Waterfall model in Software engineering
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Waterfall model in Software engineering

on

  • 839 views

 

Statistics

Views

Total Views
839
Views on SlideShare
839
Embed Views
0

Actions

Likes
0
Downloads
23
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Waterfall model in Software engineering Presentation Transcript

  • 1. Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2  Instructor: Ehtesham Mehmood 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 1
  • 2. Overview of the Last Lecture  Overview of Software Engineering    Overview of Software Process   SE definitions Quality of Good Software Activities and associated stages Overview of Software Engineering Method   01/12/14 Structured Analysis Object-Oriented Method CPSC-4360-01, CPSC-5360-01, Lecture 2 2
  • 3. Overview of This Lecture  Software Development Models       Waterfall Model Evolutionary Models Incremental Model Spiral Model Unified Process Overview of UML    01/12/14 History 4 + 1 View models Using UML in UP CPSC-4360-01, CPSC-5360-01, Lecture 2 3
  • 4. Software Development Models  High level, abstract representation of software development (software process):       Specification. Development. Validation. Evolution. Theoretical framework that is usually extended and adapted in real world application. Two Generic Models:   01/12/14 Waterfall Model. Evolutionary Model. CPSC-4360-01, CPSC-5360-01, Lecture 2 4
  • 5. Waterfall Model  The earliest software development model (Royce, 1970). Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 5
  • 6. Waterfall model (Royce, 1970) Req. Change Requirements Verify Design Verify Implementation Test Operations Retirement 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 6 6
  • 7. Waterfall Model    Defined a number of phases, e.g., “requirement phase”, “design phase”, etc. The phases correspond to the four stages of the fundamental software process activities (lecture 1). Assumption behind the model:   01/12/14 a phase takes place in sequence to another. each activity is completed before the next starts. CPSC-4360-01, CPSC-5360-01, Lecture 2 7
  • 8. Waterfall Model  In theory:  Each phase produces documents that are:     Verified and validated. Assumed to be complete. Each phase depends on the documents of the previous stage to proceed → it has to wait for the completion of previous stage. In practice:  01/12/14 The phases overlap and feedback to each other (see the feedback arrow in the diagram). CPSC-4360-01, CPSC-5360-01, Lecture 2 8
  • 9. Waterfall Model: Advantages   Tangible products (the various documents) at the end of every phases → good to measure progress. Intuitive, sensible and general purpose:   01/12/14 Emphasize planning before action. Recommend a top-down perspective. See the big picture before zooming down. CPSC-4360-01, CPSC-5360-01, Lecture 2 9
  • 10. Waterfall Model: Problems  Specification is frozen early, because:    Cannot adapt to changing or incorrect specification:    It is costly and time consuming. Later stages can be carried out. Ignore or code around. Does not meet user requirement. Testing at the very end of development:  01/12/14 Work or die situation. CPSC-4360-01, CPSC-5360-01, Lecture 2 10
  • 11. Waterfall Model: Observations     Process stages can be iterative. Flexibility in coping with changing specification. Early and frequent validation of software system. The later models are designed in response to these observations. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 11
  • 12. Evolutionary Model  Evolves an initial implementation with user feedback → multiple versions until the final version. Concurren t activities Specification 01/12/14 Development Intermediate versions Validation Outline description Initial version Final version CPSC-4360-01, CPSC-5360-01, Lecture 2 12
  • 13. Evolutionary Model  Two fundamental types:  Exploratory Development:    Explores the requirement and delivers a final system. Starts with something that is understood and evolves by adding new features proposed by customers. Throwaway prototyping:    01/12/14 Understands the requirement and develop a better requirement definition. Experimenting with poorly understood requirement. Usually develops User Interface (UI) with minor or no functionality. CPSC-4360-01, CPSC-5360-01, Lecture 2 13
  • 14. Evolutionary Model: Advantages  Customer involvement in the process:   Early and frequent testing:    More likely to meet the user requirement. More likely to identify problems. Lower risk. Suitable for small to medium sized system. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 14
  • 15. Evolutionary Model: Problems  The process is intangible:   The process is unpredictable:   Hard to manage, e.g., scheduling, workforce allocation, etc. Systems are poorly structured:    No regular, well-defined deliverables. Continual, unpredictable change tends to corrupt the software structure. Can cause major problems during software evolution. Systems may not even converge to a final version.  01/12/14 No strategy to gauge or solve this problem. CPSC-4360-01, CPSC-5360-01, Lecture 2 15
  • 16. Incremental Model  Combine the advantages of Waterfall and Evolutionary Model. Requirements Outline Develop Increment Split into increments Validate Increment Design System Architecture Integrate Increment Validate System Final System 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 16
  • 17. Incremental Model  Each increment is a mini-waterfall. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 17
  • 18. Incremental Model    Prioritizes the services to be provided by the system. Maps these requirements to Increment based on priority. Freezes requirement for the current Increment.   Requirements for the later increments can evolve concurrently. Each Increment release is a working system:   01/12/14 Allows user to experiment. Can be put into service right away. CPSC-4360-01, CPSC-5360-01, Lecture 2 18
  • 19. Incremental Model: Advantages  Early utilization:     the 1st increment satisfies the most critical requirement. Early increments can serves as prototypes. Lower risk of overall project failure. Most crucial and basic services are implemented first → receives multiple testing throughout development. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 19
  • 20. Incremental Model: Problems    Hard to map requirement into small increments (< 20,000 lines of code). Hard to define the basic services that are shared by all subsequent increments. Popular variant:  AGILE method:   01/12/14 eXtreme Programming (XP) Not covered here. CPSC-4360-01, CPSC-5360-01, Lecture 2 20
  • 21. Spiral Model  Formalize the Evolutionary Model and avoid the management shortcomings. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 21
  • 22. Spiral Model    Process is represented as a spiral rather than as a sequence of activities with backtracking. Each loop = One Iteration = A process phase. Each Loop passes through 4 quadrants (90°):      Objective Setting. Risk Assessment and Reduction. Development and Validation. Planning. As loops move away from center → Time and Cost increase. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 22
  • 23. Spiral Model  Risk Driven:    Does not prescribe a fix process:   Explicitly identify risks for each iteration. Address the highest perceived risk. Project Manager chooses the appropriate activity for each iteration base on progress and perceived risk. Flexible:  01/12/14 May resemble other process model depends on needs. CPSC-4360-01, CPSC-5360-01, Lecture 2 23
  • 24. Unified Process  State of the art process, by learning from the history of previous software development processes. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 24
  • 25. Unified Process  Integrating two seemingly contradicting insights:    A project is split into several phases:    Definitive activities and deliverables as in the Waterfall Model. Iterative and incremental processes. Each phase is split into several iterations. Each iteration consists of the traditional process activities, known as workflow. Each workflow places different emphasis on the activities depending on the current iteration. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 25
  • 26. Unified Process: 4 Phases  Inception:    Elaboration:     Understand problem domain. Design system architecture. Plan development. Construction:   Plan the project. Evaluate risk. Design, programming and test. Transition:   01/12/14 Moving system from developer to user environment. Acceptance testing, release of full system. CPSC-4360-01, CPSC-5360-01, Lecture 2 26
  • 27. Other Process Models  Formal System Development:    Reuse-Oriented Development:     Transforms a mathematical based specification through different representation → executable program. Program correctness is easy to demonstrate, as the transformations preserve the correctness. Concentrates on integrating new system with existing components/systems. Growing rapidly as development cost increase. Aspect-Oriented Development. Agent-Oriented Software Development. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 27
  • 28. Unified Modeling Language (UML)  A visual language to   Similar to all other languages, UML has:      Visualize, construct, document software system. Grammar: Rules to follow when drawing diagrams. Semantics: The meaning behind each diagram. Used with the Object-Oriented Method. Separates the language from the software process → can be used with other software development model. Currently, this is an industry standard. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 28
  • 29. What UML is NOT  Not a programming language.    Not a software modeling tool.   Not executable. Exist tools to translate into code (skeleton), but the programmer still need to do the bulk of work. There are tools that implement the UML standard, e.g., ArgoUML, Visual Paradigm, RationalRose. Not a SE method or software development process. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 29
  • 30. UML: Brief History   OO Modeling approach with different strengths and weaknesses grows rapidly. In 1995,      There were more than 50 named techniques in the industry. The Object Management Group (OMG) calls for a common modeling approach. Rumbaugh, Booch, and Jacobson (The three amigos) with input from others, formalized the UML standard (UML 1.1) in 1997. Revised in 2003 (UML 1.5): Currently most widely used. Reorganized in 2005 (UML 2.0): A new standard. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 30
  • 31. UML: 4 + 1 View Models   A system can be viewed in different ways, usually depends on the role of the viewer. UML supports this by providing the 4 + 1 View Models [Kruchten, 1995]: System Design View Implementation View Use Case View Deployment Process View View 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 31
  • 32. Use Case View  Audience:   System Analyst, End Users and Testers. Usage:    01/12/14 Describes the system’s external behaviour. Defines the requirements of the system, so it constraints all the other views. Has the central role in driving the development process. CPSC-4360-01, CPSC-5360-01, Lecture 2 32
  • 33. Example of Use Case  Elevator System  Use case 1: ‘Call Elevator’ is this possible written story:     Basic course of events: If the userOutside wants to call lift to go up/down, then he/she presses UpButton/DownButton; Exception 1: If the lift is at the ground floor, then there is no DownButton; Exception 2: If the lift is at the top floor, then there is no UpButton; Use case 2: ‘Move From Inside’ is this written story:  01/12/14 The userFromInside can select a floor number (from 1 to the number of floors of the building), or can press “Open”, “Close”. CPSC-4360-01, CPSC-5360-01, Lecture 2 33
  • 34. Design View  Audience:   System Analyst and Programmers. Usage:    01/12/14 Describes the logical structures that support the functional requirements expressed in the use case view. Consists of definitions of program components (classes, data), their behaviour and interactions. Useful as basis for coding. CPSC-4360-01, CPSC-5360-01, Lecture 2 34
  • 35. Implementation View  Audience:   System Engineer and Tester. Usage:  Describes the physical components out of which the system is to be constructed:     01/12/14 executable files, libraries of code, databases. Useful for configuration management and system integration. CPSC-4360-01, CPSC-5360-01, Lecture 2 35
  • 36. Process View  Audience:   Usage:    System Analyst, Programmer and Tester. Non-Functional requirements. Defines concurrency within the system. Relatively undeveloped. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 36
  • 37. Deployment View  Audience:   System Integrator (setup the system at client side). Usage:   Non-Functional. Describes physical components that are deployed in the physical environment:    Network of computers, connection protocol. Computer specification. Relatively Undeveloped. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 37
  • 38. UML Terminology  Model:    Model element:   Refers to the information in a single view, e.g., Use Case Model. OR Refers to all the information about the system, i.e., System Model. Independent graphical notation element, e.g., a box, an arrow, etc, that has a well defined meaning. Diagram:  01/12/14 Graphical presentation of a collection of model elements. CPSC-4360-01, CPSC-5360-01, Lecture 2 38
  • 39. UML Diagrams by Views 1. 2. 3. 4. 5. 6. 7. 8. 9. 01/12/14 Use case diagram (use case view) Object diagram (use case and design views) Sequence diagram (use case and design views) Collaboration diagram (use case and design views) Class diagram (design view) Statechart diagram (design and process views) Activity diagram (design and process views) Component diagram (implementation view) Deployment diagram (deployment view) CPSC-4360-01, CPSC-5360-01, Lecture 2 39
  • 40. UML Diagrams by Characteristic  Software system exhibits two characteristics:    Static: Logical Structure, e.g., relationship between classes, attributes of a class, etc. Dynamic: Behavior of the system, e.g., how to respond to a certain event, how to initiate an action, etc. In addition, knowledge about setting up and running the system: Implementation. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 40
  • 41. UML Diagrams by Characteristic  Static:    Dynamic:       Use case diagram Class diagram Object diagram State diagram Activity diagram Sequence diagram Collaboration diagram Implementation:   01/12/14 Component diagram Deployment diagram CPSC-4360-01, CPSC-5360-01, Lecture 2 41
  • 42. Design Model and Code   Models present an abstract view of system. Implementation adds enough detail to make these models executable. UML UML model specifies Object structures Abstract view of Abstract view of Java Source code specifies Executing program Compile time 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 Run time 42
  • 43. UML Models      Both documentation (‘UML model’) and ‘Source code’ can be described as compile-time artifacts. ‘Object structures’: Programmers in object-oriented languages (e.g., Java, C++) tend to use abstract models of program execution which talk in terms of objects being created and destroyed as a program runs. ‘Executing program’: describes the effect the program has on computer’s processor and memory when the program is running. The upper and below parts refer to design and programming. The left and right parts refer to compile-time and run-time. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 43
  • 44. Unified Process and UML  UP is Use Case Driven:    A systematic utilization of Use Case. UML diagrams are used in the Requirement, Analysis and Design activities in the UP workflow. Because of their history, there is a close fit between UML and the UP. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 44
  • 45. UP: Requirement and Analysis  UP starts with use cases describing how users interact with the system:   01/12/14 A domain model records facts about real world entities. UML use case and class diagrams document these. CPSC-4360-01, CPSC-5360-01, Lecture 2 45
  • 46. UP: Analysis and Design   Analysis and Design usually overlap in UP as the same diagrams are used. Proceed by Realization and Refinement. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 46
  • 47. UP: Realization and Refinement  Use case realizations indicate how the functionality will be supported by the system.   Documented in UML interaction diagrams, e.g., Sequence Diagram, Collaboration Diagram. This causes the domain model to be refined into a more implementation-oriented class diagram. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 47
  • 48. UP: Specifying Behavior  UML provides State Chart to document the behavior of classes. 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 48
  • 49. Summary (1)  Waterfall Process Model:     Development activities in a linear fashion. Requirements to freeze very early in development. Testing very late in the process. Evolutionary Process Model in response to iterative nature of development:   01/12/14 Use of prototyping. Requirements evolve with users’ feedback. CPSC-4360-01, CPSC-5360-01, Lecture 2 49
  • 50. Summary (2)  Incremental Process Model in response to incremental nature of development:    01/12/14 Delivery in increments. Allows prioritizing risks in development. Allows different process models for different increments. CPSC-4360-01, CPSC-5360-01, Lecture 2 50
  • 51. Summary (3)  Spiral Model:      Addresses incremental and iterative nature of development. Allows risk evaluation at every phase. Expensive process. Allows use of multiple process models. Unified Process:    01/12/14 Incorporates best industry practices. Extensive use of UML models. Allows iteration of workflows. CPSC-4360-01, CPSC-5360-01, Lecture 2 51
  • 52. Summary  Software Development Models       Waterfall Model Evolutionary Models Incremental Model Spiral Model Unified Process Overview of UML    01/12/14 History 4 + 1 View models Using UML in UP CPSC-4360-01, CPSC-5360-01, Lecture 2 52
  • 53. Reading Suggestions    [Wadhwa, Andrei, Soo; 2007], Chapter 2 [Sommerville; 2008], Chapters 1 and 4 [Priestley; 2004], Chapter 3 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 53
  • 54. Coming up next  Use Case Modeling, Domain Modeling:   01/12/14 [Wadhwa, Andrei, Soo; 2007], Chapters 2 and 3 [Priestley; 2004], Chapter 4 CPSC-4360-01, CPSC-5360-01, Lecture 2 54
  • 55. Thank you for your attention! Questions? 01/12/14 CPSC-4360-01, CPSC-5360-01, Lecture 2 55