Introduction to Software Process

1,823 views
1,645 views

Published on

Introductory slides for the Software Process Theory. It presents the foundations (software process, sw process improvement, basic lifecycles

Published in: Education, Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,823
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
53
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Introduction to Software Process

  1. 1. SW Process Foundations Modelos de Procesos y Metodologías de Ingeniería de software Mayo de 2014 Universidad de Caldas Facultad de Ingenierías Maestría en Ingeniería Computacional
  2. 2. Welcome!
  3. 3. Content SW Process Foundations Software Process Improvement Processes Models The IDEAL Model SP and SWEBOK Traditional Lifecycles
  4. 4. Sources •Gerard O’Regan, Introduction to Software Process Improvement, Springer 2011. ISBN 978-0-85729-171-4 •James R. Persse. Process Improvement Essentials. O'Reilly, 2006. ISBN 978-0-59-610217-3 •F. Alan Goodman. Defining and Deploying Software Processes. Auerbach Publications, 2006. ISBN 0-8493-9845-2. •Ian Sommerville. Software Engineering Ninth Edition. Addison- Wesley, 2011. ISBN 978-0-13-703515-1. •And others!!
  5. 5. In the beginning •Leon Osterweil (1987): SOFTWARE PROCESSES ARE SOFTWARE TOO •Osterweil, L. (1987) 'Software process are software too', Proceeding of 9th International Conference on Software Engineering, Monterey, California, USA, pp.2-13.
  6. 6. In the beginning •Leon Osterweil (1987):
  7. 7. In the beginning •Leon Osterweil (1987):
  8. 8. In the Beginning •… it thereby strongly invites the question of whether process programs might themselves be considered to be instances of some higher level process description… •…we should expect that they are best thought of as being only a part of a larger information aggregate… •This information aggregate contains such other software objects as requirements specifications (for the process description itself), design information (which is used to guide the creation of the process description), and test cases (projects which were guided by processes instantiated by the process description).
  9. 9. When people think in SW Process? •In an ISO 9000 program •In a CMMI adoption program •In any other process quality adoption (ISO 15504, Six Sigma…) •As consequence of any national call? •… •As consequence of pitfalls or chaos? •Really as a opportunity for reaching a full SW Quality goal(¿?) – must we do it? •Not as consequence of their formation in universities…
  10. 10. When people think in SW Process? •In resume - To elaborate on a high-level “what” step within an activity - To satisfy a high-level “what” requirement (e.g., to satisfy an ISO 9001 standard requirement) - To satisfy a high-level “what” perceived requirement (e.g., to satisfy a CMMI process maturity goal/standard practice) - To satisfy implied industry best practices - To satisfy some kind of stimulus
  11. 11. When people think in SW Process? Software process improvement initiatives are aligned to business goals and play a key role in helping companies achieve their strategic goals. It is invaluable in the implementation of best practice in organizations and allows companies to focus on fire prevention rather than firefighting. Source: Gerard O’Regan, Introduction to Software Process Improvement, Springer 2011.
  12. 12. All are connected, such as Touch (Fox) Fuente: http://sunilduttjha.files.wordpress.com/2012/02/16_changes.gif The H-W's power
  13. 13. When people think in SW Process? • National SW Quality initiative (since 2005). • Red Colombiana de Calidad para el Desarrollo en Tecnologías de Información y Comunicación (www.rcctic.org).  dead • SENA • MinTIC (FITI) • COLCIENCIAS • Some Universities (UniCauca, EAFIT, UIS…)
  14. 14. When people think in SW Process? Real life...
  15. 15. So, what is a Software Process? • It is the process used by software engineers to design and develop computer software. • A process is a set of practices or tasks performed to achieve a given purpose. It may include tools, methods, material, and people. • An organization will typically have many processes in place for doing its work, and the object of process improvement is to improve these to meet business goals more effectively.
  16. 16. SEI to rescue!! • The Software Engineering Institute (SEI) believes that there is a close relationship between the quality of the delivered software and the quality and maturity of the underlying processes employed to create the software. • The SEI adopted and applied the principles of process improvement employed in the manufacturing field to develop process maturity models such as the CMM and its successor the CMMI. These maturity models are invaluable in maturing software processes in software intensive organizations. Source: Gerard O’Regan, Introduction to Software Process Improvement, Springer 2011.
  17. 17. A SW process is an abstraction of the way in which work is done in the organization and is seen as the glue that ties people, procedures, and tools together
  18. 18. So, what is a SP Improvement? • Software process improvement is concerned with practical action to improve the processes in the organization to ensure that they meet business goals more effectively. • A program of activities designed to improve the performance and maturity of the organization’s software processes and the results of such a program.
  19. 19. • Software process improvement initiatives support the organization in achieving its key business goals such as delivering software faster to the market, improving quality, reducing or eliminating waste. • The objective is to work smarter and to build software better, faster, and cheaper than competitors. • Software process improvement makes business sense and provides a return on investment.
  20. 20. Benefits of SPI • Improvements to quality • Reductions in the cost of poor quality • Improvements in productivity • Reductions to the cost of software development • Improvements to on-time delivery • Improved consistency in budget and schedule delivery • Improvements to customer satisfaction • Improvements to employee morale
  21. 21. Process Model • A process model defines best practice for software processes in an organization. • It describes what the processes should do rather than how they should be done, and this allows the organization to use professional judgment to choose the most appropriate process implementation to meet its needs. • The process model will need to be interpreted and tailored to the particular organization.
  22. 22. Process Model (II) • A process model provides a place to start an improvement initiative and it provides a common language and shared vision for improvement. • It provides a framework to prioritize actions and allows the benefits of the experience of other organizations to be shared.
  23. 23. Process Model Examples • Capability Maturity Model Integration (CMMI) • ISO 9001 Standard • ISO 15504 • PSP and TSP • Six Sigma • IEEE standards • Root Cause Analysis • Balanced Scorecard
  24. 24. CMMI • Comes from Humphry, W.: Managing the Software Process. Addison Wesley (1989) • The CMMI is a suite of products used for improving processes, and it includes models, appraisal methods, and training material. • The CMMI models address three areas of interest: – CMMI for Development (CMMI-DEV) – CMMI for Services (CMMI-SVC) – CMMI for Acquisition (CMMI-ACQ)
  25. 25. CMMI (II) • It is a framework that allows organizations to improve their maturity by improvements to their underlying processes. • It provides a structured approach and allows the organization to set improvement goals and priorities. • It provides a clearly defined roadmap for improvement and it allows the organization to improve at its own pace. • Its approach is evolutionary rather than revolutionary, and it recognizes that a balance is required between project needs and process improvement needs.
  26. 26. CMMI (III) • It allows the processes to evolve from ad hoc immature activities to disciplined mature processes. • The CMMI practices may be used for the development, acquisition, and maintenance of products and services. A SCAMPI appraisal determines the process maturity of an organization and allows it to benchmark itself against other organizations.
  27. 27. ISO 9001 • ISO 9001 is an internationally recognized quality management standard and is customer and process focused. It applies to the processes that an organization uses to create and control products and services, and it emphasizes continuous improvement. • The standard is designed to apply to any product or service that an organization supplies. • The implementation of ISO 9001 involves understanding the requirements of the standard and how the standard applies to the organization.
  28. 28. ISO 9001 (II) • It requires the organization to identify its quality objectives, define a quality policy, produce documented procedures, and carry out independent audits to ensure that the processes and procedures are followed. • An organization may be certified against the ISO 9001 standard to gain recognition to its commitment to quality and continuous improvement. The certification involves an independent assessment of the organization to verify that it has implemented the ISO 9001 requirements properly and that the quality management system is effective.
  29. 29. ISO 9001 (III) • It will also verify that the processes and procedures defined are consistently followed and that appropriate records are maintained. • (The ISO 9004 standard provides guidance for continuous improvement).
  30. 30. ISO 15504 (SPICE) • Is an international standard for process assessment. It includes guidance for process improvement and for process capability determination, as well as guidance for performing an assessment. • It includes an exemplar process assessment model for software life cycle processes and also an exemplar process assessment model for systems life cycle processes.
  31. 31. ISO 15504 (SPICE) (II) • ISO/IEC 15504 can be used in a similar way to the CMMI and its exemplar models (for either software or systems life cycles) may be employed to implement best practice in process definition. • Assessments may be performed to identify strengths and opportunities for improvement.
  32. 32. PSP/TSP (powered by by Watt Humphrey) • The Personal Software Process (PSP) is a disciplined data-driven software development process that is designed to help software engineers understand and to improve their personal software process performance. • It helps engineers to improve their estimation and planning skills and to reduce the number of defects in their work. This enables them to make commitments that they can keep and to manage the quality of their projects.
  33. 33. PSP/TSP (II) • The Team Software Process (TSP) is a structured approach designed to help software teams understand and improve their quality and productivity. • Its focus is on building an effective software development team, and it involves establishing team goals, assigning team roles as well as other teamwork activities. Team members must already be familiar with the PSP.
  34. 34. More about Watt Humphrey • http://www.sei.cmu.edu/watts/index.cfm • He is considered as the father of software quality
  35. 35. Six Sigma • Six Sigma (6σ) was developed by Motorola in 1985, as a way to improve quality and reduce waste. • Six Sigma is an approach whose purpose is to identify and remove the causes of defects in processes by minimizing process variability. • Six Sigma was influenced by earlier quality management techniques developed by Shewhart, Deming, and Juran. • Wikipedia: A six sigma process is one in which 99.99966% of the products manufactured are statistically expected to be free of defects (3.4 defects per million)
  36. 36. Six Sigma • A Six-Sigma project follows a defined sequence of steps and has quantified targets. These targets may be financial, quality, customer satisfaction, and cycle time reduction. • It uses quality management techniques and tools such as the five whys, business process mapping, statistical techniques, and the DMAIC and DMADV methodologies.
  37. 37. Six Sigma http://www.isixsigma.com/new-to-six-sigma/design-for-six-sigma-dfss/dmaic-versus-dmadv/
  38. 38. Starting a SPI program • The need for a software process improvement initiative often arises from the realization that: – the organization is weak in some areas in software engineering, and – that it needs to improve to achieve its business goals more effectively. • The starting point of any improvement initiative is an examination of the business goals of the organization and these may include – Delivering high-quality products on time – Delivering products faster to the market – Reducing the cost of software development – Improving software quality
  39. 39. Obstacles • Software process improvement initiatives are not always successful, and occasionally an improvement initiative is abandoned. Some of the reasons for failure are – Unrealistic expectations – Trying to do too much at once – Lack of senior management sponsorship – Focusing on a maturity level – Poor project management of the initiative – Not run as a standard project – Insufficient involvement of staff – Insufficient time to work on improvements – Inadequate training on software process improvement – Lack of pilots to validate new processes – Inadequate rollout of new processes
  40. 40. Obstacles • It is essential that a software process improvement initiative be treated as a standard project with a project manager assigned to manage the initiative. • Senior management need to be 100% committed to the success of the initiative, and they need to make staff available to work on the improvement activities. • It needs to be clear to all staff that the improvement initiative is a priority to the organization. • All staff need to receive appropriate training on software process improvement and on the process maturity model
  41. 41. Be carefull Software Processes are essential for Software Quality …. But, quality in software needs more elements…
  42. 42. Be carefull According with ISO 25000 (SQUARE) – evolution of ISO 9126
  43. 43. ISO’s for Sofware Process • ISO 9000 • ISO 12207 - defines the software engineering process, activity, and tasks that are associated with a software life cycle process from conception through retirement - A standard that provides a common framework to speak the same language in software discipline. • ISO 15504 • Please see slides from Claude Laporte http://profs.etsmtl.ca/claporte/english/VSE/Education/Intro%2 0to%20ISO-IEC%20SE%20standards%2002RO.ppt
  44. 44. Starting a SPI program • Building through executive sponsorship • Capitalizing on your strengths • Understanding what you'd like to do better • Focusing on targeted improvements • Borrowing from the industry • Building from the inside • Building to grow • Training your people • Providing support • Patience, not perfection
  45. 45. Starting a SPI program • It's a good idea to follow something of a predictable path when you want to establish a process program: a method that will help shape the program as smoothly as possible, in an orderly and manageable way. • One approach to this can be found in the IDEAL model: Initiate, Diagnose, Establish, Act, and Learn. IDEAL is a general approach to process improvement
  46. 46. IDEAL Model
  47. 47. IDEAL Model (II) - Initiate • In the Initiate phase, an organization typically reaches the understanding that it has operational issues that need to be addressed. • This realization is often predicated by some symptomatic imbalance within the organization: falling sales, rising costs, increased complaints, low morale, or even the appreciation for general improvement, for strengthening the organization's current position. • It can be many things, but it's always a trigger for action.
  48. 48. IDEAL Model (III) - Initiate • The organization makes a conscious decision to initiate action, to act on its needs. This decision is then followed by the critical impetus of dedication to act. • The Initiate phase is typically the point at which you acquire executive sponsorship and begin to formulate the scope of what you want to address in your process program.
  49. 49. IDEAL Model (IV) - Diagnose • In the Diagnose phase, the organization's current quality and process positions is determined, also its strengths and weaknesses, and what areas for improvement should be addressed by this effort. • Questions to resolve: What the organization should change?, where it should focus its improvement activities?. • Many process managers would argue that this is the stage where you should devote most of your energy, most of your creative thinking. The better the diagnosis, the better the chance for a highly successful solution.
  50. 50. IDEAL Model (V) - Establish • In the Establish phase, you typically create your process components or refine existing ones. • The key to successful establishment is to create solutions that reflect the way your people work, solutions that possess a strong goodness-of-fit to the culture of the organization.
  51. 51. IDEAL Model (VI) - Establish • Solution involves three key factors: - It should be designed with organizational use in mind. That is, you should be pretty certain that if you implement it, it will work. - The solution should be designed not to impact the integrity of any up-line or down-line activity. You don't want to cause other problems by fixing one. - The solution should be in some way measurable. The best way to test if any solution works is to measure its activity. (This use of the measurement data comes into play during the Learn portion of IDEAL.)
  52. 52. IDEAL Model (VII) - Act • Here, you implement the solutions you designed. • Act may require a series of support steps, such as training or documentation preparation, but the real goal here is to act on your design: put it effectively into place, monitor its use, and then move to the final step, Learn. • Act is the phase during which you typically train your people, provide them with program support materials, and then implement the program in the organization.
  53. 53. IDEAL Model (VIII) - Learn • Process improvement is all about learning. That's a core trait of the discipline: it's a cultural commitment to continued learning. • Time and data will give you the factual base you need to determine the success of your efforts and may also point you to new opportunities for strengthening the system • What that observation period largely depends on is the nature of your environment and the solutions you've added into the environment.
  54. 54. IDEAL Model (IX) • The IDEAL model are considered since SWEBOK 2004 together with Quality Improvement Paradigm (QIP) as the two general models that have emerged for driving process implementation and change. • Reference work: Software Engineering Laboratory, Software Process Improvement Guidebook, Software Engineering Laboratory, NASA/GSFC, Technical Report SEL-95-102, April 1996. • SWEBOK: Evaluation of process implementation and change outcomes can be qualitative or quantitative.
  55. 55. SP and SWEBOK http://www.computer.org/portal/web/swebok/v3guide SWEBOK 2013 - Chapter 8 ISO Technical Report ISO/IEC TR 19759
  56. 56. SP and SWEBOK Chapter 8 - Software Process Definition
  57. 57. SP and SWEBOK •Pair Programming •RAD •XP •Scrum •FDD SWEBOK 2013 - Chapter 9 ISO Technical Report ISO/IEC TR 19759
  58. 58. • There is, of course, little point in having high-quality processes unless their use is institutionalized in the organization. That is, all staff need to follow the processes consistently. • This requires that all affected staff are trained on the new processes and that process discipline is instilled by an appropriate audit strategy. • Mature software companies will establish high- quality processes for the various software. So…
  59. 59. • The development of software involves many processes such as those for defining requirements; processes for project management and estimation; and processes for design, implementation, testing management and engineering activities. • All affected staff will then be trained on the new processes and audits will be conducted to ensure that the process is followed. Data will be collected to improve the process.
  60. 60. • The software process assets in an organization generally consist of – A software development policy for the organization – Process maps that describe the flow of activities – Procedures and guidelines that describe the processes in more detail – Checklists to assist with the performance of the process – Templates for the performance of specific activities (e.g. design, testing) – Training materials
  61. 61. The processes employed to develop high-quality software generally include processes for – Project management process – Requirements process – Design process – Coding process – Peer review process – Testing process – Supplier selection and management processes – Configuration management process – Audit process – Measurement process – Improvement process – Customer support and maintenance processes
  62. 62. The software development process has an associated life cycle that consists of various phases. There are several well-known life cycles employed such as • the waterfall model, • the spiral model, and • the IBM Rational Unified Process.
  63. 63. Traditional components of a SW Process • Purpose description • Entry Criteria (previous activities or preconditions that may need to have occurred in order for the activities of this process to be successfully carried out) • Inputs • Actors • Activities • Outputs • Exit criteria (results that should be in place in order to conclude that the process has been sucessfully run) • Measures
  64. 64. Traditional components of a SW Process Program • Processes • Procedures • Templates • Forms and checklists • Guidelines • Repositories • Training materials
  65. 65. • Roy:70 Royce, Winston.: The software lifecycle model (waterfall model). In: Proceedings WESTCON, Los Angeles, Aug 1970. • Source of the "conventional software process"? • Benchmark? • It provides an insightful and concise summary of conventional software management philosophy circa 1970. The waterfall lifecycle model
  66. 66. The waterfall lifecycle model (II) primary points of Royce paper
  67. 67. The waterfall lifecycle model (III) proposal 1970
  68. 68. • It starts with requirements gathering and definition. It is followed by the functional specification, the design and implementation of the software, and comprehensive testing. • The testing generally includes unit, system, and user acceptance testing. • The waterfall model is employed for projects where the requirements can be identified early in the project life cycle or are known in advance. The waterfall lifecycle model (IV)
  69. 69. • Each phase has entry and exit criteria that must be satisfied before the next phase commences. • There are several variations to the waterfall mode. • There is a variation: the “V” life cycle model, with the left-hand side of the “V” detailing requirements, specification, design, and coding and the right-hand side detailing unit tests, integration tests, system tests, and acceptance testing. - Specially mentioned by the ISTQB Certification!! The waterfall lifecycle model (V)
  70. 70. The waterfall lifecycle model (VI) typical "V" waterfall Source: Advanced Software Testing— Vol. 3 - Guide to the ISTQB Advanced Certification as an Advanced Technical Test Analyst http://www.istqb.org/
  71. 71. • The spiral model is useful where the requirements are not fully known at project initiation. • The requirements evolve as a part of the development life cycle. • The development proceeds in a number of spirals, where each spiral typically involves updates to the requirements, design, code, testing and a user review of the particular iteration or spiral. The spiral lifecycle model
  72. 72. The spiral lifecycle model (II) Typical spiral example
  73. 73. The spiral lifecycle model (III) Boehm’s spiral model of the software process (©IEEE 1988)
  74. 74. • The spiral is a reusable prototype with the business analysts and the customer reviewing the current iteration and providing feedback to the development team. • The feedback is then analyzed and addressed in subsequent spirals. • This approach is often used in joint application development for web-based software development as usability and the look and feel of the application is a key concern. The implementation of part of the system helps in gaining a better understanding of the requirements of the system, and this feeds into subsequent development cycle in the spiral. • The process repeats until the requirements and the software product are fully complete. The spiral lifecycle model (IV)
  75. 75. • A risk-driven software process framework • Each loop in the spiral represents a phase of the software process. • The innermost loop might be concerned with system feasibility, the next loop with requirements definition, the next loop with system design, and so on. • The spiral model combines change avoidance with change tolerance. • It assumes that changes are a result of project risks and includes explicit risk management activities to reduce these risks. Boehm’s spiral model
  76. 76. Objective setting • Specific objectives for that phase of the project are defined. • Constraints on the process and the product are identified and a detailed management plan is drawn up. • Project risks are identified. Alternative strategies, depending on these risks, may be planned. Risk assessment and reduction • For each of the identified project risks, a detailed analysis is carried out. • Steps are taken to reduce the risk. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed. Boehm’s spiral model (II)
  77. 77. Development and validation • After risk evaluation, a development model for the system is chosen. • For example, throwaway prototyping may be the best development approach if user interface risks are dominant. If safety risks are the main consideration, development based on formal transformations may be the most appropriate process, and so on. If the main identified risk is sub-system integration, the waterfall model may be the best development model to use. Planning • The project is reviewed and a decision made whether to continue with a further loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the project. Boehm’s spiral model (III)
  78. 78. • The main difference between the spiral model and other software process models is its explicit recognition of risk. • A cycle of the spiral begins by elaborating objectives such as performance and functionality. Alternative ways of achieving these objectives, and dealing with the constraints on each of them, are then enumerated. • Each alternative is assessed against each objective and sources of project risk are identified. • The next step is to resolve these risks by information-gathering activities such as more detailed analysis, prototyping, and simulation. • Once risks have been assessed, some development is carried out, followed by a planning activity for the next phase of the process. • Informally, risk simply means something that can go wrong. • Risks lead to proposed software changes and project problems such as schedule and cost overrun, so risk minimization is a very important project management activity. Boehm’s spiral model (IV)
  79. 79. • A prototype is an initial version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions. • Rapid, iterative development of the prototype is essential so that costs are controlled and system stakeholders can experiment with the prototype early in the software process. • A software prototype can be used in a software development process to help anticipate changes that may be required: 1. In the requirements engineering process, a prototype can help with the elicitation and validation of system requirements. 2. In the system design process, a prototype can be used to explore particular software solutions and to support user interface design. Prototyping
  80. 80. • A system prototype may be used while the system is being designed to carry out design experiments to check the feasibility of a proposed design. For example, a database design may be prototyped and tested to check that it supports efficient data access for the most common user queries. • Prototyping is also an essential part of the user interface design process. Because of the dynamic nature of user interfaces, textual descriptions and diagrams are not good enough for expressing the user interface requirements. Therefore, rapid prototyping with end-user involvement is the only sensible way to develop graphical user interfaces for software systems. Prototyping (II)
  81. 81. Prototyping (III) Prototyping software process defined by Sommerville
  82. 82. • It may be impossible to tune the prototype to meet non- functional requirements, such as performance, security, robustness, and reliability requirements, which were ignored during prototype development. • Rapid change during development inevitably means that the prototype is undocumented. The only design specification is the prototype code. This is not good enough for long-term maintenance. • The changes made during prototype development will probably have degraded the system structure. The system will be difficult and expensive to maintain. • Organizational quality standards are normally relaxed for prototype development. • Prototypes do not have to be executable to be useful (mockups for example) Prototyping in real life
  83. 83. • A general problem with prototyping is that the prototype may not necessarily be used in the same way as the final system. The tester of the prototype may not be typical of system users. The training time during prototype evaluation may be insufficient. • If the prototype is slow, the evaluators may adjust their way of working and avoid those system features that have slow response times. When provided with better response in the final system, they may use it in a different way. Prototyping in real life (II)
  84. 84. • Some of the developed increments are delivered to the customer and deployed for use in an operational environment. • In an incremental delivery process, customers identify, in outline, the services to be provided by the system. They identify which of the services are most important and which are least important to them. • A number of delivery increments are then defined, with each increment providing a sub-set of the system functionality. Iterative – Incremental delivery
  85. 85. Iterative – Incremental delivery (II) typical iterative-incremental scenario
  86. 86. • The allocation of services to increments depends on the service priority, with the highest-priority services implemented and delivered first. • Once the system increments have been identified, the requirements for the services to be delivered in the first increment are defined in detail and that increment is developed. • During development, further requirements analysis for later increments can take place but requirements changes for the current increment are not accepted. • Once an increment is completed and delivered, customers can put it into service. This means that they take early delivery of part of the system functionality. Iterative – Incremental delivery (III)
  87. 87. • Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments. • (Unlike prototypes, these are part of the real system so there is no re-learning when the complete system is available). • Customers do not have to wait until the entire system is delivered before they can gain value from it. The first increment satisfies their most critical requirements so they can use the software immediately. • The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system. • As the highest-priority services are delivered first and increments then integrated, the most important system services receive the most testing. This means that customers are less likely to encounter software failures in the most important parts of the system. Advantages IID
  88. 88. • Most systems require a set of basic facilities that are used by different parts of the system. It can be hard to identify common facilities that are needed by all increments. As requirements are not defined in detail until an increment is to be implemented, • Iterative development can also be difficult when a replacement system is being developed. Users want all of the functionality of the old system and are often unwilling to experiment with an incomplete new system. Therefore, getting useful customer feedback is difficult. Problems IID
  89. 89. The essence of iterative processes is that the specification is developed in conjunction with the software. So… • This conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract. • This requires a new form of contract, which large customers such as government agencies may find difficult to accommodate. • In the incremental approach, there is no complete system specification until the final increment is specified. Problems IID (II)
  90. 90. Conclusion? http://testingtype.freetzi.com/sdlc_model.html The Build and Fix model
  91. 91. Graphical Comparison Source: Melnik Grigiri, Meszaros Gerard and Bach Jon. Acceptance Test Engineering Guide Volume I: Thinking. Microsoft Patterns and Practices Press,2009. Multi‐release waterfall with overlapping functionality Classical waterfall Multi‐release waterfall with independentfunctionality
  92. 92. Graphical Comparison Source: Melnik Grigiri, Meszaros Gerard and Bach Jon. Acceptance Test Engineering Guide Volume I: Thinking. Microsoft Patterns and Practices Press,2009. Agile methods (comming soon) Iterative & Incremental
  93. 93. Questions? Thanks

×