Presentation is loading. Please wait.

Presentation is loading. Please wait.

SE-381 Software Engineering

Similar presentations

Presentation on theme: "SE-381 Software Engineering"— Presentation transcript:

1 SE-381 Software Engineering
BEIT-V Lecture no. 11 Software Process Models – 3 of 4

2 Prototyping Model Can be used to clarify Requirements, to design User Interface, demonstrate feasibility, verify the new technology will work, or to provide a training system Cannot be used for embedded software, real-time control software or scientific or Engineering numerical computational software Tools 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 stage Customer plays with it and suggests needed amendments and developer incorporates them into the prototype User/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 Model Evolutionary Prototype Model Rapid or Throwaway Prototyping Model Uses rapid techniques to construct prototypes that are thrown away once users’ requirements have been established Evolutionary Prototyping Model Evolves the initial prototype into the final software as the requirements are clarified

5 Prototyping Model Pressman (1992) – SEPA3

6 Prototyping Model Problems & Real-life Different Types How Done
Prototyping is a historical technique of Engineering Discipline, Chemical Engg, Aerodynamics User not aware what he wants Developer not sure how good his Algorithms or Code would perform Client ignorant of expected output. Changes to come by use of the Sw Product Different Types Paper Prototype PC Based Screen layouts Software developed to initiate User Interaction with the system How Done Client & Developer meet and sort out Requirements A quick design Implementation Accommodation of user Feedback

7 Prototyping Model . Cons
The developed Prototype should not be taken as Product According 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 working Should be used as a tool for Requirement Phase Client be explained at the outset that after getting Prototype accepted the ‘Product’ will be re-engineered.

8 Rapid Prototyping Model

9 Jal05 – Prototyping Model

10 [Bel05] Throwaway Prototype Model

11 Rapid Prototyping Model
Pros A new model, using the developed Prototype as a Front-end to your SD process, to gather User Requirements, Clients’ experience with the Sw (Prototype) Insight to the Algorithms used and how efficient these are A tool/guide for all who are involved in SD of the product to improve their area Prototype used as A tool for Requirements phase Rest Follow the remaining phases linearly Iteration introduced by Maintenance phase, for Corrective Adaptive and Perfective changes

12 [Bel05] Evolutionary Prototype Model

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 system Evolutionary 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 Statement Write 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 Models The relevant parts of the above chapters to be read at home.

16 Software Process Models
Commonly used SDLC Models Build-n-Fix Model Classical and Water Fall Model Prototyping (Rapid and Evolutionary) Model Incremental Model Timeboxing Model Risk Based Models Spiral Model eXtreme Programming Synchronise and Stabilize Model Object Oriented Life Cycle Models - Fountain Model Unified Process Model Open Source Software Development Model

17 Incremental Model The Product is Real-life In this Model we
Artifacts or buildings, large projects are built incrementally In this Model we Design an Open-ended architecture in mind to support incremental growth Compile a “Project Control List” (PCL) containing all tasks or functions Different functions/parts supported in different ‘builds’ The Product is Designed, 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 capability Product goes through the cycle of Design, Implementation and Analysis In 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 Builds Design0 Designn Design1 . Implementation0 Implementationn Implementation1 Analysis0 Analysisn Analysis1 Build 0 Build 1 Build n Iterations

19 Incremental Model

20 Incremental Model .. Pros
Software Products are models of Real-life which is prone to Change, Incremental Model has in-built capability to handle change Early delivery of Operational product Smooth transition of Users of the Product from manual to automated system Simple and financially/functionally crucial builds can be developed earlier and complex ones later All, 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 models Well thought and flexible architectural design needed Each new build has to strengthen, co-exist and conform to the already built system Too 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 confusing Can 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 Build1 As 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 on The 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 builds What are possible problems?

23 Concurrent Incremental Model

24 SE-381 Software Engineering
BEIT-V Lecture no. 12 Software Development Life Cycle (SDLC) Models 4 of 4

25 Incremental or Iterative Enhancement Model Contd.
Douglas Bell 2005 has emphasized the implementation part of Incremental Model Architectural Design has to be done thoroughly and should be flexible and open ended Can be implemented using several approaches Top Down Approach Bottom Up Approach Middle Out Approach Use Case Based Approach The implementation approach to SD is like scaffolding to building construction


