There are tons of models, and many companies adopt their own, but all have very similarpatterns.Each phase produces deliverables required by the next phase in thelife cycle. Requirements are translated into design. Codeis producedduring implementation that is driven by the design. Testing verifies the deliverable of the implementation phase againstrequirements.RequirementsBusiness requirements are gathered in this phase. This phaseis the main focus of the project managers and stake holders. Meetings with managers, stake holders and users are held in order todetermine the requirements. Who is going to use the system? How will they use thesystem? What data should be input into thesystem? What data should be output by the system? These aregeneral questions that getanswered during a requirements gatheringphase. This produces a nice big list of functionality that thesystem should provide, which describes functions the system shouldperform, business logic that processes data, what data is stored andused by the system, and how theuser interface should work. Theoverall result is the system as a whole and how it performs, not how itis actually going to do it.DesignThe software system design is produced from the results of therequirements phase. Architects have the ball in their courtduring this phaseand this is the phase in which their focuslies. This is where the details on how the system will work isproduced. Architecture, includinghardware and software,communication, software design (UML is produced here) are all part ofthe deliverables of a design phase.ImplementationCode is produced from the deliverables of the design phase duringimplementation, and this is the longest phase of the softwaredevelopment life cycle. For a developer, this is the main focusof the life cycle because this is where the code is produced. Implementationmy overlap with both the design and testingphases. Many tools exists (CASE tools) to actually automate theproduction of code usinginformation gathered and produced during thedesign phase.TestingDuring testing, the implementation is tested against therequirements to make sure that the product is actually solving theneeds addressedand gathered during the requirements phase. Unittests and system/acceptance tests are done during this phase. Unit tests act on a specificcomponent of the system, while systemtests act on the system as a whole.So in a nutshell, that is a very basic overview of the generalsoftware development life cycle model.
Waterfall ModelThis is the most common and classic of life cycle models, alsoreferred to as a linear-sequential life cycle model. It is verysimple tounderstand and use. In a waterfall model, each phasemust be completed in its entirety before the next phase canbegin. At the end of each phase, a review takes place todetermine if the project is on the right path and whether or not tocontinue or discard the project. Unlikewhat I mentioned in thegeneral model, phases do not overlap in a waterfall model.
V-Shaped ModelJust like the waterfall model, the V-Shaped life cycle is asequential path of execution of processes. Each phase must becompleted beforethe next phase begins. Testing is emphasized inthis model more so than the waterfall model though. The testingprocedures are developedearly in the life cycle before any coding isdone, during each of the phases preceding implementation.Requirements begin the life cyclemodel just like the waterfallmodel. Before development is started, a system test plan iscreated. The test plan focuses on meeting thefunctionalityspecified in the requirements gathering.The high-level design phase focuses on system architecture anddesign. An integration test plan is created in this phase as wellin order to test the pieces of the software systems ability to worktogether.The low-level design phase is where the actual software componentsare designed, and unit tests are created in this phase as well.The implementation phase is, again, where all coding takesplace. Once coding is complete, the path of execution continuesup the right sideof the V where the test plans developed earlier arenow put to use.
Incremental ModelThe incremental model is an intuitive approach to the waterfallmodel. Multiple development cycles take place here, making thelife cycle a“multi-waterfall” cycle. Cycles are divided up intosmaller, more easily managed iterations. Each iteration passesthrough the requirements,design, implementation and testing phases.A working version of software is produced during the firstiteration, so you have working softwareearly on during the softwarelife cycle. Subsequent iterations build on the initial softwareproduced during the first iteration.Spiral ModelThe spiral model is similar to the incremental model, with moreemphases placed on risk analysis. The spiral model has fourphases: Planning, Risk Analysis, Engineering and Evaluation. Asoftware project repeatedly passes through these phases in iterations(called Spirals in this model). The baseline spiral, starting inthe planning phase, requirements are gathered and risk isassessed. Each subsequent spiralsbuilds on the baseline spiral.Requirements are gathered during the planning phase. In therisk analysis phase, a process is undertaken toidentify risk andalternate solutions. A prototype is produced at the end of therisk analysis phase.Software is produced in the engineering phase, along with testing atthe end of the phase. The evaluation phase allows the customer toevaluate the output of the project to date before the project continuesto the next spiral.In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.
Spiral ModelThe spiral model is similar to the incremental model, with moreemphases placed on risk analysis. The spiral model has fourphases: Planning, Risk Analysis, Engineering and Evaluation. Asoftware project repeatedly passes through these phases in iterations(called Spirals in this model). The baseline spiral, starting inthe planning phase, requirements are gathered and risk isassessed. Each subsequent spiralsbuilds on the baseline spiral.Requirements are gathered during the planning phase. In therisk analysis phase, a process is undertaken toidentify risk andalternate solutions. A prototype is produced at the end of therisk analysis phase.Software is produced in the engineering phase, along with testing atthe end of the phase. The evaluation phase allows the customer toevaluate the output of the project to date before the project continuesto the next spiral.In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.
What is Project Management? Necessary skills Software development project managementand related techniques Failure and Success Q&A4
“Go ahead and do it” approach Run the business / operations approach Project approach5
Project - Planned set of interrelated tasksto be executed over a fixed period andwithin certain cost and other limitations.◦ New Airplane◦ New Cell Phone◦ New Software6
Process planning and control Timely risk identification and mitigation Grater assurance in the positive result7
Project Management is the application ofknowledge, skills and techniques to executeprojects effectively and efficiently.◦ project management brings a unique focus shaped bythe goals, resources and schedule of each project.8
Until 1900 projects were managed as "go aheadand do it" by the chief engineers 1900 – 1950 – a transition period. Henry Ganttand Frederick Winslow Taylor developed thestructured processes and tools: WBS standing for“Work breakdown structure” and Gantt chart At 1950 project management became structured.Fields that could be considered as starting point:civil engineering and military IMPA – 1967 in Europe and PMI – 1969 in US9
Software Development Life Cycle - Software development lifecycle models describe phases of the software cycle andthe order in which those phases are executed: Waterfall model V-Shaped model Spiral model Incremental model Set of general project stages:13RequirementsDesign TransitionImplementation TestingInitiating Planning ExecutingMonitoring& ControlClosing
Advantages DisadvantagesSimple and easy to use.Easy to manage due to the rigidity of themodel – each phase has specificdeliverables and a review process.Phases are processed and completed oneat a time.Works well for smaller projects whererequirements are very well understood.- Adjusting scope during the life cycle can kill aproject- No working software is produced until late duringthe life cycle.- High amounts of risk and uncertainty.- Poor model for complex and object-orientedprojects.- Poor model for long and ongoing projects.- Poor model where requirements are at amoderate to high risk of changing.15
AdvantagesSimple and easy to useEach phase has specific deliverablesHigher chance of success over the waterfall modeldue to the development of test plans early on duringthe life cycleWorks well for small projects where requirements areeasily understoodDisadvantages- Very rigid, like the waterfall model- Little flexibility and adjusting scope is difficult andexpensive- Software is developed during the implementationphase, so no early prototypes of the software areproduced- Model doesn’t provide a clear path for problemsfound during testing phases16
Advantages DisadvantagesGenerates working software quickly and earlyduring the software life cycleMore flexible – less costly to change scope andrequirementsEasier to test and debug during a smalleriterationEasier to manage risk because risky pieces areidentified and handled during its iterationEach iteration is an easily managed milestone- Each phase of an iteration is rigid and do notoverlap each other- Problems may arise pertaining to systemarchitecture because notall requirements are gathered up front for theentire software lifecycle.17
AdvantagesHigh amount of risk analysisGood for large and mission-critical projectsSoftware is produced early in the software lifecycleDisadvantages- Can be a costly model to use- Risk analysis requires highly specific expertise- Project’s success is highly dependent on the riskanalysis phase- Doesn’t work well for smaller projects18
SW Projects typically failwhen:◦ People begin programmingbefore they understand theproblem◦ The team has an unrealisticidea about how much work isinvolved◦ Defects are injected early butdiscovered late◦ Programmers have poor habits– and they don’t feelaccountable for their work◦ Define Failure!!!20
How can we make sure a projectto succeed:◦ Make sure all decisions are based onopenly and timely sharedinformation◦ Don’t second-guess your teammembers’ expertise◦ Introduce software quality fromthe very beginning of the project◦ Don’t impose an artificial hierarchyon the project team◦ Remember that the fastest waythrough the project is to use goodengineering practices◦ Define sucess !!!21
Software Development Life Cycle Models, RaymondLewallen, 2005, http://codebetter.com/raymondlewallen/2005/07/13/software-development-life-cycle-models/ Applied Software Project Management, Andrew Stellman & JenniferGreene, 2005, http://www.stellman-greene.com/aspm/content/view/28/33/22