of Foundations Software Engineering (for non-software engineers)
Software Development Life Cycles Guy-Vincent Jourdan
Software Life Cycles
Early software development was done with no planning, no formal design and analysis. To develop software, you would code, debug and test, "until done". Software development life cycles have been introduced starting in 1970 to formalize a framework for the software development phases and give tools to assess whether the requirements and quality criteria expected have been satisfied
Software Life Cycles
Futrell, R., Shafer, D. and Shafer L., Quality Software Project Management, Prentice Hall PTR, 2002 Van Vliet, H. Software Engineering: Principles and Practice, 2nd Edition, Wiley, 2000 Christensen, M.J. and Thayer, R.H. Project Manager's Guide to Software Engineering's Best Practices, IEEE Press, 2002 IEEE 12207-1996 Software life cycle processes Description IEEE 1074-1997 Developing Software Life Cycle Processes
Software Life Cycles
Most well known software development life cycles: The waterfall model The v-shaped model The prototyping model The rapid application development model The incremental development model The spiral model The agile model
The waterfall model
Waterfall SDLC have been introduced as early as '70. Several refinements have been proposed over the years, but the model is still used extensively today. It is not necessarily followed precisely, but the "flow" that it captures is often the default model that is used, usually informally, in many software projects today.
The waterfall model
Waterfall SDLC example proposed by Boehm in 76.
System (user) requirements Software requirements Preliminary conceptual design Detailed design Code and debug Integrate and test Operation and maintenance
Barry W. Boehm. Software engineering. IEEE Transactions on Computers, C-25(12):1226-1241, December 1976.
The waterfall model
1. System (user) requirements: system user group identifies and develops the system level requirements in sufficiently complete details that preliminary software requirements can be specified. 2. Software Requirements: translation of the purposeful requirements identified in phase 1 into structural and functional requirements, focusing on the nature and style of the software being developed, the data and information that will be required, the required functionality, performance, interfaces. The resulting requirements are validated and a document is produced.
The waterfall model
3. Preliminary conceptual design: the requirements are converted into a preliminary design, including data structure, software architecture, identification of procedures and functions... 4. Detailed design: definition of the program modules and inter-modular interfaces, data format, detailed algorithms description etc. Output must allow a direct coding. 5. Code and debug: detailed design is "translated" into a programming language. The resulting code is debugged as much as possible.
The waterfall model
6. Integrate and test: the individual components of the software are integrated and the result is tested as a complete system. 7. Operations and maintenance: the system is installed, evaluated and put into production. Over time, the system is modified (maintained) to accommodate for better understood or novel requirements. In practice, the last phase can be several times longer (and more expensive) than the first six phases together.
The waterfall model
Transition from one phase to the next involves a formal review by the team and the costumer: a step of verification (the system built meets the requirements of that particular phase; ready to go to the next phase), and a step of validation (the system built is what the users wants) "build the system right (verification) and build the right system (validation)" In case of a serious problem, the process moves back up to the previous phase
Waterfall model: strengths
Some strengths of the waterfall model Well known, well mastered Easy to understand for everybody Provides structure for inexperienced and weak teams Provides requirements stability Allows the early detection of defects At some level, progress is easy to track
Waterfall model: weaknesses
Some weaknesses of the waterfall model Inherently linear sequential nature does not reflects the reality of software development All requirements must be known at the beginning, which is often not realistic Does not produce any result until the very end of the process Does not reflect the problem-solving nature of software development, phases being tied rigidly to activities No way to partition the system for delivery by pieces Gives a false impression of status and progress
When to use the waterfall
When the requirements are known upfront and the implementation of these requirements is very well understood When building a type of product for which experience exists and can be reused Release of a new version of a product with well defined and controlled changes. Porting a product on a different platform
The v-shaped model
Essentially a variation on the waterfall model, with emphasis on the planning and design of the testability of the system Testing of the system are planned and designed early in the early phases of the life cycle Activities are paired: Customer acceptance plan designed during the planning phase System integration plan developed during the analysis and design phase Etc.
The v-shaped model
Project and requirements planning Product requirements, specification analysis Architecture or high level design Detailed design Production, operation and maintenance System and acceptance testing Integration and testing
Unit testing
Coding
The v-shaped model
Project and requirement planning: determines the software requirements and how the resources of the organization will be allocated to meet them Product requirements and specification analysis: analysis of the software problem at hand, complete specification of the expected external behavior of the system to be built Architecture or high level design: overall architecture of the system Detailed design: defines and documents algorithms for each component that was designed during the architecture phase.
The v-shaped model
Coding: transforms detailed design into software Unit testing: checks each coded module for errors Integration and testing: interconnects the sets of previously unit-tested modules to ensure that the sets behave as well as the independently tested modules did during the unit-testing phase System and acceptance testing: system whether the entire software system in its actual environment behave according to the software requirements Production, operation and maintenance: put software into production and provide for enhancements and corrections
V-shaped model: strengths
Good planning for verification and validation of the software Encourage verification and validation of all internal and external deliverables, not just the software product Cf. waterfall
V-shaped model: weaknesses
Cf. waterfall
When to use V-shaped
Cf. Waterfall Systems that require high reliability
The prototyping model
One of the main issue with the previous models was the need to gather the requirements upfront. However, often, users are not able to provide detailed requirements upfront. Inferring requirements solely from the (presumably not ideal) current situation is not easy. The user is not a specialist with a good understanding of what can and what can't be done. It is often useful to vet an idea, to put it to work for a while before deciding whether or not the idea is actually a good one, or if it turns out to be impracticable or to have hidden problems.
The prototyping model
In other industries, prototypes are fairly routinely created . Prototypes are (partially) working implementation of a system (in the case of software) that are meant to give an opportunity to users and developers alike to test with and learn about the proposed solution. In prototyping, we are thus going to produce rapidly "somewhat working" versions of the some portion of the software before investing a lot of money and time into the final solution.
The prototyping model
First cycle of requirement engineering-designimplementation-testing aimed at producing quickly the initial prototype during the requirement definition phase End users and stakeholders experiment with the prototype. Loop on the cycle until satisfaction is reached. Final design is derived from the last prototyping iteration
The prototyping model
Throwaway prototypes are explicitly meant to be discarded once the evaluation is done. We can use very efficient technology to develop them, regardless of its suitability for the final product Evolutionary prototypes are prototypes that are meant to evolve into the final product. This calls for a more rigorous development during the prototyping steps. It is possible to mix both approach and reuse part of the prototypes
The prototyping model
Horizontal prototyping consists of trying to touch on most of the functionalities of the software, but in a rather superficial way. Vertical prototyping is about selecting very few functionalities, and implement them thoroughly. Throw away prototypes are rather used in an horizontal approach, and evolutionary ones in the vertical one, though this is not an absolute rule.
Prototyping model: strengths
The resulting system is much more likely going to be the right system: easier to use, actually addressing users needs New and unexpected requirements can be accommodated for Steady and visible signs of progress increases the confidence in the project all around Risk is controlled, less rework means lower costs User end satisfaction improved: no "bad surprise" Quality is built in (evolutionary model), documentation focuses on the final product End solution may have fewer unnecessary features, as users are less tempted to add them "just in case"
Prototyping model: weaknesses
The resulting system can be of lesser quality and poorer performance because of the rush to produce prototypes and the lack of global vision (evolutionary prototype) The user may not understand that a working prototype is not a final product and want to move into production too soon Final documentation is easily overlooked, as everybody knows the system already It may add more features, as the users gets more and more ideas It is easy to miss an important point (speed, complexity...) due to over simplification of the prototypes Number of iterations unknown upfront Not always adapted to the situation (particularly adapted to
When to use prototyping
When requirements are not known upfront, are unstable or require clarifications When developing user interface, proof of concepts, demonstration of feasibility When developing a very new system When there is uncertainty about best the solution When high risk project requires technical assessment In a pre-sale environment
Rapid Application Development
Characterized by a quick turnaround (the system is typically created in less than 60 days) and heavy end-user involvement at all stages Relies on heavy usage of good, high powered development tools allowing to create complex interconnected UI and databases with a few drag and drops. Heavily reuses software component inside the development environment and complete software application outside (spreadsheet, reporting tool etc.) A full development can involve several 60 days "time boxes"
RAD: strengths
Good usage of tools saves times and money, mitigates risks Quickly provides a working and usable solution, with enduser acceptance obtained en route Excellent component and tool re-use philosophy
RAD: weaknesses
Requires the involvement (and thus availability) of an end user Not always suitable, requires a certain type of project Requires a system that can be properly modularized Cost of the total system ("unbounded" number of time boxes) can be difficult to assess or predict
When to use RAD
System with reasonably well know, simple requirements System that can be easily highly modularized System that do not require high performances With skilled project teams, familiar with the problem domain and skilled in the use of the development tool
Incremental software model
Like evolutionary prototyping, incremental software development is a process of constructing a partial implementation of the final system and slowly adding increased functionalities, by increment In this model, each delivery is a complete, working, tested, documented solution that can be in production with a subset of the final functionalities The model calls for the prioritization of the requirements, creating groups that are going to be implemented in one increment Each increment is implemented using a model such as waterfall or V-shaped
Incremental software: strengths
Possibility to spread costs over a longer time frame, with some relative control on what you get when Delivery of an operational module with each increment Lessons learned, user experiences, general feedbacks can be used in the following increments, which is a less expensive way to refine and improve the product Possibility to adapt the size of an increment to the capacity of the available resources (divide and conquer) Initial delivery cheaper, faster, optimized to immediate needs Control over the scope, which improves adaptability to changes and possible control over scope creep
Incremental software: weaknesses
Model does not allow for iterations within each increment Increments are far better defined if a complete, fully functional system is defined early in the cycle Tendency to push difficulties to futures increments Does not lower the total cost "Tunnel vision" focusing on the current increment will, from time to time, lead to a flawed design: addition of the next "increment" will show that the previous one has a fatal problem
When to use incremental
When most requirement are know upfront but expected to evolve overtime When time to market is short When the risk is too high for a full blown development at once When feature needs can be prioritized in a somewhat balanced manner When a large technology gap is introduced and minimization of the disturbance is important
The spiral model
(Barry Boehm, 1988)
Removes the focus from coding or documentation, and put the emphasis on risk analysis and evaluation of alternatives The model can accommodate most models and allow for the combination of these models Each loop in the spiral focuses on one or more major risk using the best possible method for that circumstance. There is no set number of iterations, and each iteration goes through the same four quadrants
The spiral model
The spiral model
1.Objective setting: specific objectives for that phase are defined. Alternative means for implementing these objectives are determined. Constraints on the process and product are identified. Risks are identified and documented 2.Risk assessment and alternative evaluation: evaluation of the alternative identified. Detailed analysis is carried out for each of the identified risks. Go/no go decision. 3.Develop next level product: a development model is chosen and the "next level" is developed and validated 4.Plan next phase: review the project, decide whether or not another phase will be done, and if yes develop plans for it.
The spiral model: strengths
User sees the system early Provides early indication of high risk without involving large cost User is closely tied to planning and risk analysis activities Splits large effort into small chunks, with high risk ones addresses first. Expenses are reduced if the project must be abandoned. Allows to combine the strengths of the waterfall model and the flexibility of the incremental one No need for all the money upfront, and cumulative costs can be assessed frequently
The spiral model: weaknesses
Not suitable for small, low risk projects Model complex that may be difficult to use. Good risk assessment expertise required Developers must be re-assigned during the non development phases Lack of industry expertise Model itself can be expensive: a lot of time is spent planning, risk analyzing, prototyping etc. Project milestones and objectives can be hard to define
When to use the spiral model
When it is important to evaluate the cost during the project When risk is medium or high When a long term commitment upfront is unwise When project is large, unsure, new When tests of basic concepts are required, significant changes are expected
Agile development
Nowadays, a lot of emphasis is put on change, reactivity. A lot of focus is put the fact that we are in a "rapid pace" environment. Businesses are expecting rapid results, because they are themselves in rapidly moving businesses. In addition, a very large part of the software developed these days is not developed for huge systems on a mainframe. There is a lot of demand for smaller scale, end user oriented systems. The type of "heavyweight" approach that was championed until the 80's led to a lot of frustration for the programmers, that see it as completely inadequate to handle the type of development they were involved in. In the 90's, the notion of "agile development" emerged.
The Agile Manifesto (agilemanifesto.org)
Principles behind the Agile Manifesto. We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
The Agile Manifesto (2/3)
Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress.
The Agile Manifesto (3/3)
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Some Agile Methods
eXtreme Programming Dynamic Systems Development Model (DSDM) Feature Driven Development (FDD) Scrum. (See AgilePresentation.pdf)
Comparison of methods
From Futrell, R., Shafer, D. and Shafer L., Quality Software Project Management Examination of the projects characteristics by requirements, project team, user community and project type and risk.
Comparison: requirements
Requirements Are the requirements easily defined and/or well known? Can the requirements be defined early in the cycle? Will the requirements change often in the cycle? Is there a need to demonstrate the requirements to achieve definition? Is a proof of concept required to demonstrate capability? Do the requirements indicate a complex system? Is early functionality a requirement? Wat. Y Y N N N N N V Y Y N N N N N Prot. N N Y Y Y Y Y Spi. N N Y Y Y Y Y RAD Y Y N Y Y N Y Inc. N Y N N N Y Y
Comparison: project team
Project team Are the majority of the team members new to the problem domain for the project? Are the majority of the team members new to the technology domain for the project? Are the majority of the team members new to the tools to be used on the project? Are the team member subject to reassignment during the life cycle? Is there training available, if required? Is the team more comfortable with structure than flexibility? Wat. N Y Y N N Y V N Y Y N Y Y Prot. Y N N Y N N Spi. Y Y Y Y N N RAD N N N N Y N Inc. N Y N Y Y Y
Comparison: project team (2/2)
Project team Will the project manager closely track the team's progress? Is ease of resource allocation important? Does the team accept peer reviews and inspections, management/customer reviews and milestones? Wat. Y Y Y V Y Y Y Prot. N N Y Spi. Y N Y RAD N Y N Inc. Y Y Y
Comparison: Users
User community Will the availability of the user representative be limited? Are the user representatives new to the system definition? Are the user representatives experts in the problem domain? Do the users want to be involved in all phases of the life cycle? Does the customer want to track project progress? Wat. Y N N N N V Y N N N N Prot. N Y Y Y Y Spi. Y Y N N Y RAD N N Y Y N Inc. Y Y Y N N
Comparison: project type & risk
Project type and risk Does the project identify a new product direction for the organization? Is the project a system integration project? Is the project an enhancement to an existing system? Is the funding expected to be stable throughout the life cycle? Is the product expected to have a long life in the organization? Is high reliability a must? Is the system expected to be modified post deployment, in non anticipated ways? Wat. N N N Y Y N N V N Y Y Y Y Y N Prot. Y Y N Y N N Y Spi. Y Y N N Y Y Y RAD N Y Y Y N N N Inc. Y Y Y N Y Y Y
Comparison: project type & risk
Project type and risk Is the schedule constrained? Are the module interfaces clean? Are reusable components available? Are resources (time, money, tools, people) scarce? Wat. N Y N N V N Y N N Prot. Y N Y Y Spi. Y N Y Y RAD Y N Y N Inc. Y Y N N