SE-381
Software Engineering
BEIT-V
Lecture no. 5
Software Engineering Processes
1 of 3
Quality Product
• For a quality software product, both the
quality of product itself and quality of
software process are i...
Boehm 1987 - ‘Industrial Sw Metrics Top 10 List’
1. Finding and fixing a Sw problem after delivery, costs 100 times more t...
Pareto Analysis or Principle
In any series of elements to be controlled, a
selected, small fraction, in terms of the
numbe...
Pareto Analysis or Principle implies
• Focus on the problem and try to identify “the vital or
significant few versus the t...
– A detailed analysis of patients revealed that 80% of common diseases,
like fever, cough, cold etc are ‘minor’ diseases a...
Maintenance Aspects
– 1970s Development-then-Maintenance Model
+ Well defined two stages
- Changing Application Environmen...
• For every 1$ spent on development, 2$s are spent on
maintenance
• In 1992, 60%-80% of R & D staff at HP was involved in
...
Failure Curve for Hardware
Software doesn’t wear out but it deteriorates
Idealized and Actual Failure
Curve for Software
Increased Failure rate due to side effects and corrections or bug fixes ma...
Software Process
Is a set of activities and associated results which produce a
Software Product. These activities are carr...
Software Process ..
To introduce visibility in the process different graphical
notations are used to produce different des...
Software Process and Its Components
Software Process
Product
Engineering
Processes
Process
Management
Process
Development
...
Characteristics of Software Process
• Process should be
– Predictable
– Support Testability and Maintainability
– Support ...
SE-381
Software Engineering
BEIT-V
Lecture no. 6
Software Engineering Processes
2 of 3
Software Paradigms
• Classical or Structured Paradigm
• Data Structures and Behavior is loosely connected
• Data Structure...
• Object Oriented Paradigm
• Is a new way of thinking about problems using models organized
around real-world concepts
• F...
Client, User & Developer
• Client
Who initiates and pays for the product and effort
incurred therein, can be a person or a...
Personal / Groups Involved in SD
• Developers
Software Analysts, Architects, Designers,
Programmers or Coders, Testers, Do...
• SQA Division or Section
Solely responsible for assuring quality of the produced
products, directly reporting to CEO. Has...
Re-Cap
• For efficiency and cost effectiveness
– Software should be developed using a phased process
– Testing and Mainten...
Desired Process Properties
• Provide high Quality and Productivity (Q&P)
– Support testability as testing is the most expe...
ETVX Specification
• ETVX approach is to specify at each phase or
step
– Entry criteria: what conditions must be satisfied...
ETVX approach
Testing at Different Phases of
Software Development
• Main Testing Types
Testing could be of Two Types; Non-executable
and...
Requirements Phase
• Input
– Clients (and Users) tell what
they want
– Client’s description of project
– Meetings to under...
Requirements Phase
• Do
– Clarify the constraints, refine
‘What Client wants’ and ‘what
is needed’
– Meetings with develop...
Specification Phase
• Input
– Requirements Doc
• Goal
– Specification Doc should
explicitly describe
• Functionality
• Con...
Specification Phase
• Do
– Consult Client whenever
needed to clarify the
requirements
– Write clearly avoiding
mentioned p...
SE-381
Software Engineering
BEIT-V
Lecture no. 7
Software Engineering Processes
3 of 3
Planning Phase
• Input
– Specification Doc
– Resources Available
– Organizational structure
– SDLC,CASE Tool, Detailed
Sch...
Planning Phase
• Outputs
– Major Components of the
product,
• Milestones / Gantt Charts
• Time & Cost Budget
• Deliverable...
Design Phase
The Most Important Phase
– Specification describes
‘What’ and Design tells
‘How’ the functionality can
be pro...
Design Phase
• Design has 2 or 3 Parts
– Architectural Design
• Break Down of System into
Subsystems, Components and
modul...
Implementation Phase
• Input
– Detailed Design for all the
modules
– Test Cases for the
respective modules
• How to Do
– C...
Integration Phase
• Input
– Specifications of
Modules, Subsystems,
and System; Test Cases,
Structure Chart(s),
Modules’ Co...
Maintenance Phase
• Maintenance starts after
delivery!!
• But
– Maintenance must be kept in
focus while Designing/Coding
…...
Retirement Phase
• When to Retire?
– Further Maintenance is not
Cost-effective
– Write-Only code
– The documentation has
r...
References / Reading Assignment
[Jal97/05] Pankaj Jalote (1997,2005); An Integrated Approach
to Software Engineering; 2nd ...
SE-381
Software Engineering
BEIT-V
Lecture no. 8
Software Process Models
1 of 3
Software Process Models
– Software Development
• Needs to be performed in a series of well-defined steps, so
that the proc...
Some Software Process Models
– Build-n-Fix Model
– Classical Waterfall Model and its variants
– Prototyping Models
• Rapid...
Build and Fix Model
• Pros
– Simplest
– Used by students for
classroom assignments
– Build-use-modify-use-modify
cycle continues until client ...
Waterfall Model
• Pros
– Oldest, Since 1970s
– Found by Winston Royce in
1970
– Most Widely used (in
Aerospace Industry, e...
Waterfall Model
Many organizations still cling to the waterfall model because, even
with its shortfalls, it provides the m...
Classical Waterfall Model
Stage-wise Inputs / Outputs
Waterfall Model with Inter-stage
Feedback
Jal97 – Waterfall Model
Waterfall Model
Waterfall Model .
• Problems
– Real-life systems don’t
work in a simple sequential
mode (so Iterations
implemented)
– Prob...
Waterfall Model ..
Thus limitations of WF model are:
– Requirements of a system are frozen before design begins; could
wor...
Prototyping Model
• Can be used to clarify Requirements, to design Use
Interface, demonstrate feasibility, verify the new
...
Prototyping Model
• Ensures that customer gets what s/he wanted
• Customer is provided a working version of software i.e.
...
Prototyping Model
Prototyping Model could be of two types:
• Rapid or Throwaway prototype Model
• Evolutionary Prototype M...
Prototyping Model
Pressman (1992) –
Prototyping Model
• Problems & Real-life
– Prototyping is a historical
technique of Engineering
Discipline, Chemical Engg,...
Prototyping Model .
• Cons
• The developed Prototype should not be taken as Product
• According to Brooks 1975, it should ...
Rapid Prototyping Model
Jal97 – Prototyping Model
[Bel05] Throwaway Prototype Model
Rapid Prototyping Model
• Pros
– A new model, using
the developed
Prototype as a Front-
end to your SD
process, to gather
...
[Bel05] Evolutionary Prototype Model
Evolutionary Versus Rapid Prototypes
– Rapid Prototypes start from incomplete specifications,
go through a ‘quick’ design ...
Prototyping Model – An Example
Problem Statement
Write a software program that can check the
general knowledge of a user, ...
References
[Bel05] Douglas Bell (2005); Software Engineering for Students,
4th Edition, Pearson Education, New Delhi – Ch ...
Beit 381 se lec 5, 6, 7 & 8 - 69 - 12 feb21,22,28,29  - sw process 1-3 sdlc models
Beit 381 se lec 5, 6, 7 & 8 - 69 - 12 feb21,22,28,29  - sw process 1-3 sdlc models
Beit 381 se lec 5, 6, 7 & 8 - 69 - 12 feb21,22,28,29  - sw process 1-3 sdlc models
Beit 381 se lec 5, 6, 7 & 8 - 69 - 12 feb21,22,28,29  - sw process 1-3 sdlc models
Beit 381 se lec 5, 6, 7 & 8 - 69 - 12 feb21,22,28,29  - sw process 1-3 sdlc models
Upcoming SlideShare
Loading in …5
×

Beit 381 se lec 5, 6, 7 & 8 - 69 - 12 feb21,22,28,29 - sw process 1-3 sdlc models

841 views

Published on

Software Engineering, Lectures

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

  • Be the first to like this

No Downloads
Views
Total views
841
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Beit 381 se lec 5, 6, 7 & 8 - 69 - 12 feb21,22,28,29 - sw process 1-3 sdlc models

  1. 1. SE-381 Software Engineering BEIT-V Lecture no. 5 Software Engineering Processes 1 of 3
  2. 2. Quality Product • For a quality software product, both the quality of product itself and quality of software process are important. • The cost of error recovery in the later phases of software is many times more than in earlier phases, so more attention should be paid in the earlier phases, and these should be made error-free.
  3. 3. Boehm 1987 - ‘Industrial Sw Metrics Top 10 List’ 1. Finding and fixing a Sw problem after delivery, costs 100 times more than finding and fixing the problem in early design phases 2. You can compress Sw development schedule 25% of nominal, but no more 3. For every $1 you spend on development, you will spend $2 on maintenance 4. Sw Development and maintenance costs are primarily a function of the number of SLOC or DLOC – Delivered Lines of Code 5. Variations among people account for the biggest differences in Sw productivity 6. The overall ratio of Sw : Hw costs is still growing, in 1955 it was 15:85, in 1985, 85:15 {and in 2011 it is almost 95:5} 7. Only 1/6th or about 15 -16% of sw development effort is devoted to programming 8. Sw products typically cost 3 times as much per SLOC as individual Sw programs, Sw systems (i.e. system of systems) cost 9 times as much Sw programs (Sw pgm : Sw Product : Sw Sys :: 1:3:9) 9. Walkthroughs catch 60% of the errors 10. 80% of the contribution comes from 20% of the contributors – Corollary of Pareto Law
  4. 4. Pareto Analysis or Principle In any series of elements to be controlled, a selected, small fraction, in terms of the numbers of elements, always accounts for a large fraction in terms of effect. – Vilfredo Pareto (1848-1923) – an economist and sociologist
  5. 5. Pareto Analysis or Principle implies • Focus on the problem and try to identify “the vital or significant few versus the trivial many” • Few examples – Only a small percentage of the thousands of inventory items in a department store account for 80% of the dollar sales (large stores capitalize on this) – Less than10% of employees in an organization will account for most of the absenteeism – A few percent of the kinds of illnesses are the cause of admission for a great majority of hospital patients – Steve M Erickson (1981); Management Tools for Everyone: Twenty Analytical Techniques That Are Easy to Learn and Valuable to Know; Petrocelli Books Inc. New York, USA
  6. 6. – A detailed analysis of patients revealed that 80% of common diseases, like fever, cough, cold etc are ‘minor’ diseases and can be cured by educating masses about hygiene – Dr Ijaz Bashir, Chairman, Decent Welfare Society, Gujrat, Pakistan – Sept 2010 – Some figures from Proceedings of the Seminar on CORPORATE AGRICULTURE: ISSUES & OPTIONS; UAAR (2001) • 93% people own 37% of the land whereas the rest 7% own 63% of the land • Over 80% of the farmers either own less than 2 hectors of land or are landless tenants • Over 70% of the land holdings are below 12.5 acres • Less than 6% own over 60 hectors of land • 1 Hectare = 10,000 m2 and 1 acre = 4840 Yards2 = 4047 m2
  7. 7. Maintenance Aspects – 1970s Development-then-Maintenance Model + Well defined two stages - Changing Application Environments - Every product developed from Scratch - No reuse – Maintenance is a process that occurs when ‘Software undergoes modifications to code and associated documentation due to a problem or the need of improvement or adaptation’ [ISO/IEC ‘95]
  8. 8. • For every 1$ spent on development, 2$s are spent on maintenance • In 1992, 60%-80% of R & D staff at HP was involved in Maintenance, and Maintenance constituted 40-60% of the total cost of Software [Colman et al 1994] • Organizations devote upto 80% of their time and effort to maintenance [Yourdon 1996] • Maintenance is an extreme phase, so techniques efficient for Maintenance result in overall saving Maintenance Aspects (Contd.)
  9. 9. Failure Curve for Hardware Software doesn’t wear out but it deteriorates
  10. 10. Idealized and Actual Failure Curve for Software Increased Failure rate due to side effects and corrections or bug fixes made Software Engineering methods strive to reduce the magnitude of the spikes and the slope of the actual curve
  11. 11. Software Process Is a set of activities and associated results which produce a Software Product. These activities are carried out (mostly) by humans, using different tools (including CASE tools) and predefined methods. The main four fundamental activities which are common to all Sw processes are: Specification, Development, Validation and Evolution. There exist a number of Sw Processes, initiated by different individuals and organizations. Different processes can be used to develop the same product, but they do have their own specificities. Software Processes
  12. 12. Software Process .. To introduce visibility in the process different graphical notations are used to produce different design documents. Since different methods have different origins, so these are different and have different notations for their deliverable documents. Now effort is being made to unify them. Different metrics have been devised to control and optimize the software process to produce ‘Quality’ product. Paradigm or Methodology Is collection of consistent methods used to support all activities or phases of software development life cycle. Each phase being the part of the process, has its own inputs and deliverables, so these need to conform, semantically and as well as in notations.
  13. 13. Software Process and Its Components Software Process Product Engineering Processes Process Management Process Development Process Project Management Process Software Configuration Process
  14. 14. Characteristics of Software Process • Process should be – Predictable – Support Testability and Maintainability – Support Change – Early Error or Defect Removal – Process Improvement and Feedback
  15. 15. SE-381 Software Engineering BEIT-V Lecture no. 6 Software Engineering Processes 2 of 3
  16. 16. Software Paradigms • Classical or Structured Paradigm • Data Structures and Behavior is loosely connected • Data Structures are identified using Entity Relationship and Attribute Analysis • Behavior of the system is understood by analyzing the data flow with in the system, among different data structures. Data Flow Diagrams are used to portray this transition of data • Functions performed by the system are resolved into different strongly-cohesive and loosely-coupled modules • Modules and their interaction are presented in Structure Charts, and their functionality is written in un-ambiguous ‘structured English’ • The system is considered as a whole – one lump.
  17. 17. • Object Oriented Paradigm • Is a new way of thinking about problems using models organized around real-world concepts • Fundamental construct is Object, which combines Data structure and behavior in one entity (Encapsulation) • Software is collection of discrete objects • OO approach exploits the four characteristics – Identity, Classification, Polymorphism and Inheritance • Users functional requirements are represented thru Use Case Diagrams, Classification of objects represented using Class Diagrams, interaction of different objects and Classes is shown using Sequence Diagrams, all activities are shown using Activity Diagrams, etc. • There are different methodologies which support OO paradigm for all/some phases of software development • Object Modeling Technique (OMT) is one such methodology which supports from Requirement phase thru Design and Implementation phases to Maintenance phase of the SDLC Software Paradigms .
  18. 18. Client, User & Developer • Client Who initiates and pays for the product and effort incurred therein, can be a person or an organization • User Person(s) who will be using the product, on Client’s behalf • Developer Person(s) involved in any of the phases of software development, from Analysis to Implementation and Testing
  19. 19. Personal / Groups Involved in SD • Developers Software Analysts, Architects, Designers, Programmers or Coders, Testers, Document Writers etc • Project Managers Looking after the execution of software project, it includes planning, monitoring and control and termination phases • Configuration Controllers Involved in Configuration Control or Sw Configuration Management Process
  20. 20. • SQA Division or Section Solely responsible for assuring quality of the produced products, directly reporting to CEO. Has qualified members having expertise in all Software development areas • SQA Group Software Quality Assurance group will be responsible for assuring quality of the product at a particular phase or stage. Depending upon product size, its composition (and size) could vary for each phase, must of at least 4-5 members, representatives from Client, previous stage, current stage and next stage, should be headed by an experienced person from SQA division • Software Engineering Process Group (SEPG) Involved in managing the managing the Process Management Process activities
  21. 21. Re-Cap • For efficiency and cost effectiveness – Software should be developed using a phased process – Testing and Maintenance being two very costly phases, so to benefit for maximum saving these two phases should be focused – Errors introduced in early stages, if not identified and eradicated early then these cost a lot Hence Integrated Approach to Software Development should be adopted, according to this at each stage testing should be carried out [Jalote05] calls it ETVX Approach, whereas [Schach96] specifies What needs to be tested at each stage!!!
  22. 22. Desired Process Properties • Provide high Quality and Productivity (Q&P) – Support testability as testing is the most expensive task; testing can consume 30 to 50% of total development effort – Support maintainability as maintenance can be more expensive than development; over the life of the product, up to 80% of total cost – Remove defects early, as cost of removing defects increases with latency
  23. 23. ETVX Specification • ETVX approach is to specify at each phase or step – Entry criteria: what conditions must be satisfied for initiating this phase – Task: what is to be done in this phase – Verification: the checks done on the outputs of this phase – eXit criteria: when can this phase be considered done successfully • A phase also produces information for management
  24. 24. ETVX approach
  25. 25. Testing at Different Phases of Software Development • Main Testing Types Testing could be of Two Types; Non-executable and Executable • Phases Requirements Phase , Specification Phase, Planning Phase, Design Phase Implementation Phase, Integration Phase, Maintenance Phase and Retirement Phase Ref: Stephen R. Schach (2007); Software Engineering, 7th Edition, Tata McGraw- Hill Publishing Company Limited, New Delhi
  26. 26. Requirements Phase • Input – Clients (and Users) tell what they want – Client’s description of project – Meetings to understand ‘what they want’ – Client believes the Sw will help him – Find out the ‘constraints’ • Problems – Client don’t know what he wants – Description is vague, ambiguous, contradictory or simply impossible to achieve – Clarify the time and budget constraints
  27. 27. Requirements Phase • Do – Clarify the constraints, refine ‘What Client wants’ and ‘what is needed’ – Meetings with development team to address constraints – Analyze the possible problem areas – Rapid Prototyping helps – Requirements Document finalized • Testing – SQA group should ensure the Clients needs are satisfied – Confirm the final version of Rapid Prototype is acceptable to Client/User and meets their needs – Safeguard ‘moving target problem’
  28. 28. Specification Phase • Input – Requirements Doc • Goal – Specification Doc should explicitly describe • Functionality • Constraints and • Input/Output of the product • Problems – Specification Doc is the basis for the Contract, so must be • Precise • Unambiguous • Clear • No Contradictory or multi- meaning statements – In case of lawsuits it works as an evidence
  29. 29. Specification Phase • Do – Consult Client whenever needed to clarify the requirements – Write clearly avoiding mentioned problems – Validate errors in the input data and ensure all cases are covered – Specification (Software Requirements Specification – SRS) Document finalized • Testing – SQA group should ensure Specification Doc is • Complete • Unambiguous • Non-contradictory – Ascertain that the promised functionality can be delivered and it’s true reflection of clients requirements • Review of joint team from Client and Developer and SQA group helps
  30. 30. SE-381 Software Engineering BEIT-V Lecture no. 7 Software Engineering Processes 3 of 3
  31. 31. Planning Phase • Input – Specification Doc – Resources Available – Organizational structure – SDLC,CASE Tool, Detailed Schedule for Budget • Purpose – Exact Time and Budget Estimates – Erroneous estimates may lead to loss of contract or financial penalty to Company. • How to Do: – All Specification Document functions are addressed and estimated – Task Assignments to personnel – Time estimates, Costs incurred, detailed schedules
  32. 32. Planning Phase • Outputs – Major Components of the product, • Milestones / Gantt Charts • Time & Cost Budget • Deliverables and their timelines – Software Project Management Plan • With who is doing what and when information • Testing – Validate that Time and Budget estimates are correct – A good way to do it, obtain two alternate plans from different teams and note the differences and reconcile – Formal Review is another good technique to test
  33. 33. Design Phase The Most Important Phase – Specification describes ‘What’ and Design tells ‘How’ the functionality can be provided – Design is a CREATIVE activity • Input – Specification / SRS Document • How Done – Determine the Internal Structure of the product – Decide for Algorithms and Data Structures – Determine I/O of the product from SRS Doc – Analyze Internal Data Flows – Decompose Product into ‘Modules’ – Specify ‘functionality’ and ‘Interface’ to each module – Record all design decisions explicitly
  34. 34. Design Phase • Design has 2 or 3 Parts – Architectural Design • Break Down of System into Subsystems, Components and modules of the product • Structure Charts to represent – Detailed Design • Functionality and Interface of all modules is developed • Algorithms and Data Structures of each module identified • Testing – Re-trace – That every function in Spec (SRS) Doc have a module supporting it and the vice versa – Test Cases written for all modules be validated with the Spec Doc i.e. they conform to specs.
  35. 35. Implementation Phase • Input – Detailed Design for all the modules – Test Cases for the respective modules • How to Do – Consider language and platform dependencies here, if any – Code the modules with sufficient comments – Provide extra documentation like decision trees/tables, flow- charts etc for maintenance • Testing – Test all the modules using already prepared test cases • Output – Code for Modules
  36. 36. Integration Phase • Input – Specifications of Modules, Subsystems, and System; Test Cases, Structure Chart(s), Modules’ Code • How to Do – Top-Down, Bottom-up or incremental integration • Testing – Module, sub-systems and system all perform according to the specifications, – Product testing – Acceptance testing at Clients site, – Shrink-wrapped products – alpha, beta testing Test Cases Results with Used/produced I/O, Source Code, Acceptance Test proof
  37. 37. Maintenance Phase • Maintenance starts after delivery!! • But – Maintenance must be kept in focus while Designing/Coding … – Should be integral part of Software Development process • Testing – Ensure proper documentation – Careful change insertion and Regression Testing i.e. after making a change run all test cases to ensure that no further error has been introduced. Up-to-Date ‘Change Document’, Regression Test results
  38. 38. Retirement Phase • When to Retire? – Further Maintenance is not Cost-effective – Write-Only code – The documentation has rendered Obsolete – Hardware Advancement • Like a ‘record in sports’ new record improves the old one • True retirement is Rare in Sw domain, it is always a replacement, with improved version • Testing / Utility – A complete review of functionality and operations the Sw performed – Incorporation of keynote functions into the replacement
  39. 39. References / Reading Assignment [Jal97/05] Pankaj Jalote (1997,2005); An Integrated Approach to Software Engineering; 2nd /3rd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes pp:21-66 [Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life- Cycle Models [Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping The relevant parts of the above chapters to be read at home.
  40. 40. SE-381 Software Engineering BEIT-V Lecture no. 8 Software Process Models 1 of 3
  41. 41. Software Process Models – Software Development • Needs to be performed in a series of well-defined steps, so that the process could be managed to develop fault-free software product in the given budgetary and time constraints – Software Process Model • is a way or the order in which these steps/stages or phases of software development are executed, • is a framework for portraying the specific sequence of these phases There are a number of Software Process Models
  42. 42. Some Software Process Models – Build-n-Fix Model – Classical Waterfall Model and its variants – Prototyping Models • Rapid or Throwaway Prototyping Model • Evolutionary Prototyping Model – Incremental Model – Risk Based Models • Spiral Model – eXtreme Programming – Synchronise and Stabilize Model – Object Oriented Life Cycle Models • Fountain Model • Agile Model • Unified Process Model
  43. 43. Build and Fix Model
  44. 44. • Pros – Simplest – Used by students for classroom assignments – Build-use-modify-use-modify cycle continues until client is satisfied • Cons – No specification or design stages – Works for very small (<300- 400 LOCs) codes – Unreliable product – Very high cost of the produced product – Maintenance is in fact not possible without specification and design documents Build and Fix Model A Software Development Life Cycle Model must be chosen before the work on the product is initiated
  45. 45. Waterfall Model • Pros – Oldest, Since 1970s – Found by Winston Royce in 1970 – Most Widely used (in Aerospace Industry, even today) – Divides complex task into smaller, more manageable tasks and executes them in Linear order – Each task/stage is well defined has deliverables and well specified inputs and outputs – Iterations accommodated in Modified version – ‘Something is better than nothing’ - at least a systematic method then a haphazard approach – Project Management Possible
  46. 46. Waterfall Model Many organizations still cling to the waterfall model because, even with its shortfalls, it provides the most fully elaborated management guidelines on how to proceed in a given software situation. Barry Boehm, April 1998 Although 20 years back problems in WF model approach were highlighted but still 40% of companies using this approach – IEEE Software 2003 survey [Som04]
  47. 47. Classical Waterfall Model
  48. 48. Stage-wise Inputs / Outputs
  49. 49. Waterfall Model with Inter-stage Feedback
  50. 50. Jal97 – Waterfall Model
  51. 51. Waterfall Model
  52. 52. Waterfall Model . • Problems – Real-life systems don’t work in a simple sequential mode (so Iterations implemented) – Problems CROP UP in the later stages effecting earlier stages – Uncertainty in user specification CANNOT be specified at the outset – Design errors are numerous and persistent – Software delayed, user has to wait for long time – Specifications frozen at early stages, so the product may NOT conform to what user wanted
  53. 53. Waterfall Model .. Thus limitations of WF model are: – Requirements of a system are frozen before design begins; could work for automation of a legacy system but not for new systems – Freezing of Requirements may include the choice of HW, so on completion the new system may be dependent on a obsolete technology, as technology is ever improving – WF Model stipulates that the requirements are completely specified before the SD can proceed. In reality, for many systems including COTs a part of the system is fully developed and sold to customers, and then functionality is added to the system and it is redeveloped – Early freezing of specifications and absence of not many iterations, can not guarantee Users Satisfaction – The ‘Document Driven’ nature of Waterfall Model has its own Pros & Cons
  54. 54. Prototyping Model • Can be used to clarify Requirements, to design Use 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 markete
  55. 55. 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
  56. 56. 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
  57. 57. Prototyping Model Pressman (1992) –
  58. 58. Prototyping Model • Problems & Real-life – 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 – User Feedback accommodation
  59. 59. 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.
  60. 60. Rapid Prototyping Model
  61. 61. Jal97 – Prototyping Model
  62. 62. [Bel05] Throwaway Prototype Model
  63. 63. 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
  64. 64. [Bel05] Evolutionary Prototype Model
  65. 65. 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
  66. 66. 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 Pakistan and its neighbors. This is to be used by general public, so its implementation in national language will be preferred.
  67. 67. 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.

×