Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CSE 2102 CSE 2102 Chapter 7: The Software Process Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371.

Similar presentations


Presentation on theme: "1 CSE 2102 CSE 2102 Chapter 7: The Software Process Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371."— Presentation transcript:

1 1 CSE 2102 CSE 2102 Chapter 7: The Software Process Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT (860) 486 – 4818 (860) 486 – 3719 (office)

2 2 CSE 2102 CSE 2102 Overview of Chapter 7  Software Production Process Models  Focus on the “How” of Software Development  Stages, Phases, Steps: Methodology  Consider Six Process Models  Waterfall Model  Evolutionary Model  Transformation Model  Spiral Model  UML Unified Process (Slide 85ff – UML Slides)  Agile Software Development  Other Process Issues  Configuration Management  Standards

3 3 CSE 2102 CSE 2102 Software Production Process  Phases and Actions to Build, Deliver, Evolve Product  Objectives  Construct Programs from Idea to Completion  Produce Reliable, Predictable, and Efficient SW  Difficult to Automate  Software Production is a Highly Intellectual Activity  Software is Highly Instable  Interactions of Individuals from Various Backgrounds  Interface to OS, Hardware, Databases, etc.  Production Models Focus on the Software Lifecycle Emphasizing the Process from Start to Finish

4 4 CSE 2102 CSE 2102 Motivation  Increase in Application Complexity and Requirements has Led to Separation Between Developers and Users  Software Now Targets Users without “Computer Expertise”  Higher Level of Quality and Reliability Needed  Software Development as Group Activity  Software Development Needs to:  Manage Complexity in Modern Applications  Provide Detailed Careful Analysis of User Requirements  Boehm States that Goals of a Process Model are:  Determine Appropriate Stages  Establish Transition Criteria for Progressing from One Stage to Another

5 5 CSE 2102 CSE 2102 Design and Specification Waterfall Model – Classic Approach  Completion of All Phases (thru Delivery) Implies a Valid, Verified Product  Intended for Traditional Procedural PLs (C, Pascal, Fortran, PL/I, etc.)  Multiple Phases for Development  Complete One Phase before Next Begins Requirements Analysis and Specification Coding and Module Testing Integration and System Testing Delivery Maintenance Feasibility Study

6 6 CSE 2102 CSE 2102 Waterfall Model  First Appeared in late 1950s - Popularized in 1970s  Describes a Sequential Linear Flow Among Phases  Output of one Phase is Input to Next  Many Variants of Waterfall Model  Software Categories Influence Variants of Model  Customized Software for Particular Customer  Customized Software for Company  Generalized Application for Commercial Market  Software Production Companies  Define Outputs for Each Phase  Define Methods to be used to Produce Outputs  Organize Methods into SW Development Methodology  Briefly – Let’s Review Each Phase

7 7 CSE 2102 CSE 2102 Feasibility Study  Purpose: Produce a Feasibility Study Document that Evaluates Cost and Benefits of Application  People: Customer, End User, SW Engineers  Contents Highly Dependent on Application Domain  Feasibility Study Should Contain:  Definition of the Problem  Alternative Solutions and Expected Benefits  Required Resources, Costs, and Delivery Dates  Global Problem Analysis  Decide Future Worth of Software  How Complete can this Document be early in the Development Process?

8 8 CSE 2102 CSE 2102 Requirements Analysis/Specification  Purpose: Identify Required Qualities of Application  People: Interactions Between Users & SW Engineers  States the Required Qualities not How Attained  Produces a Requirements Specification Document  Formal Methods Translated into Natural Language for End Users  Includes User Manual with Screen Mockups  System Test Plan and Strategies/Scenarios  Critical Issues of  Separation of Concerns  Abstraction  Modularity

9 9 CSE 2102 CSE 2102 Requirements Analysis/Specification  Vertical Modularity: Each Module Hides Lower Level Design Decisions  Horizontal Modularity: System is Collection of Views of Some Level of Abstraction – Provide View of  Model of Data (ER or other Diagram)  Model of Functions (DFD, SC, AD, etc.)  Model of Control (Petri Nets, FSM, etc.)  Requirements Specification Document Contains  Functional Requirements – what Product Does  Non-Functional Requirements  Reliability (Available, Secure, Integrity, Safety, …)  Accuracy of Results, Performance, HCI  Operating/Physical Constraints, Portability, …

