Presentation on theme: "Chapter 7: The Software Process"— Presentation transcript:
1Chapter 7: The Software Process Prof. Steven A. DemurjianComputer Science & Engineering DepartmentThe University of Connecticut371 Fairfield Road, Box U-2155Storrs, CT(860) 486 – 4818(860) 486 – 3719 (office)
2Overview of Chapter 7 Software Production Process Models Focus on the “How” of Software DevelopmentStages, Phases, Steps: MethodologyConsider Six Process ModelsWaterfall ModelEvolutionary ModelTransformation ModelSpiral ModelUML Unified Process (Slide 85ff – UML Slides)Agile Software DevelopmentOther Process IssuesConfiguration ManagementStandards
3Software Production Process Phases and Actions to Build, Deliver, Evolve ProductObjectivesConstruct Programs from Idea to CompletionProduce Reliable, Predictable, and Efficient SWDifficult to AutomateSoftware Production is a Highly Intellectual ActivitySoftware is Highly InstableInteractions of Individuals from Various BackgroundsInterface to OS, Hardware, Databases, etc.Production Models Focus on the Software Lifecycle Emphasizing the Process from Start to Finish
4MotivationIncrease in Application Complexity and Requirements has Led to Separation Between Developers and UsersSoftware Now Targets Users without “Computer Expertise”Higher Level of Quality and Reliability NeededSoftware Development as Group ActivitySoftware Development Needs to:Manage Complexity in Modern ApplicationsProvide Detailed Careful Analysis of User RequirementsBoehm States that Goals of a Process Model are:Determine Appropriate StagesEstablish Transition Criteria for Progressing from One Stage to Another
5Waterfall Model – Classic Approach Multiple Phases for DevelopmentComplete One Phase before Next BeginsFeasibilityStudyRequirementsAnalysis andSpecificationDesign andSpecificationCoding andModule TestingIntegration andSystem TestingCompletion of All Phases (thru Delivery) Implies a Valid, Verified ProductIntended for Traditional Procedural PLs (C, Pascal, Fortran, PL/I, etc.)DeliveryMaintenance
6Waterfall Model First Appeared in late 1950s - Popularized in 1970s Describes a Sequential Linear Flow Among PhasesOutput of one Phase is Input to NextMany Variants of Waterfall ModelSoftware Categories Influence Variants of ModelCustomized Software for Particular CustomerCustomized Software for CompanyGeneralized Application for Commercial MarketSoftware Production CompaniesDefine Outputs for Each PhaseDefine Methods to be used to Produce OutputsOrganize Methods into SW Development MethodologyBriefly – Let’s Review Each Phase
7Feasibility StudyPurpose: Produce a Feasibility Study Document that Evaluates Cost and Benefits of ApplicationPeople: Customer, End User, SW EngineersContents Highly Dependent on Application DomainFeasibility Study Should Contain:Definition of the ProblemAlternative Solutions and Expected BenefitsRequired Resources, Costs, and Delivery DatesGlobal Problem AnalysisDecide Future Worth of SoftwareHow Complete can this Document be early in the Development Process?
8Requirements Analysis/Specification Purpose: Identify Required Qualities of ApplicationPeople: Interactions Between Users & SW EngineersStates the Required Qualities not How AttainedProduces a Requirements Specification DocumentFormal Methods Translated into Natural Language for End UsersIncludes User Manual with Screen MockupsSystem Test Plan and Strategies/ScenariosCritical Issues ofSeparation of ConcernsAbstractionModularity
9Requirements Analysis/Specification Vertical Modularity: Each Module Hides Lower Level Design DecisionsHorizontal Modularity: System is Collection of Views of Some Level of Abstraction – Provide View ofModel of Data (ER or other Diagram)Model of Functions (DFD, SC, AD, etc.)Model of Control (Petri Nets, FSM, etc.)Requirements Specification Document ContainsFunctional Requirements – what Product DoesNon-Functional RequirementsReliability (Available, Secure, Integrity, Safety, …)Accuracy of Results, Performance, HCIOperating/Physical Constraints, Portability, …
10Design and Specification Purpose: Decompose System into ModulesPeople: SW Engineers and ManagersProduces a Design Specification Document Containing a Description of Software ArchitectureDecomposition usually has Two Phases:Preliminary DesignDetailed DesignDesign Specifications Document Must Follow a Company’s StandardDesign Alternatives Proposed and EvaluatedMultiple Ways to Solve ProblemPaper Methods (Simulation, Queueing, etc.)Evaluate w.r.t. Requirements Analysis/Spec
11Coding and Module Testing Purpose: Actually Code and Test SoftwarePeople: SW Engineers and Managers, End Users (test)Programming-in-the SmallAlternatives Implemented and EvaluatedList vs. Array vs. API (Set, Collection, …)Different Algorithms w.r.t. Space and/or TimeUsage of Company Wide StandardsProgram Layout, Comments and Headers, Naming ConventionsModule Testing (WBT, BBT) also via StandardsOther Activities IncludeCode Inspection for Adherence to StandardsCheck for Software Qualities (Performance)
12Integration and System Testing Purpose: Assemble Application from Individual Components and TestPeople: SW Engineers, Teams, Managers, UsersProgramming-in-the LargeCollections of Modules and Entire System TestedIncremental TestingBig-Bang TestingAlpha Testing – Test Under Realistic Conditions with “Understanding” or “Forgiving” UsersUsage of Company Wide StandardsMethod of IntegrationTest Data DesignDocumentation of Tests and Results
13Delivery and Maintenance Purpose: Application Distributed to Users and Supported via Maintenance/Evolution (A, C, and P)People: Shipping Personnel, SWE, End UsersTwo Stage DeliverBeta Testing – Selective Group of Expected Users to Shake out all BugsProduct Delivered to CustomersLeintz 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%
14Other Activities in Waterfall Model DocumentationWaterfall Model is Document DrivenOutput of Phases is DocumentedCompany Standards Dictate Document FormatVerificationEmphasized During Module and System TestingAppropriate Verification Occurs via Reviews, Walk-Throughs, Code InspectionGoal – Monitor Application Quality Throughout Development Process – Discover/Remove ErrorsManagementTailor the Process to Fit the ProductConfiguration and Version ManagementHuman Resources (Personnel and Organization)
15Waterfall Model - Evaluation Contributions to Understanding Software ProcessesSoftware Development Must be Disciplined, Planned, and ManagedImplementation Delayed Until Objectives Clearly UnderstoodCharacteristics of Waterfall ModelLinear: From Beginning to End w/o BacktrackingRigidity:Results of Each Phase Completed Before Proceeding to Next PhaseAssumes Requirements and Specs FinalizedMonolithic: All Planning is Oriented to Single Delivery DateWhat are the Problems with this Process?
16Waterfall Model - Evaluation Problems with Waterfall ModelForces Cost Estimation and Project Planning to Occur After Limited Analysis PerformedVerification of Requirements Spec Document Performed by Customer Not Very EffectiveUnrealistic to Assume all Requirements Frozen before Development StartsUser’s Often Don’t Know Exact RequirementsParticularly Early in the ProcessDoes not Stress Anticipating ChangesEnforces Standards Based on Producing Particular Documents at Specific Times
17Waterfall Process Model with Feedback RequirementsAnalysis andSpecificationDesign andSpecification50 %TIME & COSTCoding andModule TestingIntegration andSystem TestingDelivery andMaintenance50 %
18Evolutionary Model F. Brooks Advocates Producing a Product Twice First Version is Throwaway to Provide Means for Users to Offer Feedback on Exact RequirementsSecond Version Developed using WaterfallEvolutionary or Incremental ApproachEmphasizes Stepwise DevelopmentFlexible and Non-MonolithicPostpones Parts of Some StagesSeveral Different Variants of Evolutionary Model
19Evolutionary 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 CustomerIncludes Supporting Material (Doc, Test Plans, Training Materials, etc.)Development StrategyDeliver Something to the Real UserMeasure Added Value to userAdjust Design and Objectives AccordinglyMust Use Waterfall Process DisciplineUse Increments to Evolve toward Desired Product
20Incremental Implementation Model Variant Waterfall Model Used until Implementation PhaseImplementation Done IncrementallyRequires Analysis and Design Emphasis on Useful, Deliverable Subsets/Flexible InterfacesDifferent Plans are Implemented, Tested, and Delivered at Different TimesIncremental Implementation is only a Partial SolutionMay be Missing Functional (Buttons Don’t Work)May Simulate Portions (Canned Info instead of DB)What are Advantages? Disadvantages?
21Incremental Development & Delivery Model Incremental Approach Applied to All Waterfall PhasesAchieves Finer Granularity in the ProcessWaterfall Model Followed for Different PortionsIncrements Developed After user FeedbackUsers can Understand What they Actually NeedAll Evolutionary ApproachesIncorporate Maintenance into Every Stage of the ModelEmploy Evolutionary Prototype that is Progressively transformed into Final ApplicationPrototyping Helps SWEs Understand User NeedsRequires Tools such as Visio, Rapid GUI tools, etc.
22Assessing Evolutionary Models Problems:Large Time Gap Between Requirements Specification and DeliveryEmphasis on User Interface and Not ProductMay Miss Functional RequirementMay Underestimate DB Complexity/InteractionsRequires Tools to Manage Process (Doable Today)Advantages:Product May Closely Follow User RequirementsSupports Anticipation of ChangeMore Flexible Than Just Waterfall Approach
23Transformation ModelRoots in Formal Specification that Views SW D & D as Steps to Transform Spec to ImplementationInternal Requirements are Analyzed and Formally SpecifiedFormal Specification Transformed into Detailed, Less Abstract Formal DescriptionRepeat Step 2 Until Description is Executable by Some Abstract ProcessorFurther Transformations may be Needed to Increase EfficiencyTransformations may be Performed manually by SWE or by Automated Support System
25Transformation Model Two Main Stages Requirements Analysis for Formal RequirementsOptimization for Performance TuningTransformation Controlled by Software EngineeringTake Advantage of Reusable ComponentsVerify Against user ExpectationsSupported by Software D&D EnvironmentTools for Requirements Verification, Managing Reusable Components, Optimizing, Config. Mgmt.Transformation Model Studied for Small Programs to Mathematically Prove CorrectnessIdea of an Automated Assistant to Watch Over the Shoulder of Software EngineersIsn’t this What Today’s SDEs/IDEs Provide?
26Spiral ModelPurpose: Provide a Framework for Design Production Process Guided by Risk LevelsGuiding 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
27Spiral Model Cyclical Model is Four Stages: Identify Objectives and Design AlternativesEvaluate Alternatives and Identify/Deal with Potential RisksDevelop and Verify Next Level ProductReview Results and Plan for Next IterationAllows Unstated Requirements to Become Part of Specification of Next CycleRobustness Approximates Correctness More Closely
31UML Unified Process UML as a Model Can’t Work in Isolation Large Scale System Design/Development InvolvesTeam-Oriented EffortsSoftware Architectural DesignSystem Design, Implementation, IntegrationThe Unified Process by Rational isIterative and IncrementalUse Case DrivenArchitecture-Centric
32Creating the Unified Process Rational Unified Process 5.0Functional testingPerformance testingRequirements mgmtConf. and change mgmtBusiness engineeringData engineeringUI design1998RationalObjectory Process 4.1Rational ApproachUMLObjectory ProcessEricsson Approach
33What Is a Process?Defines Who is doing What, When to do it, and How to reach a certain goal.New or changedrequirementsNew or changedsystemSoftware EngineeringProcess
34Lifecycle PhasestimeInceptionElaborationConstructionTransitionInception Define the scope of the project /develop business caseElaboration Plan project, specify features, and baseline the architectureConstruction Build the productTransition Transition the product to its users
35Unified Process Iterations and Workflow PhasesProcess WorkflowsInceptionElaborationConstructionTransitionBusiness ModelingRequirementsAnalysis & DesignImplementationTestDeploymentSupporting WorkflowsConfiguration MgmtManagementEnvironmentPreliminary Iteration(s)Iter. #1Iter. #2Iter. #nIter. #n+1Iter. #n+2Iter. #mIter. #m+1Iterations
36Workflows and Models UML diagrams provide views into each model Use CaseModelRequirementsAnalysisModelAnalysisDesignModelDesignDeploym.ModelImpl.ModelImplementationTestModelTestEach workflow is associated with one or more models.
37Use Case Model Use Case Diagrams Class Diagrams Object Diagrams AnalysisModelComponentDiagramsDesignModelDeploymentDiagramsDepl.ModelSequenceDiagramsImpl.ModelCollaborationDiagramsStatechartDiagramsTestModelActivityDiagrams
38Analysis & Design Model Use CaseDiagramsUse CaseModelClassDiagramsObjectDiagramsAnalysisModelComponentDiagramsIncl. subsystems and packagesDesignModelDeploymentDiagramsDepl.ModelSequenceDiagramsImpl.ModelCollaborationDiagramsStatechartDiagramsTestModelActivityDiagrams
39Deployment and Implementation Model Use CaseDiagramsUse CaseModelClassDiagramsObjectDiagramsAnalysisModelComponentDiagramsDesignModelDeploymentDiagramsIncl. active classes and componentsDepl.ModelSequenceDiagramsImpl.ModelCollaborationDiagramsStatechartDiagramsTestModelActivityDiagrams
40Test model refers to all other models and uses corresponding diagrams Use CaseDiagramsUse CaseModelClassDiagramsObjectDiagramsAnalysisModelComponentDiagramsDesignModelDeploymentDiagramsDepl.ModelTest model refers to all other models and uses corresponding diagramsSequenceDiagramsImpl.ModelCollaborationDiagramsStatechartDiagramsTestModelActivityDiagrams
41Use Cases (scenarios) bind these workflows together Use Case DrivenReqmt.’sAnalysisDesignImpl.TestUse Cases (scenarios) bind these workflows together
42Use Cases Drive Iterations Drive a Number of Development ActivitiesCreation and Validation of the System’s ArchitectureDefinition of Test Cases and ProceduresPlanning of IterationsCreation of User DocumentationDeployment of SystemSynchronize the Content of Different Models
43Architecture-Centric Models Are Vehicles for Visualizing, Specifying, Constructing, and Documenting ArchitectureThe Unified Process Prescribes the Successive Refinement of an Executable ArchitectureInceptionElaborationConstructionTransitiontimeArchitecture
44Architecture and Models Use CaseModelAnalysisModelDesignModelImpl.ModelTestModelDeploym.ModelModelsViewsArchitecture embodies a collection of views of the models
48Function versus FormUse casesArchitectureUse Case Specify Function; Architecture Specifies FormUse Cases and Architecture Must Be Balanced
49The Unified Process is Engineered Describe aUse CaseUse case packageUse caseresponsible forAnalystArtifactA piece of information that is produced, modified, or used by a processWorkerA role played by an individual or a teamActivityA unit of work
51Configuration Management Identifies Components and Their VersionsConfiguration ManagementDiscipline of Coordinating Software Development And Controlling the Change and Evolution of Software Products and ComponentsMultiple Access to Shared RepositoryHandling Product FamiliesDifferent Members of the Family Comprise Components Which May have Different Versions
52Versions Version Management Differentiates Between Revisions Variants New Version Supersedes the PreviousDefine a Linear OrderVariantsAlternative Implementations of the Same Specification for Different Machines, or Access to Different I/O DevicesFurther Logical Relations May Exist Among Versions of ComponentsA Component May be Derived From AnotherObject Code Component is a Derived Version of a Source Code Component
53Software StandardsStandards are Needed to Achieve Quality In Both Software Products and ProcessesStandards May Be Imposed Internally or ExternallyE.G., MIL-STD 2167A Imposed To Contractors For Military ApplicationsOther Examples: ISO Series, IEEEDOIT Standards for All Types ofMethodologiesToolsDocumentationWeb Developmentetc. etc. etc.
54Main Benefits of Standards From Developers' ViewpointStandards Enforce a Uniform Behavior Within an OrganizationFacilitate Communication Among PeopleStabilizes Production ProcessMakes It Easier to Add New People to Ongoing ProjectsFrom Customers' ViewpointMake It Easier to Assess the Progress And Quality Of ResultsReduce the Strict Dependency of Customers on Specific Contractors
55Chapter 7 SummarySoftware Process Methodologies are Crucial to Control the Process from Idea to MaintenanceMany Different ApproachesWaterfall, Evolutionary, Transformation, SpiralUnified Process of UMLAgile ProcessAll Share Similar Terminology Influenced by Original Waterfall ModelPhases Relevant – Today Incremental FocusWhat’s Coming Up…Project Management and PlanningTools and EnvironmentsUnderlying Infrastructure that Supports Process