Fesq, 1/3/01 1 16.070Software Process2/12/01 Lecture #3 16.070• Overview of the Software Development Process (SWDP)• Details on the first phase -- Conceiving• Example of Conceiving• Designing, Implementing, Operation• Summary of SWDP• Learning Objectives:! Describe the SW Development Process as a specialization of the genericProduct Development Process (PDP)! Use the First Phase of SWDPFesq, 1/3/01 2 16.070Software Engineering ProcessCD IOGenericPDPNeeds,RequirementsAnalysis,ArchitecturePreliminaryDesignDetailDesignChunkBuilding,TestingIntegration,TestingOperating Maintaining,Upgrading,RetiringUckan Text"C"RequirementsSpecificationAnalysis Design Implementation, Testing andVerification-------LaplanteText"R"Concept "Partitioning" Design Programming, Test ---- MaintenanceGood SWDP is just a specialization of anunderlying Generic PDPFesq, 1/3/01 3 16.070Conceiving: Needs to RequirementsInterpret the Needs (which exist outside your organization)• Who is the customer? Who benefits?• What are their needs? What is the opportunity?• How will they benefit? What value will they derive?Define the Requirements (which are set within your organization)• What exactly is the "problem" to be solved?• What features should be provided?• What functions should be performed?• Must include consideration of technical, financial, regulatory viabilityOutput: A clear, correct, complete andconsistent statement of the goals andrequirements -- What the system will do.Fesq, 1/3/01 4 16.070Conceiving: Analyze the RequirementsHigh level goal (Mission objective, problem statement)Functional Requirements• Function* - the input-output processes or transformations that must beperformed! May include performance (e.g., accuracy)! Should be in solution neutral-form (e.g., avoid reference to structure; code)! Should specifically identify inputs, outputs, internal processes, constraints• Timing - throughput, latency• Human Operator - how the user is informed or operates*Subtly different use than "C function"Fesq, 1/3/01 5 16.070Conceiving: Analyze the Requirements - cont.Non-Functional Requirements• Interfaces - with hardware and software• Resources and constraints - lines of code, budget, schedule, languageto be used, processor to be used• Test and Verification necessary• Other - overall desires of the designer, often with respect to style,enterprise strategy, competitionFesq, 1/3/01 6 16.070Conceiving: Conceptual Design and Architecture• Develop the high level concept of the Design Solution• Partition the problem into modules so that only the function of themodule is visible to the other modules - i.e., the modules hide theinternal features• Partitioning should be based on! Intensity of information exchange among internal steps! Likelihood that internal steps will change! Hiding interfaces to hardware and humans• Interfaces between modules must be "controlled"Output: Functions, concept and high level partitionwhich collectively are known as the architectureFesq, 1/3/01 7 16.070Example - Controlled Flight into TerrainCali-Columbia - On a routine descent, a 757 flies into a mountain, killingall aboardAccident analysis: Pilots became disoriented in unfamiliar terrain,followed flight controller instructions, crashed.Need: ?Fesq, 1/3/01 8 16.070RequirementsDevise a system to inform the pilot of when the path of the aircraft willimpact terrain. The system must use conventional "glass cockpit" flightdisplays, and must be easily understandable. It must integrate intoexisting on-board processors, and use C. It must inform the pilots of"clear ahead," "getting close" or "impact expected."Fesq, 1/3/01 9 16.070Requirements AnalysisHigh level goal:Function:Timing:Human operator:Interfaces:Resources and constraints:Test and Verification:Other:Fesq, 1/3/01 10 16.070Definition of Functions• Determine the relative location of terrain to aircraft! input = aircraft location, terrain profile• Determine the expected path of aircraft! input = velocity vector, navigation guidance• Determine the likelihood of Flight into terrain! No, maybe, yes• Display likelihood to pilot! Output = warning to pilotFesq, 1/3/01 11 16.070ArchitectureMap Functions onto Modulesaircraft positionterrain dataaircraft velocitynav guidancecalculate expected pathcalculate relative positioncompare expected path with relative terrain positioncreate display to pilotdisplayFesq, 1/3/01 12 16.070Designing• Convert requirements + architecture + interface control into detaileddesign specification! What each module should do! How/what it inputs and outputs! What algorithms might be used• Design includes aspects of! Logic design (e.g. pseudo-code, flow charts)! Data design (data representation)Fesq, 1/3/01 13 16.070Designing - cont.• Includes the design of test cases for verification [assurance thatrequirements are met]! Nominal, special, limiting cases! Coverage to insure all code is executed! Most likely cases to find errors• Other design phase decisions! Processor to be used! Language, compiler! Estimates of processor, memory resourcesOutput: The set of information/knowledge artifactswhich completely describe the design, its interfacesand environment/contextFesq, 1/3/01 14 16.070Implementing: Program Building Phase• Build the system by writing the code. Implement, as a program, thealgorithm(s) specified in the design document! Convert each algorithm step into a programming language statement. Writereadable code!! Perform manual simulation! Examine efficiency of execution time and space• Compile and Run Program (or module)• Perform incremental testing (white box testing)! Design Errors occur during analysis, design, implementation! Syntax errors occur during implementation, detected by compiler! Run-time Errors, e.g., divide by 0Fesq, 1/3/01 15 16.070Unit TestModule TestStand-AloneFunctional TestStand-AloneFunctional TestAcceptanceTestComponent TestSystemIntegr ationSystemTestingOn-OrbitCalibrationand Mission SuccessGround-Based andSpace-BasedSystemsSoftware Verification Hardware VerificationImplementing: Integration and Test• Incremental Integration• Formal Testing! Specified test cases! Acceptance criteria set a priori! No program changes allowed!• Subsequent Regression Testing! Changes to code! Changes to EnvironmentOutput - code (or code in embedded system) plus testreport verifying performanceFesq, 1/3/01 16