10 10 CSE 2102 CSE 2102 Design and Specification  Purpose: Decompose System into Modules  People: SW Engineers and Managers  Produces a Design Specification Document Containing a Description of Software Architecture  Decomposition usually has Two Phases:  Preliminary Design  Detailed Design  Design Specifications Document Must Follow a Company’s Standard  Design Alternatives Proposed and Evaluated  Multiple Ways to Solve Problem  Paper Methods (Simulation, Queueing, etc.)  Evaluate w.r.t. Requirements Analysis/Spec

11 11 CSE 2102 CSE 2102 Coding and Module Testing  Purpose: Actually Code and Test Software  People: SW Engineers and Managers, End Users (test)  Programming-in-the Small  Alternatives Implemented and Evaluated  List vs. Array vs. API (Set, Collection, …)  Different Algorithms w.r.t. Space and/or Time  Usage of Company Wide Standards  Program Layout, Comments and Headers, Naming Conventions  Module Testing (WBT, BBT) also via Standards  Other Activities Include  Code Inspection for Adherence to Standards  Check for Software Qualities (Performance)

12 12 CSE 2102 CSE 2102 Integration and System Testing  Purpose: Assemble Application from Individual Components and Test  People: SW Engineers, Teams, Managers, Users  Programming-in-the Large  Collections of Modules and Entire System Tested  Incremental Testing  Big-Bang Testing  Alpha Testing – Test Under Realistic Conditions with “Understanding” or “Forgiving” Users  Usage of Company Wide Standards  Method of Integration  Test Data Design  Documentation of Tests and Results

13 13 CSE 2102 CSE 2102 Delivery and Maintenance  Purpose: Application Distributed to Users and Supported via Maintenance/Evolution (A, C, and P)  People: Shipping Personnel, SWE, End Users  Two Stage Deliver  Beta Testing – Selective Group of Expected Users to Shake out all Bugs  Product Delivered to Customers  Leintz and Swanson’s Study Found:  Changes to User Requirements 42%  Changes in Data Format 17%  Emergency Fixes 12% Routine Debugging 9%  Hardware Changes 6%  Documentation Improvements 5%  Efficiency Improvements 4%

14 14 CSE 2102 CSE 2102 Other Activities in Waterfall Model  Documentation  Waterfall Model is Document Driven  Output of Phases is Documented  Company Standards Dictate Document Format  Verification  Emphasized During Module and System Testing  Appropriate Verification Occurs via Reviews, Walk-Throughs, Code Inspection  Goal – Monitor Application Quality Throughout Development Process – Discover/Remove Errors  Management  Tailor the Process to Fit the Product  Configuration and Version Management  Human Resources (Personnel and Organization)

15 15 CSE 2102 CSE 2102 Waterfall Model - Evaluation  Contributions to Understanding Software Processes  Software Development Must be Disciplined, Planned, and Managed  Implementation Delayed Until Objectives Clearly Understood  Characteristics of Waterfall Model  Linear: From Beginning to End w/o Backtracking  Rigidity:  Results of Each Phase Completed Before Proceeding to Next Phase  Assumes Requirements and Specs Finalized  Monolithic: All Planning is Oriented to Single Delivery Date  What are the Problems with this Process?

16 16 CSE 2102 CSE 2102 Waterfall Model - Evaluation  Problems with Waterfall Model  Forces Cost Estimation and Project Planning to Occur After Limited Analysis Performed  Verification of Requirements Spec Document Performed by Customer Not Very Effective  Unrealistic to Assume all Requirements Frozen before Development Starts  User’s Often Don’t Know Exact Requirements  Particularly Early in the Process  Does not Stress Anticipating Changes  Enforces Standards Based on Producing Particular Documents at Specific Times

17 17 CSE 2102 CSE 2102 Waterfall Process Model with Feedback Requirements Analysis and Specification Design and Specification Coding and Module Testing Integration and System Testing Delivery and Maintenance 50 %

