Note Excerpts from Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R. Schach
CHAPTERS 1 & 2 THE SCOPE OF OBJECT-ORIENTED SOFTWARE ENGINEERING & THE SOFTWARE PROCESS
Dealing with Unrealistic Requirements When the project requirements are not feasible… ◦ Is there is an off-the-shelf solution that can be used? ◦ Can the time/cost constraints be relaxed? ◦ Can the functionality be reduced? Provide data that shows the client that the project as stated is not feasible. ◦ Hardware invoices. ◦ Software development schedules and costs. Never make promises that you cannot keep!
Protecting the Interest of Your Company (Client’s concerns) The contract should state that the “software shall meet specifications, be delivered on time, within budget”… ◦ Specify acceptance criteria. ◦ Specify deliverables. ◦ Specify that “all faults shall be corrected at no further charge for a period of one year after acceptance of the product”. ◦ Specify that “documentation shall be full and complete and shall include source code, specifications, design and operating instructions”. ◦ Specify the type and duration of training that shall be provided. ◦ Specify the terms of the maintenance contract. ◦ Specify the developer’s liability for damages caused by faults in software.
What can go wrong? Late Delivery ◦ Underestimating the size of the problem. ◦ Failure to obtain complete and accurate requirements. ◦ Poor planning. ◦ Failure to specify the product correctly. ◦ Poor management techniques. ◦ Failure to detect faults early in the life cycle. ◦ Ineffective or badly trained personnel. ◦ Poor quality testing. ◦ Personnel turnover. ◦ Poor documentation of the development process. ◦ Poor communication between members of the development team. ◦ Continual hard-ware and/or system software failures. Project over budget All of the above, plus Unexpected price increases for hardware, programming tools, and so on. Product does not meet specifications All of the above, plus Poor quality specifications. Poor testing. Poor quality assurance. Operational faults, such as injuries to sailors firing the missiles. Poor testing, and hence residual faults. Poor quality documentation. Inadequate documentation. Badly trained personnel. Poor management.
A few definitions… A workflow is a set of activities. An artifact is a constituent component of a software product. A workflow creates or modifies one or more artifacts. A baseline is a set of artifacts.
Things to consider when choosing a Life Cycle Model. Experience and skills of the development team. Computer literacy of the client. Extent to which the client seems to appreciate his or her real needs.
Mitigating Risks… The users may not be comfortable with the product: ◦ -> Construct a rapid prototype of the user interface ◦ -> Involve the purchasing clerks, factory supervisors, sales clerks, and so on, in the development loop. The product may not be what the client really needs: ◦ -> Construct a rapid prototype. The design may not permit future development as the corporation grows or changes the way it does business: ◦ -> Ensure that the design is as open-ended as is reasonable. There may be cost and or time overruns. ◦ -> Estimate carefully (see Chapter 9). A competitor may produce off-the-shelf software before the product has been delivered: ◦ Really no way to resolve this risk. A critical member of the development team may leave: ◦ -> Keep management of the development organization abreast of major decisions being made, thereby making it easier to integrate a replacement into the team. The development team may not be properly managed ◦ ->Ensure that managers are competent and well-trained.
Iterative-and-Incremental Life-Cycle ◦ Offers multiple opportunities for checking that the software product is correct. ◦ The robustness of the underlying architecture can be determined relatively early in the life cycle. ◦ Risks can be mitigated early. ◦ There is always a working version of the software.