Upload
dalton-pippins
View
229
Download
0
Embed Size (px)
Citation preview
1
CSE
2102
CSE
2102
Chapter 7: The Software ProcessChapter 7: The Software Process
Prof. Steven A. DemurjianComputer Science & Engineering Department
The University of Connecticut371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
[email protected]://www.engr.uconn.edu/
~steve(860) 486 – 4818
(860) 486 – 3719 (office)
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
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
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
CSE
2102
CSE
2102
Design andSpecification
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 andSpecification
Coding andModule Testing
Integration andSystem Testing
Delivery
Maintenance
FeasibilityStudy
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
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
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
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
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
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
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
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
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
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
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
CSE
2102
CSE
2102
Waterfall Process Model with FeedbackWaterfall Process Model with Feedback
Requirements Analysis andSpecification
Design andSpecification
Coding andModule Testing
Integration andSystem Testing
Delivery and Maintenance
50 %50 %
50 %50 %
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
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
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
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
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
CSE
2102
CSE
2102
Transformation Model Roots in Formal Specification that Views SW D & D
as Steps to Transform Spec to Implementation1. Internal Requirements are Analyzed and Formally
Specified2. Formal Specification Transformed into Detailed,
Less Abstract Formal Description3. Repeat Step 2 Until Description is Executable by
Some Abstract Processor4. Further Transformations may be Needed to
Increase Efficiency Transformations may be Performed manually by SWE
or by Automated Support System
24
CSE
2102
CSE
2102
Requirements analysis and specification
OptimizationRequirements
Formal specifications
Verification Tuning
Lower level specifications
Recording of developmental history
Reusable components
Decisions & rationale
Transformation ModelTransformation Model
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
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
CSE
2102
CSE
2102
Spiral Model Cyclical Model is Four Stages:
1. Identify Objectives and Design Alternatives2. Evaluate Alternatives and Identify/Deal with
Potential Risks3. Develop and Verify Next Level Product4. Review Results and Plan for Next Iteration
Allows Unstated Requirements to Become Part of Specification of Next Cycle Robustness Approximates Correctness More
Closely
28
CSE
2102
CSE
2102
The Spiral ModelThe Spiral Model
29
CSE
2102
CSE
2102
The Spiral ModelThe Spiral Model
30
CSE
2102
CSE
2102
The Spiral ModelThe Spiral Model
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
CSE
2102
CSE
2102
Creating the Unified ProcessCreating the Unified Process
Functional testingPerformance testingRequirements mgmt
Conf. and change mgmtBusiness engineering
Data engineeringUI design
Rational Unified Process 5.01998
Rational Objectory Process 4.11996-1997
Objectory Process 1.0-3.81987-1995
Ericsson Approach
Rational Approach UML
33
CSE
2102
CSE
2102
New or changed
requirements
New or changed
system
Software EngineeringProcess
What Is a Process?
Defines Who is doing What, When to do it, and How to reach a certain goal.
34
CSE
2102
CSE
2102
Lifecycle Phases
time
Inception Elaboration Construction Transition
Inception Define the scope of the project /develop business case
Elaboration Plan project, specify features, and baseline the architecture
Construction Build the productTransition Transition the product to its
users
35
CSE
2102
CSE
2102
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary Iteration(s)
Iter.#1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Unified Process Iterations and WorkflowUnified Process Iterations and Workflow
36
CSE
2102
CSE
2102
Workflows and ModelsWorkflows and Models
Requirements
Design
Implementation
Test
Analysis
Use CaseModel
DesignModel
Deploym.Model
Impl.Model
AnalysisModel
TestModel
UML diagrams provide views into each model
Each workflow is associated with one or
more models.
37
CSE
2102
CSE
2102
Use Case ModelUse Case Model
Use CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
38
CSE
2102
CSE
2102
Analysis & Design ModelAnalysis & Design Model
Use CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
Incl. subsystems and packages
39
CSE
2102
CSE
2102
Deployment and Implementation ModelDeployment and Implementation Model
Use CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
Incl. active classes and components
40
CSE
2102
CSE
2102
Test ModelTest Model
Use CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
Test model refers to all other models and uses
corresponding diagrams
41
CSE
2102
CSE
2102
Use Case Driven
Reqmt.’s Impl. Test
Use Cases (scenarios) bind these workflows together
Analysis Design
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
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
timeArchitecture
Inception Elaboration Construction Transition
44
CSE
2102
CSE
2102
Architecture and ModelsArchitecture and Models
Architecture embodies a collection of views of the models
Views
Models
Use CaseModel
DesignModel
Deploym.Model
Impl.Model
TestModel
AnalysisModel
45
CSE
2102
CSE
2102
Logical Application ArchitectureLogical Application Architecture
RelationalDatabase
GraphicalUser
Interface
RelationalDatabase
GraphicalUser
Interface
BusinessObjectModel
GraphicalUser
Interface
BusinessObjectModel
RelationalDatabase
46
CSE
2102
CSE
2102
Physical Application ArchitecturePhysical Application Architecture
Relational Database Server(s)
Client CWWW Browser
WebServer
HTMLCGI ASP Java
Business ObjectServices
Business ObjectEngine
Application
Business ObjectServices
Client A
Business ObjectEngine
Thinner client, thicker server
Client B
Application
Business ObjectServices
Business ObjectEngine
Business Object Server
DCOMADO/R
CORBA Beans
COMMTS
BeansETS
47
CSE
2102
CSE
2102
Complex Internet System
Client
Server
ApplicationServer
FulfillmentSystem
FinancialSystem
InventorySystem
RDBMSServer
Dynamic HTML, JavaScript, Javaplug-ins, source code enhancements
Java, C, C++, JavaScript, CGI
Java, C, C++, JavaBeans, CORBA, DCOM
Native languages
48
CSE
2102
CSE
2102
Use cases Architecture
Function versus Form
Use Case Specify Function; Architecture Specifies Form
Use Cases and Architecture Must Be Balanced
49
CSE
2102
CSE
2102
The Unified Process is EngineeredThe 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
CSE
2102
CSE
2102
Agile DevelopmentAgile Development
Jump to Other Presentation
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
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
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
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
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