18 18 CSE 2102 CSE 2102 Evolutionary Model  F. Brooks Advocates Producing a Product Twice  First Version is Throwaway to Provide Means for Users to Offer Feedback on Exact Requirements  Second Version Developed using Waterfall  Evolutionary or Incremental Approach  Emphasizes Stepwise Development  Flexible and Non-Monolithic  Postpones Parts of Some Stages  Several Different Variants of Evolutionary Model

19 19 CSE 2102 CSE 2102 Evolutionary Process Model Variant  Boehm: “Model Whose stages Consist of Expanding Increments of an Operational Software product, with the Direction of Evolution being Determined by Operational Experience”  Delivered Increment: Self-Contained Functional Unit that is Useful to the Customer  Includes Supporting Material (Doc, Test Plans, Training Materials, etc.)  Development Strategy  Deliver Something to the Real User  Measure Added Value to user  Adjust Design and Objectives Accordingly  Must Use Waterfall Process Discipline  Use Increments to Evolve toward Desired Product

20 20 CSE 2102 CSE 2102 Incremental Implementation Model Variant  Waterfall Model Used until Implementation Phase  Implementation Done Incrementally  Requires Analysis and Design Emphasis on Useful, Deliverable Subsets/Flexible Interfaces  Different Plans are Implemented, Tested, and Delivered at Different Times  Incremental Implementation is only a Partial Solution  May be Missing Functional (Buttons Don’t Work)  May Simulate Portions (Canned Info instead of DB)  What are Advantages? Disadvantages?

21 21 CSE 2102 CSE 2102 Incremental Development & Delivery Model  Incremental Approach Applied to All Waterfall Phases  Achieves Finer Granularity in the Process  Waterfall Model Followed for Different Portions  Increments Developed After user Feedback  Users can Understand What they Actually Need  All Evolutionary Approaches  Incorporate Maintenance into Every Stage of the Model  Employ Evolutionary Prototype that is Progressively transformed into Final Application  Prototyping Helps SWEs Understand User Needs  Requires Tools such as Visio, Rapid GUI tools, etc.

22 22 CSE 2102 CSE 2102 Assessing Evolutionary Models  Problems:  Large Time Gap Between Requirements Specification and Delivery  Emphasis on User Interface and Not Product  May Miss Functional Requirement  May Underestimate DB Complexity/Interactions  Requires Tools to Manage Process (Doable Today)  Advantages:  Product May Closely Follow User Requirements  Supports Anticipation of Change  More Flexible Than Just Waterfall Approach

23 23 CSE 2102 CSE 2102 Transformation Model  Roots in Formal Specification that Views SW D & D as Steps to Transform Spec to Implementation 1. Internal Requirements are Analyzed and Formally Specified 2. Formal Specification Transformed into Detailed, Less Abstract Formal Description 3. Repeat Step 2 Until Description is Executable by Some Abstract Processor 4. Further Transformations may be Needed to Increase Efficiency  Transformations may be Performed manually by SWE or by Automated Support System

24 24 CSE 2102 CSE 2102 Transformation Model

25 25 CSE 2102 CSE 2102 Transformation Model  Two Main Stages  Requirements Analysis for Formal Requirements  Optimization for Performance Tuning  Transformation Controlled by Software Engineering  Take Advantage of Reusable Components  Verify Against user Expectations  Supported by Software D&D Environment  Tools for Requirements Verification, Managing Reusable Components, Optimizing, Config. Mgmt.  Transformation Model Studied for Small Programs to Mathematically Prove Correctness  Idea of an Automated Assistant to Watch Over the Shoulder of Software Engineers  Isn’t this What Today’s SDEs/IDEs Provide?

26 26 CSE 2102 CSE 2102 Spiral Model  Purpose: Provide a Framework for Design Production Process Guided by Risk Levels  Guiding Principles: Level of Risk (Potential Adverse Circumstance)  Risk Management (Boehm): “Discipline whose objectives are to identify, address, and eliminate software risk items before they become either threats to successful software operation or a major source of expensive software rework.”  Focus on Identifying and Eliminating High Risk Problems by Careful Process Design/Assessment

