Note Excerpts from Note Excerpts from

Object-Oriented Software Object-Oriented Software EngineeringEngineering WCB/McGraw-Hill, 2008WCB/McGraw-Hill, 2008

Stephen R. SchachStephen R. Schachsrs@vuse.vanderbilt.edusrs@vuse.vanderbilt.edu

CHAPTERS 1 & 2CHAPTERS 1 & 2

THE SCOPE OFOBJECT-ORIENTED

SOFTWARE ENGINEERING

&THE SOFTWARE PROCESS

Dealing with Unrealistic Dealing with Unrealistic RequirementsRequirementsWhen 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 Protecting the Interest of Your Company (Client’s concerns)(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?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 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 Things to consider when choosing a Life Cycle Model.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…Mitigating Risks… The users may not be comfortable with the product:

◦ -> Construct a rapid proto type of the user inter face

◦ -> 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 Iterative-and-Incremental Life-CycleLife-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.