90 likes | 174 Views
Note Excerpts from Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R. Schach srs@vuse.vanderbilt.edu. CHAPTERS 1 & 2. THE SCOPE OF OBJECT-ORIENTED SOFTWARE ENGINEERING & THE SOFTWARE PROCESS. Dealing with Unrealistic Requirements.
E N D
Note Excerpts from Object-Oriented Software EngineeringWCB/McGraw-Hill, 2008Stephen R. Schachsrs@vuse.vanderbilt.edu
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? • 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. • 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.
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.