27 27 CSE 2102 CSE 2102 Spiral Model  Cyclical Model is Four Stages: 1. Identify Objectives and Design Alternatives 2. Evaluate Alternatives and Identify/Deal with Potential Risks 3. Develop and Verify Next Level Product 4. Review Results and Plan for Next Iteration  Allows Unstated Requirements to Become Part of Specification of Next Cycle  Robustness Approximates Correctness More Closely

28 28 CSE 2102 CSE 2102 The Spiral Model

29 29 CSE 2102 CSE 2102 The Spiral Model

30 30 CSE 2102 CSE 2102 The Spiral Model

31 31 CSE 2102 CSE 2102 UML Unified Process  UML as a Model Can’t Work in Isolation  Large Scale System Design/Development Involves  Team-Oriented Efforts  Software Architectural Design  System Design, Implementation, Integration  The Unified Process by Rational is  Iterative and Incremental  Use Case Driven  Architecture-Centric

32 32 CSE 2102 CSE 2102 Creating the Unified Process Functional testing Performance testing Requirements mgmt Conf. and change mgmt Business engineering Data engineering UI design Rational Unified Process Rational Objectory Process Objectory Process Ericsson Approach Rational Approach UML

33 33 CSE 2102 CSE 2102 New or changed requirements New or changed system Software Engineering Process What Is a Process?  Defines Who is doing What, When to do it, and How to reach a certain goal.

34 34 CSE 2102 CSE 2102 Lifecycle Phases time InceptionElaborationConstruction Transition  Inception Define the scope of the project /develop business case  Elaboration Plan project, specify features, and baseline the architecture  Construction Build the product  Transition Transition the product to its users

35 35 CSE 2102 CSE 2102 Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements ElaborationTransitionInceptionConstruction Unified Process Iterations and Workflow

36 36 CSE 2102 CSE 2102 Workflows and Models Requirements Design Implementation Test Analysis Use Case Model Design Model Deploym. Model Impl. Model Analysis Model Test Model UML diagrams provide views into each model Each workflow is associated with one or more models.

37 37 CSE 2102 CSE 2102 Use Case Model Use Case Model Use Case Diagrams Collaboration Diagrams Component Diagrams Deployment Diagrams Object Diagrams Statechart Diagrams Sequence Diagrams Class Diagrams Activity Diagrams Use Case Model Design Model Depl. Model Impl. Model Analysis Model Test Model

38 38 CSE 2102 CSE 2102 Analysis & Design Model Use Case Diagrams Collaboration Diagrams Component Diagrams Deployment Diagrams Object Diagrams Statechart Diagrams Sequence Diagrams Class Diagrams Activity Diagrams Use Case Model Design Model Depl. Model Impl. Model Analysis Model Test Model Incl. subsystems and packages

39 39 CSE 2102 CSE 2102 Deployment and Implementation Model Use Case Diagrams Collaboration Diagrams Component Diagrams Deployment Diagrams Object Diagrams Statechart Diagrams Sequence Diagrams Class Diagrams Activity Diagrams Use Case Model Design Model Depl. Model Impl. Model Analysis Model Test Model Incl. active classes and components

40 40 CSE 2102 CSE 2102 Test Model Use Case Diagrams Collaboration Diagrams Component Diagrams Deployment Diagrams Object Diagrams Statechart Diagrams Sequence Diagrams Class Diagrams Activity Diagrams Use Case Model Design Model Depl. Model Impl. Model Analysis Model Test Model Test model refers to all other models and uses corresponding diagrams

41 41 CSE 2102 CSE 2102 Use Case Driven Reqmt.’sImpl.Test Use Cases (scenarios) bind these workflows together Analysis Design

42 42 CSE 2102 CSE 2102 Use Cases Drive Iterations  Drive a Number of Development Activities  Creation and Validation of the System’s Architecture  Definition of Test Cases and Procedures  Planning of Iterations  Creation of User Documentation  Deployment of System  Synchronize the Content of Different Models