27 Scaffolding provides Support to structure and Access to structure, like an Arch Stone in an Arch, similarly Test bed has to provide support and Access to the Sw components Test 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 environment Stubs are dummies, written with the same interface and name, for the program components which are still not ready

28 Top Down Approach for Software Development

29 Bottom Up Approach for Software Development - 1

30 Bottom Up Approach for Software Development - 2

31 Use Case Based Approach
Middle Out Approach We 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 Approach We 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 years Slow and productive transition of users/clients working environment with the evolution of developed product Phased 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 Model Too many builds will waste more time on Integration testing, and blur configuration boundaries Open 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 builds Concurrent 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 iteration Time boxing – fix an iteration duration, then determine the specs Divide iteration in a few equal stages Use pipelining concepts to execute iterations in parallel

35 Time Boxed Iterations General iterative development – fix the functionality for each iteration, then plan and execute it In time boxed iterations – fix the duration of iteration and adjust the functionality to fit-in Completion time is fixed, the functionality to be delivered is flexible

36 Time boxed Iteration Useful in many situations
Has predictable delivery times Overall product release and marketing can be better planned Makes time a non-negotiable parameter and helps focus attention on schedule Prevents requirements bloating / freezing Overall 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 parallel Can reduce the average completion time by exploiting parallelism For parallel execution, can borrow pipelining concepts from hardware This leads to Timeboxing Process Model

38 Timeboxing Model – Basics
Development is done iteratively in fixed duration time boxes Each time box divided in fixed stages Each stage performs a clearly defined task that can be done independently Each stage approximately equal in duration There is a dedicated team for each stage When one stage team finishes, it hands over the project to the next team

39 Timeboxing With this type of time boxes, can use pipelining to reduce cycle time Like hardware pipelining – view each iteration as set of instructions being executed on an artifact As 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 situations Can adjust durations by determining the boundaries suitably Can adjust duration by adjusting the team size for each stage Have 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-2 AT 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)

42 Timeboxing Execution

43 Timeboxing execution First iteration finishes at time T
Second finishes at T+T/3; third at T+2 T/3, and so on In steady state, delivery every T/3 time If 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 same Productivity of a time box is same Yet, average cycle time or delivery time has reduced to a third

45 Team Size In linear execution of iterations, the same team performs all stages If each stage has a team of size S, in linear execution the team size is S In 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 Size Merely by increasing the team size we cannot reduce cycle time - Brook’s law Time boxing allows structured way to add manpower to reduce cycle time Note that we cannot change the time of an iteration – Brook’s law still holds Work allocation different to allow larger team to function properly

47 Work Allocation of Teams

48 Timeboxing Advantages: Shortened delivery times, other advantage of iterative and distributed execution Disadvantages: Larger teams, project mgmt is harder, high synchronization needed, Configuration Management is harder Applicability: When short delivery times is emphasized; Architecture is stable; Flexibility in feature grouping is possible

49 Summary Process is a means to achieve project objectives of high Quality and Productivity Process models define generic process, which can form basis of project process Process typically has stages, each stage focusing on an identifiable task Many models for development process have been proposed

50 Summary – waterfall Strength Weakness Types of Projects Simple
Easy to execute Intuitive and logical Easy to sign contracts All or nothing – too risky Requirements frozen early May choose outdated hardware/technology Disallows changes No feedback from users Encourages requirem-ents bloating Well understood problems, short duration projects, automation of existing manual systems

51 Summary – Prototyping Strength Weakness Types of Projects
Helps Requirements elicitation Stabilized User Requirements Reduces risk Better and more stable final system Front heavy Possibly higher cost and schedule Disallows later change Encourages requirements bloating Systems 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 benefit Can accommodate changes naturally Allows user feedback Avoids req bloating Naturally prioritizes req Allows reasonable exit points Reduces risks Overhead of planning each iteration Total cost may increase System architecture and design may suffer Rework may increase For 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 iterative Planning for iterations somewhat easier Very short delivery times PM becomes more complex Team size is larger Complicated – lapses can lead to losses Where very short delivery times are very important Where there is flexibility in grouping features Architecture 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 Models The 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 Model eXtreme Programming Synchronise and Stabilize Model Unified Process Model Open 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 Models The relevant parts of the above chapters to be read at home.

Download ppt "SE-381 Software Engineering"

Similar presentations

Ads by Google