2010/02/08

System development integration Week2_1

Software Development Life Cycle (SDLC)


  1. Requirement (Analysis)
  2. Design
  3. Implementation
  4. Testing
  5. Deployment
  6. Maintenance
Waterfall Model
*It must be reviewed all broader concept phases before next step.


  • System Requirement Definition (How many users? How many Locations?)
  • Software Requirements Analysis
  • Preliminary design
  • Detailed design
  • Coding and unit testing
  • Component integration and testing
  • Integration testing
  • System testing
  • Maintain software
- Pros

  1. System is well documented.
  2. Phases correspond with project management phases.
  3. Cost and schedule estimates may be lower and more accurate.
  4. Details can be addressed with more engineering effort if software is large or complex.
- Cons


  1. All risks must be deal with in a single software development effort.
  2. Because the model is sequential, there is only local feedback at the transaction between phases.
  3. A working product is not available until late in the project.
  4. Progress and success are not observable until the later stages. If a mistake or deficiency exists in the documentation of earlier phases, it may not be discovered until the product is delivered.
  5. Corrections must often wait for the maintenance phase.
- Concluding


  • The waterfall model can be successfully used when requirements are well understood in the beginning and are not expected to change or evolve over the project. Project risks should be relatively low.

Incremental Model
- Pros


  1. Provides some feedback, allowing later development cycles to learn from previous cycles.
  2. Requirements are relatively stable and may be better understood with each increment.
  3. Allows some requirements modification and may allow the addition of new requirements.
  4. It is more resposive to user needs than the waterfall model.
  5. A usable product is available with the first release, and each cycle results in greater functionality.
  6. The project can be stopped any time after the first cycle and leave a working product.
  7. Risk is spread out over multiple cycles.
  8. This method can usually be performed with fewer people than the waterfall model.
  9. Return on investment is visible earlier for smaller, incremental project.
  10. Testing may be easier on smaller portions of the system.

- Cons

  1. The majority of requirements must be known in the begining.
  2. Formal reviews may be more difficult to implement on incremental releases than on a complete system.
  3. Because development isspread out over multiple iterations, interfaces between modules mesut be well-known defined in the beginning.
  4. Cost and schedule overruns may result in an unfinished sysrtem.
  5. Operations are impacted as each new release is deployed.
  6. Users are required to learn how to use a new system with each deployment.

- Concluding

The incremental model is good for projects where requirements are known at beginning, but which need functionality early in the project or which can benefit from the feedback of earlier cycyles.

Evolutionary Model (Prototyping)

- Pros

  1. Project can begin without fully defining or understanding requirements.
  2. Final requirements are improved and more in line with real user needs.
  3. Risks are spread over multiple software builds and controlled better.
  4. Operational capability is achieved earlier in the program.
  5. Newer technology can be incorporated into the system as it becomes available durinng later prototypes.
  6. Documentation emphasizes the final product instead of the evoluition of the product.
  7. This method combines a formal specification with an operational prototype.

- Cons

  1. Because there are more activities and changes, there is usually an increase in both cost and schedule over the waterfall method.
  2. Management activities are increased.
  3. Instead of a single switch over to a new system, there is an ongoing impact to current operations.
  4. Configuration management activities are increased.
  5. Greater coordination of resources is required.
  6. Users sometimes mistake a prototype for the final system.
  7. Prototypes changes between cycles, adding a learning curve for developers and users.
  8. Risks may be increased in the areas.

- Concluding

  • The evolutionary model can be employed on the most type of acquisitions. However, it is usually employed on medium to high-risk systems.

0 件のコメント:

コメントを投稿

UA-9417263-1