43 43 CSE 2102 CSE 2102 Architecture-Centric  Models Are Vehicles for Visualizing, Specifying, Constructing, and Documenting Architecture  The Unified Process Prescribes the Successive Refinement of an Executable Architecture time Architecture InceptionElaborationConstruction Transition

44 44 CSE 2102 CSE 2102 Architecture and Models Architecture embodies a collection of views of the models Views Models Use Case Model Design Model Deploym. Model Impl. Model Test Model Analysis Model

45 45 CSE 2102 CSE 2102 Logical Application Architecture Relational Database Graphical User Interface Relational Database Graphical User Interface Business Object Model Graphical User Interface Business Object Model Relational Database

46 46 CSE 2102 CSE 2102 Physical Application Architecture Relational Database Server(s) Client C WWW Browser Web Server HTML CGI ASP Java Business Object Services Business Object Engine Application Business Object Services Client A Business Object Engine Thinner client, thicker server Client B Application Business Object Services Business Object Engine Business Object Server DCOM ADO/R CORBABeans COM MTS Beans ETS

47 47 CSE 2102 CSE 2102 Complex Internet System Client Server Application Server Fulfillment System Financial System Inventory System RDBMS Server Dynamic HTML, JavaScript, Java plug-ins, source code enhancements Java, C, C++, JavaScript, CGI Java, C, C++, JavaBeans, CORBA, DCOM Native languages

48 48 CSE 2102 CSE 2102 Use casesArchitecture Function versus Form  Use Case Specify Function; Architecture Specifies Form  Use Cases and Architecture Must Be Balanced

49 49 CSE 2102 CSE 2102 The Unified Process is Engineered Describe a Use Case Use case package Use case responsible for Analyst Artifact A piece of information that is produced, modified, or used by a process Worker A role played by an individual or a team Activity A unit of work

50 50 CSE 2102 CSE 2102 Agile Development Jump to Other Presentation

51 51 CSE 2102 CSE 2102 Configuration Management  Configuration  Identifies Components and Their Versions  Configuration Management  Discipline of Coordinating Software Development And Controlling the Change and Evolution of Software Products and Components  Multiple Access to Shared Repository  Handling Product Families  Different Members of the Family Comprise Components Which May have Different Versions

52 52 CSE 2102 CSE 2102 Versions  Version Management Differentiates Between  Revisions  New Version Supersedes the Previous  Define a Linear Order  Variants  Alternative Implementations of the Same Specification for Different Machines, or Access to Different I/O Devices  Further Logical Relations May Exist Among Versions of Components  A Component May be Derived From Another  Object Code Component is a Derived Version of a Source Code Component

53 53 CSE 2102 CSE 2102 Software Standards  Standards are Needed to Achieve Quality In Both Software Products and Processes  Standards May Be Imposed Internally or Externally  E.G., MIL-STD 2167A Imposed To Contractors For Military Applications  Other Examples: ISO Series, IEEE  DOIT Standards for All Types of  Methodologies  Tools  Documentation  Web Development  etc. etc. etc.

54 54 CSE 2102 CSE 2102 Main Benefits of Standards  From Developers' Viewpoint  Standards Enforce a Uniform Behavior Within an Organization  Facilitate Communication Among People  Stabilizes Production Process  Makes It Easier to Add New People to Ongoing Projects  From Customers' Viewpoint  Make It Easier to Assess the Progress And Quality Of Results  Reduce the Strict Dependency of Customers on Specific Contractors

55 55 CSE 2102 CSE 2102 Chapter 7 Summary  Software Process Methodologies are Crucial to Control the Process from Idea to Maintenance  Many Different Approaches  Waterfall, Evolutionary, Transformation, Spiral  Unified Process of UML  Agile Process  All Share Similar Terminology Influenced by Original Waterfall Model  Phases Relevant – Today Incremental Focus  What’s Coming Up…  Project Management and Planning  Tools and Environments  Underlying Infrastructure that Supports Process


Download ppt "1 CSE 2102 CSE 2102 Chapter 7: The Software Process Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371."

Similar presentations


Ads by Google