The Spiral Model of Software Development and Enhancement Barry W. Boehm, TRW Defense Systems Group Victor Velez Group # 5 ...
Outline <ul><li>• Introduction </li></ul><ul><li>• Previous Models </li></ul><ul><li>• The Spiral Model </li></ul><ul><li>...
Introduction <ul><li>Basically, the idea of Spiral  Model  is evolutionary development, using the waterfall model for each...
A Risk-Driven Approach <ul><li>• Different idea of software development. </li></ul><ul><li>• How does this project affect ...
Software Process Model <ul><li>As opposed to a  software methodology . </li></ul><ul><li>–  How to navigate through each p...
Previous Software Process Models <ul><li>An evolution of models </li></ul><ul><li>–  Code & Fix </li></ul><ul><li>–  Stage...
Spiral Model <ul><li>A different approach born out of the evolution of the Waterfall Model. </li></ul><ul><li>• Encompasse...
Initiating/Terminating the Process <ul><li>•  Initiating the process </li></ul><ul><li>–  Hypothesize that a particular op...
Cycle Requirements <ul><li>If alternatives or uncertainties are found </li></ul><ul><li>they must be resolved. </li></ul><...
Cycle Requirements…Cont <ul><li>Each cycle is completed by a review by </li></ul><ul><li>the people concerned with the pro...
Applied to TRW-SPS <ul><li>An example of how the Spiral model works in a </li></ul><ul><li>large system. </li></ul><ul><li...
More Rounds?? <ul><li>Succeeding rounds may be necessary. </li></ul><ul><li>•  Depends on the amount of risk. </li></ul><u...
Spiral Model Features <ul><li>Balances all of the risk elements, i.e. the </li></ul><ul><li>high-risk elements must be low...
Results <ul><li>•  The Software Productivity System (SPS) </li></ul><ul><li>has grown to over 300 tools and 1.3 </li></ul>...
Advantages <ul><li>􀀹It promotes reuse of existing software in </li></ul><ul><li>early stages of development. </li></ul><ul...
Disadvantages <ul><li>􀂙 Spiral model not yet complete (in 1988). </li></ul><ul><li>􀂙 Matching to contract software </li></...
Conclusions <ul><li>The paper draws four conclusions: </li></ul><ul><li>1. The risk-driven nature provides adaptability </...
Evaluating Software Engineering Standards Shari Lawrence Pfleeger, Norman Fenton, and Stella Page Centre for Software Reli...
Introduction   <ul><li>This article reports on the results for: </li></ul><ul><li>the  Smartie  project ( S tandards and  ...
What is a Good Standard <ul><li>It involves at least three aspects: </li></ul><ul><li>1  What attributes of the final prod...
To what do our standards apply <ul><li>It apply to: </li></ul><ul><ul><li>Process:   </li></ul></ul><ul><li>validation of ...
Are Software Standards like other Standards? <ul><li>No are not.  </li></ul><ul><li>Software engineering standards are  he...
Conclusions <ul><li>The Smartie framework is practical and effective in identifying problems with standards and making cha...
Thank you
Upcoming SlideShare
Loading in …5
×

Sanjay

460 views

Published on

capital structure of NTPC

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
460
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sanjay

  1. 1. The Spiral Model of Software Development and Enhancement Barry W. Boehm, TRW Defense Systems Group Victor Velez Group # 5 April 05/04
  2. 2. Outline <ul><li>• Introduction </li></ul><ul><li>• Previous Models </li></ul><ul><li>• The Spiral Model </li></ul><ul><li>• TRW-SPS Application </li></ul><ul><li>• Advantages and Difficulties </li></ul><ul><li>• Risk Management </li></ul><ul><li>• Conclusions </li></ul><ul><li>• Future of the Spiral Model </li></ul><ul><li>• Discussion </li></ul>
  3. 3. Introduction <ul><li>Basically, the idea of Spiral Model is evolutionary development, using the waterfall model for each step; it's intended to help by a Risk-Driven Approach . Don't define in detail the entire system at first. The developers should only define the highest priority features. Define and implement those, then get feedback from users/customers (such feedback distinguishes &quot;evolutionary&quot; from &quot;incremental&quot; development). With this knowledge, they should then go back to define and implement more features in smaller chunks. </li></ul>
  4. 4. A Risk-Driven Approach <ul><li>• Different idea of software development. </li></ul><ul><li>• How does this project affect the </li></ul><ul><li>developers and the clients? </li></ul><ul><li>• How does each step in the project affect </li></ul><ul><li>its overall development? </li></ul><ul><li>• Not used in previous development models. </li></ul><ul><li>– Usually code-driven or document-driven. </li></ul>
  5. 5. Software Process Model <ul><li>As opposed to a software methodology . </li></ul><ul><li>– How to navigate through each phase (Data, </li></ul><ul><li>Control) </li></ul><ul><li>– How to represent phase products (Diagrams) </li></ul><ul><li>• Used to determine the order of the stages </li></ul><ul><li>and to establish the transition criteria. </li></ul><ul><li>– What do we do next? </li></ul><ul><li>– How long shall we continue doing it? </li></ul><ul><li>• Provides guidance between the different </li></ul><ul><li>phases of a project. </li></ul>
  6. 6. Previous Software Process Models <ul><li>An evolution of models </li></ul><ul><li>– Code & Fix </li></ul><ul><li>– Stagewise & Waterfall </li></ul><ul><li>– Evolutionary Development </li></ul><ul><li>– Transform Model </li></ul>
  7. 7. Spiral Model <ul><li>A different approach born out of the evolution of the Waterfall Model. </li></ul><ul><li>• Encompasses the previous models as special </li></ul><ul><li>cases, and can make use of a combination of </li></ul><ul><li>models. </li></ul><ul><li>• Risk analysis asks, “ What are the areas of </li></ul><ul><li>uncertainty, and what is the probability that </li></ul><ul><li>they will slow the progress of development?” </li></ul>
  8. 8. Initiating/Terminating the Process <ul><li>• Initiating the process </li></ul><ul><li>– Hypothesize that a particular operational mission(s) </li></ul><ul><li>can be improved by software effort. </li></ul><ul><li>• Test this hypothesis throughout. </li></ul><ul><li>• Terminating </li></ul><ul><li>– If a spiral violates its hypothesis then the </li></ul><ul><li>spiral is terminated. </li></ul><ul><li>– Otherwise it ends with the installation of a </li></ul><ul><li>new or modified software product. </li></ul>
  9. 9. Cycle Requirements <ul><li>If alternatives or uncertainties are found </li></ul><ul><li>they must be resolved. </li></ul><ul><li>• Risk-driven “subsetting” allows a mixture of </li></ul><ul><li>other software process models, as </li></ul><ul><li>necessary, until a high-risk situation is </li></ul><ul><li>resolved. </li></ul><ul><li>– Specification-oriented (Transform or Stagewise) </li></ul><ul><li>– Prototype-oriented (Waterfall) </li></ul><ul><li>– Automatic-transformation oriented (Transform) </li></ul><ul><li>– Simulation-oriented (Evolutionary) </li></ul>
  10. 10. Cycle Requirements…Cont <ul><li>Each cycle is completed by a review by </li></ul><ul><li>the people concerned with the project. </li></ul><ul><li>• Plans for the next cycle should be </li></ul><ul><li>introduced. </li></ul><ul><li>• With each succeeding level in the spiral </li></ul><ul><li>the level of detail increases. </li></ul>
  11. 11. Applied to TRW-SPS <ul><li>An example of how the Spiral model works in a </li></ul><ul><li>large system. </li></ul><ul><li>• Software Productivity System (SPS) – a group of integrated software development tools for use within TRW, as well as for other clients. </li></ul><ul><li>• Spiral Model rounds </li></ul><ul><li>– Rounds correspond to a level in the spiral. </li></ul><ul><li>– In this case, a Round 0 was needed to determine </li></ul><ul><li>initial feasibility of the TRW-SPS project, but is not </li></ul><ul><li>necessary for all projects. </li></ul>
  12. 12. More Rounds?? <ul><li>Succeeding rounds may be necessary. </li></ul><ul><li>• Depends on the amount of risk. </li></ul><ul><li>– Ex. The risk alleviation of the RTT </li></ul><ul><li>preliminary design specification. </li></ul><ul><li>• More attractive alternatives may be found. </li></ul><ul><li>– Ex. The change in UDF tool requirements. </li></ul>
  13. 13. Spiral Model Features <ul><li>Balances all of the risk elements, i.e. the </li></ul><ul><li>high-risk elements must be lowered first. </li></ul><ul><li>• Offers prototyping as a risk-reduction </li></ul><ul><li>option at any stage of development. </li></ul><ul><li>• It allows reworks of earlier stages as more </li></ul><ul><li>attractive alternatives are identified. </li></ul><ul><li>• Detail isn’t necessary until detail is </li></ul><ul><li>needed. (Round 0) </li></ul>
  14. 14. Results <ul><li>• The Software Productivity System (SPS) </li></ul><ul><li>has grown to over 300 tools and 1.3 </li></ul><ul><li>million instructions. </li></ul><ul><li>• Over 25 projects have used SPS with </li></ul><ul><li>overall productivity up 50%; most projects </li></ul><ul><li>have doubled productivity. </li></ul><ul><li>• One underestimation of Unix compatibility </li></ul><ul><li>led to some TRW projects not using SPS. </li></ul>
  15. 15. Advantages <ul><li>􀀹It promotes reuse of existing software in </li></ul><ul><li>early stages of development. </li></ul><ul><li>􀀹Allows quality objectives to be formulated </li></ul><ul><li>during development. </li></ul><ul><li>􀀹Provides preparation for eventual </li></ul><ul><li>evolution of the software product. </li></ul><ul><li>􀀹Eliminates errors and unattractive </li></ul><ul><li>alternatives early. </li></ul>
  16. 16. Disadvantages <ul><li>􀂙 Spiral model not yet complete (in 1988). </li></ul><ul><li>􀂙 Matching to contract software </li></ul><ul><li>– Internal projects have more freedom. </li></ul><ul><li>– Contract software demands total control and a full </li></ul><ul><li>picture of the deliverables in advance. </li></ul><ul><li>􀂙 Relying on risk-assessment expertise. </li></ul><ul><li>􀂙 Need for further elaboration of spiral model steps. </li></ul><ul><li>– Milestones and specifications. </li></ul><ul><li>– Guidelines and checklists. </li></ul>
  17. 17. Conclusions <ul><li>The paper draws four conclusions: </li></ul><ul><li>1. The risk-driven nature provides adaptability </li></ul><ul><li>for a full range of software projects. </li></ul><ul><li>2. The model has been successful in a large </li></ul><ul><li>application, the TRW-SPS. </li></ul><ul><li>3. The model is not yet fully elaborated. </li></ul><ul><li>4. Even partial implementations of the model, </li></ul><ul><li>such as the risk management plan, are </li></ul><ul><li>compatible with the other process models. </li></ul>
  18. 18. Evaluating Software Engineering Standards Shari Lawrence Pfleeger, Norman Fenton, and Stella Page Centre for Software Reliability
  19. 19. Introduction <ul><li>This article reports on the results for: </li></ul><ul><li>the Smartie project ( S tandards and M ethods </li></ul><ul><li>A ssessment using R igorous T echniques in </li></ul><ul><li>I ndustrial E nviroments). </li></ul><ul><li>Smartie : </li></ul><ul><li>- uses standards (some of those have not been </li></ul><ul><li>patented) to reflect the user’s needs and </li></ul><ul><li>builder’s practices to improve software </li></ul><ul><li>development processes and products. </li></ul><ul><li>- Identifies the benefits of using the standard. </li></ul>
  20. 20. What is a Good Standard <ul><li>It involves at least three aspects: </li></ul><ul><li>1 What attributes of the final product are supposed to </li></ul><ul><li>improve by using the standard. </li></ul><ul><li>2 Cost of applying the standard. </li></ul><ul><li>3 How the standard is being complied with requirements </li></ul><ul><li>- Reference-only : no way to determine compliance </li></ul><ul><li>- Subjective : only a subjective measure of conformance </li></ul><ul><li>- Partially objective : Objective, but still requires objectivity </li></ul><ul><li>- Completely objective : most desirable kind </li></ul>
  21. 21. To what do our standards apply <ul><li>It apply to: </li></ul><ul><ul><li>Process: </li></ul></ul><ul><li>validation of specifications vs. requirements </li></ul><ul><ul><li>Internal product: </li></ul></ul><ul><li>refers to the code </li></ul><ul><ul><li>External product: </li></ul></ul><ul><li>user experiences( e.g. reliability) </li></ul><ul><ul><li>Resources: </li></ul></ul><ul><li>staff, tools and support software </li></ul>
  22. 22. Are Software Standards like other Standards? <ul><li>No are not. </li></ul><ul><li>Software engineering standards are heavy on process and light on product , while other engineering standards are the reverse </li></ul><ul><li>Most other engineering include in their standard a description of the method to be used to asses compliance. Software one, lack objective assessment criteria. So, are not always based on rigorous experimental results </li></ul>
  23. 23. Conclusions <ul><li>The Smartie framework is practical and effective in identifying problems with standards and making changes that are needed on them </li></ul><ul><li>Some standards apply to certain types of modules. So notions of conformance must be adjusted to consider only that part of the system </li></ul><ul><li>Software engineering standards should be better balanced, with more product requirements in relation to process and resource requirements </li></ul>
  24. 24. Thank you

×