Presentation on theme: "SE-381 Software Engineering"— Presentation transcript:
1 SE-381 Software Engineering BEIT-VLecture no. 11Software Process Models – 3 of 4
2 Prototyping ModelCan be used to clarify Requirements, to design User Interface, demonstrate feasibility, verify the new technology will work, or to provide a training systemCannot be used for embedded software, real-time control software or scientific or Engineering numerical computational softwareTools for developing good quick prototypes are scarce, some HLLs are providing routine libraries, whereas systems like Smalltalk could not survive or capture market
3 Prototyping Model Ensures that customer gets what s/he wanted Customer is provided a working version of software i.e. prototype at a very early stageCustomer plays with it and suggests needed amendments and developer incorporates them into the prototypeUser/customer needs/requirements are thus refined and defined, and the software could be developed using these requirements
4 Prototyping Model Prototyping Model could be of two types: Rapid or Throwaway prototype ModelEvolutionary Prototype ModelRapid or Throwaway Prototyping ModelUses rapid techniques to construct prototypes that are thrown away once users’ requirements have been establishedEvolutionary Prototyping ModelEvolves the initial prototype into the final software as the requirements are clarified
6 Prototyping Model Problems & Real-life Different Types How Done Prototyping is a historical technique of Engineering Discipline, Chemical Engg, AerodynamicsUser not aware what he wantsDeveloper not sure how good his Algorithms or Code would performClient ignorant of expected output. Changes to come by use of the Sw ProductDifferent TypesPaper PrototypePC Based Screen layoutsSoftware developed to initiate User Interaction with the systemHow DoneClient & Developer meet and sort out RequirementsA quick designImplementationAccommodation of user Feedback
7 Prototyping Model . Cons The developed Prototype should not be taken as ProductAccording to Brooks 1975, it should be a ‘Throwaway Version’ of the product but is it possible?Customer Pressure to take Prototype as Product, and Developer Shortcuts to get the Prototype workingShould be used as a tool for Requirement PhaseClient be explained at the outset that after getting Prototype accepted the ‘Product’ will be re-engineered.
11 Rapid Prototyping Model ProsA new model, using the developed Prototype as a Front-end to your SD process, to gatherUser Requirements,Clients’ experience with the Sw (Prototype)Insight to the Algorithms used and how efficient these areA tool/guide for all who are involved in SD of the product to improve their areaPrototype used asA tool for Requirements phaseRest Follow the remaining phases linearlyIteration introduced byMaintenance phase, forCorrectiveAdaptive andPerfective changes
13 Evolutionary Versus Rapid Prototypes Rapid Prototypes start from incomplete specifications, go through a ‘quick’ design and development and these are improved on users’ or clients’ response. The final output is the clarified Requirements. These are used to develop the systemEvolutionary Prototypes start from initial specifications, designed thoroughly and incorporate the users’/clients’ response. The evolved system turns out to be the final system
14 Prototyping Model – An Example Problem StatementWrite a software program that can check the general knowledge of a user, specifically his/her knowledge about geography and history of Indo-Pakistan.This is to be used by general public, so its implementation in national language will be preferred.
15 References[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping[Jal97] Pankaj Jalote (1997); An Integrated Approach to Software Engineering; 2nd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle ModelsThe relevant parts of the above chapters to be read at home.
16 Software Process Models Commonly used SDLC ModelsBuild-n-Fix ModelClassical and Water Fall ModelPrototyping (Rapid and Evolutionary) ModelIncremental ModelTimeboxing ModelRisk Based ModelsSpiral ModeleXtreme ProgrammingSynchronise and Stabilize Model Object Oriented Life Cycle Models - Fountain ModelUnified Process ModelOpen Source Software Development Model
17 Incremental Model The Product is Real-life In this Model we Artifacts or buildings, large projects are built incrementallyIn this Model weDesign an Open-ended architecture in mind to support incremental growthCompile a “Project Control List” (PCL) containing all tasks or functionsDifferent functions/parts supported in different ‘builds’The Product isDesigned, implemented, integrated and tested as series of incremental ‘Builds’ where a build consists of code pieces from various modules interacting to provide a specific functional capabilityProduct goes through the cycle of Design, Implementation and AnalysisIn Analysis you decide what is to be included from PCL into the next build or Iteration
18 Incremental or Iterative Process Formulate Project Control List (PCL)Decide the Contents of Different BuildsDesign0DesignnDesign1.Implementation0ImplementationnImplementation1Analysis0AnalysisnAnalysis1Build 0Build 1Build nIterations
20 Incremental Model .. Pros Software Products are models of Real-life which is prone to Change, Incremental Model has in-built capability to handle changeEarly delivery of Operational productSmooth transition of Users of the Product from manual to automated systemSimple and financially/functionally crucial builds can be developed earlier and complex ones laterAll, to be supported tasks, are listed, prioritized and high priority tasks are put in earlier builds and more complex tasks are included in later builds (Millers law – At any one time, we humans are capable of concentrating on 5 ± 2 chunks of information 1956)Lesser financial burden on the client as it is developed and delivered incrementally, the benefits from use of the product start pouring in early
21 Incremental Model … Cons Incomplete system as compared to well tested/documented product produced by WF or RP modelsWell thought and flexible architectural design neededEach new build has to strengthen, co-exist and conform to the already built systemToo many builds may blur the boundaries or configurations of the product and can loosen the developers control on the product, whereas too few builds can also transform the model to Build-n-fix or Waterfall model by de-linking the development process from the client for a longer time. Hence a balance on number of builds is to be maintained.Two different views for Design and Development are confusingCan the skill-set specific to different phases be shared ?
22 Incremental Model ….Skill-set specific to different phases can be shared!After Requirements and specification, a team can be assigned to specify the Build1As they finish the Specification of Build 1, the second team can be assigned to Design Build 1, and the first team can start specifying Build 2, and so onThe work on multiple Builds can be taken in Parallel, and experience/skills learnt by the teams from previous Builds can be used in the development of subsequent buildsWhat are possible problems?
24 SE-381 Software Engineering BEIT-VLecture no. 12Software Development Life Cycle (SDLC) Models4 of 4
25 Incremental or Iterative Enhancement Model Contd. Douglas Bell 2005 has emphasized the implementation part of Incremental ModelArchitectural Design has to be done thoroughly and should be flexible and open endedCan be implemented using several approachesTop Down ApproachBottom Up ApproachMiddle Out ApproachUse Case Based ApproachThe implementation approach to SD is like scaffolding to building construction
27 Scaffolding providesSupport to structure andAccess to structure, like an Arch Stone in an Arch, similarlyTest bed has to provide support and Access to the Sw componentsTest Beds, Test Drivers or Test Harnesses/Oracles are the programs which are used to call the other component programs so as if these are called and used in the actual environmentStubs are dummies, written with the same interface and name, for the program components which are still not ready
29 Bottom Up Approach for Software Development - 1
30 Bottom Up Approach for Software Development - 2
31 Use Case Based Approach Middle Out ApproachWe take components from the middle of the hierarchy (Architectural Design) and develop and test them and then their related ones and so proceed on.Use Case Based ApproachWe write Use Cases for the respective system and start developing Use Case by Use Case‘Use Case’ is Usage Case, how the user will be interacting with the system, and usually it is the implementation of some Functional Requirement of the system.
32 Incremental Model Pros Product is made available (though with limited functionality) within weeks as compared to Waterfall or Rapid Prototyping Models output which might take months or yearsSlow and productive transition of users/clients working environment with the evolution of developed productPhased delivery relieves client from high initial capital costs and gives higher RoI (Return on Investment) due to early use of product
33 Incremental Model Cons Too few builds degenerate the Incremental Model into Build-n-Fix model or WF ModelToo many builds will waste more time on Integration testing, and blur configuration boundariesOpen ended Architectural Design needed for required flexibility, demands expertise which is scarce,More effort is required to support all sorts of maintenance and extension in the later buildsConcurrent Incremental model is risky, more than one builds constructed simultaneously without stabilising the lower level builds.
34 Timeboxing Is iterative, has linear sequence of iterations Each iteration is a mini waterfall – decide the specs, then plan the iterationTime boxing – fix an iteration duration, then determine the specsDivide iteration in a few equal stagesUse pipelining concepts to execute iterations in parallel
35 Time Boxed IterationsGeneral iterative development – fix the functionality for each iteration, then plan and execute itIn time boxed iterations – fix the duration of iteration and adjust the functionality to fit-inCompletion time is fixed, the functionality to be delivered is flexible
36 Time boxed Iteration Useful in many situations Has predictable delivery timesOverall product release and marketing can be better plannedMakes time a non-negotiable parameter and helps focus attention on schedulePrevents requirements bloating / freezingOverall development time is still unchanged, instead improved i.e. cycle time reduced
37 Timeboxing Model – Taking Time Boxed Iterations Further What if we have multiple iterations executing in parallelCan reduce the average completion time by exploiting parallelismFor parallel execution, can borrow pipelining concepts from hardwareThis leads to Timeboxing Process Model
38 Timeboxing Model – Basics Development is done iteratively in fixed duration time boxesEach time box divided in fixed stagesEach stage performs a clearly defined task that can be done independentlyEach stage approximately equal in durationThere is a dedicated team for each stageWhen one stage team finishes, it hands over the project to the next team
39 TimeboxingWith this type of time boxes, can use pipelining to reduce cycle timeLike hardware pipelining – view each iteration as set of instructions being executed on an artifactAs stages have dedicated teams, simultaneous execution of different iterations is possible
40 Example An iteration with three stages – Analysis, Build, Deploy These stages are approximately equal in many situationsCan adjust durations by determining the boundaries suitablyCan adjust duration by adjusting the team size for each stageHave separate teams for A - Analysis, B - Build, and D - Design
41 Pipelined Execution AT (Analysis Team) starts executing it-1 AT finishes, hands over it-1 to BT (Build Team), starts executing it-2AT finishes it-2, hands over to BT; BT finishes it-1, hands over to DT (Design Team); AT starts it-3, BT starts it-2 (and DT, it-1)…
43 Timeboxing execution First iteration finishes at time T Second finishes at T+T/3; third at T+2 T/3, and so onIn steady state, delivery every T/3 timeIf T is 3 weeks, first delivery after 3 wks, 2nd after 4 wks, 3rd after 5 wks,…In linear execution, delivery times will be 3 wks, 6 wks, 9 wks,…
44 Timeboxing execution Duration of each iteration still the same Total work done in a time box is also the sameProductivity of a time box is sameYet, average cycle time or delivery time has reduced to a third
45 Team SizeIn linear execution of iterations, the same team performs all stagesIf each stage has a team of size S, in linear execution the team size is SIn pipelined execution, the team size is three times (one for each stage)That is, the total team size in timeboxing is larger; and this reduces cycle time
46 Team SizeMerely by increasing the team size we cannot reduce cycle time - Brook’s lawTime boxing allows structured way to add manpower to reduce cycle timeNote that we cannot change the time of an iteration – Brook’s law still holdsWork allocation different to allow larger team to function properly
48 TimeboxingAdvantages: Shortened delivery times, other advantage of iterative and distributed executionDisadvantages: Larger teams, project mgmt is harder, high synchronization needed, Configuration Management is harderApplicability:When short delivery times is emphasized;Architecture is stable;Flexibility in feature grouping is possible
49 SummaryProcess is a means to achieve project objectives of high Quality and ProductivityProcess models define generic process, which can form basis of project processProcess typically has stages, each stage focusing on an identifiable taskMany models for development process have been proposed
50 Summary – waterfall Strength Weakness Types of Projects Simple Easy to executeIntuitive and logicalEasy to sign contractsAll or nothing – too riskyRequirements frozen earlyMay choose outdated hardware/technologyDisallows changesNo feedback from usersEncourages requirem-ents bloatingWell understood problems, short duration projects, automation of existing manual systems
51 Summary – Prototyping Strength Weakness Types of Projects Helps Requirements elicitationStabilized User RequirementsReduces riskBetter and more stable final systemFront heavyPossibly higher cost and scheduleDisallows later changeEncourages requirements bloatingSystems with novice users; or areas with requirements uncertainty.Heavy reporting based systems can benefit from UI prototypes
52 Summary – Iterative Strength Weakness Types of Projects Regular deliveries, leading to business benefitCan accommodate changes naturallyAllows user feedbackAvoids req bloatingNaturally prioritizes reqAllows reasonable exit pointsReduces risksOverhead of planning each iterationTotal cost may increaseSystem architecture and design may sufferRework may increaseFor businesses where time is important;risk of long projects cannot be taken; Requirements not known and evolve with time
53 Summary – Timeboxing Strength Weakness Types of Projects All benefits of iterativePlanning for iterations somewhat easierVery short delivery timesPM becomes more complexTeam size is largerComplicated – lapses can lead to lossesWhere very short delivery times are very importantWhere there is flexibility in grouping featuresArchitecture is stable
54 References[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping[Jal97/05] Pankaj Jalote (1997,2005); An Integrated Approach to Software Engineering; 2nd /3rd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle ModelsThe relevant parts of the above chapters to be read at home.
55 Assignment no 2 Deadline to be handed in on Oct 15, 2012 (Monday) Individual Assignment, 3-paged preferably hand-written, Cheated will earn Zero marks, delayed submissions will loose 1 mark per delayed working day, will be evaluated by viva, if required.Choose the topic on the basis of your registration no, [mod(Reg#,5)+1=n where n has a value given below]Spiral ModeleXtreme ProgrammingSynchronise and Stabilize ModelUnified Process ModelOpen Source Software Development Model
56 References[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping[Jal97] Pankaj Jalote (1997); An Integrated Approach to Software Engineering; 2nd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle ModelsThe relevant parts of the above chapters to be read at home.
Your consent to our cookies if you continue to use this website.