1 / 55

Software Engineering Roadmap: Chapter 1 Focus

Software Engineering Roadmap: Chapter 1 Focus. Identify corpor- ate practices - assess capability - specify standards - e.g. CMM level . Plan project. Analyze requirements. Maintain. Development phases. Integrate & test system. Design. Implement. Test units.

shawn
Télécharger la présentation

Software Engineering Roadmap: Chapter 1 Focus

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering Roadmap: Chapter 1 Focus Identify corpor- ate practices - assess capability - specify standards - e.g. CMM level Plan project Analyze requirements Maintain Development phases Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  2. Software Engineering Roadmap: Chapter 1 Focus Plan configuration management - how to manage documents & code - document: SCMP Plan quality assurance - how to ensure quality - document: SQAP Identify corpor- ate practices - assess capability - specify standards - e.g. CMM level Plan verification & validation - verify the product satisfies requirements - validate each phase by showing it succeeded document: SVVP next chapter: Plan development process Plan project Analyze requirements Maintain Development phases Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  3. Some Application Types • Stand-alone • residing on a single computer • not connected to other software or hardware • e.g., word processor • Embedded • part of unique application involving hardware • e.g., automobile controller • Realtime • functions must execute within small time limit • typically microseconds • e.g., radar software • Network • consist of parts interacting across a network • e.g., Web-based video game Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  4. Typical Project Roadmap 1. Understand nature & scope of proposed product 2. Select the development process, and create a plan -- section 4 and chapter 2 3. Gather requirements -- chapters 3 and 4 4. Design and build the product -- chapters 5, 6, and 7 5. Test the product -- chapters 8 and 9 6. Deliver and maintain the product -- chapter 10 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  5. 3. Expectations for process, project, product and people

  6. Five Key Expectations (Humphrey) 1. Predetermine quantitative quality goals Used for process development Part of the project 2. Accumulate data for subsequent use 3. Keep all work visible 4. A. Design only against requirements B. Program only against designs C. Test only against requirements and designs Aspect of the product Influenced by people 5. Measure quality

  7. The Waterfall Model Requirements analysis Produces … specification (text) Design ... diagrams & text Implementation ... code & comments Integration ... entire code Test ... test report, including defect descriptions Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  8. More Detailed Waterfall Version Concept analysis Analysis Design Implementation & unit testing Integration System testing Maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  9. Spiral Development Product: requirements specifications Product:class models + Step n: Analyze requirements Step n+1: Design complete targeted requirements Step n+2: Implement Step n+3: Test Product: code + Product: test results + Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  10. Incremental Development Iteration No. 1 2 3 867 868 Update SPMP1 Test whole Integrate Update Test documentation Test units Update source code Implement Design Update SDD2 Analyze requirements Update SRS3 1 Software Project Mangement Plan (chapter 2); 2 Software Design Document (chapter 5); 3 Software Requirements Specification (chapter 3); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  11. The Unified Software Development Process: Classification of Iterations • Inception iterations: preliminary interaction with stakeholders • primarily customer • users • financial backers etc. • Elaboration iterations : finalization of what’s wanted and needed; set architecture baseline • Construction iterations : results in initial operational capability • Transition iterations : completes product release Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  12. USDP vs. Standard Terminology 2 of 2 USDP Terminology Classical Terminology Requirements Analysis Requirements analysis Design Implementation Test Design Implementation Integration Test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  13. Unified Process Matrix Jacobson et al: USDP Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. ….. ….. Requirements Analysis Amount of effort expended on the requirements phase during the first Construction iteration Design Implemen- tation Test

  14. The Six USDP Models (Views of the Application) Use-case model Test model Analysis model Implementation model Design model Deployment model Graphics reproduced with permission from Corel.

  15. Identify the Process You Will Use One way to ... 1. Decide which of waterfall, spiral, and incremental processes is appropriate. Usually a spiral for a semester project. Combining parts is OK e.g. start with spiral, end with incremental 2. Decide how many iterations. Usually two for a semester project (there are many artifacts to coordinate at the end of each iteration). Three provides lots of practice -- but this is a challenge; make the first increment as minor as possible Three promotes the collection and use of metric data -- use metric data collected from each iteration on next. 3. Rough out a weekly schedule. Coordinate with course assignments. (The next chapter discusses scheduling.) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  16. 5. Documentation

  17. Undocumented Code int a( int i, char c ) { if( c== “m” ) if( i< 1000 ) return 0; else if( i< 10000 ) return 500; else return 1200; else return 1300; } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  18. Somewhat Documented Code int tax( int anEarning, char aStatus ) { if( aStatus == ‘m’ ) if( anEarning < 1000 ) return 0; // no tax for married, < $1000 else if( anEarning < 10000 ) return 500; // married, $1000-$10000 else return 1200; // married, >=$10000 // If not “married”, apply single tax rate of $1300 regardless else return 1300; } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  19. Documented Code /** * This method implements requirement 4.3: * “State tax effective 9/1/98 -12/31/99” * @author Eric J. Braude * @version 2.3.4 (8/6/98) * @param anEarning: earnings 9/1/98 thru 12/31/99 * @param aStatus: ‘m’ signifies “married” (anything * else designates unmarried) */ int tax( int anEarning, char aStatus ) { Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  20. SVVP software validation & verification plan Project Documentation Verification & validation SQAP software quality assurance plan Quality assurance SCMP software configuration management plan Configuration SPMP software project management plan Project status Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  21. Project Documentation SVVP software validation & verification plan Verification & validation SQAP software quality assurance plan Quality assurance SCMP software configuration management plan Configuration SPMP software project management plan Project status Customer-oriented SRS software requirements specifications Requirements Developer-oriented Architecture SDD software design document Design Detailed design Code Source Code STD software test documention Testing User’s manual Operation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  22. One way to ... Identify Your Documentation Needs 1. Document the way documents & code are accessed • otherwise, chaos results • “Software Configuration Management Plan*” -- section tbd 2. Specify who will do what, and when they will do it • “Software Project Management Plan*” -- chapter 2 3. Document what is to be implemented • for yourself, your customer, and your team • “Software Requirements Specification*” -- chapters 3 and 4 4. Document the design of the application • i.e., prior to programming • “Software Design Document*” -- chapters 5 and 6 5. Write and document code • the “code base” -- chapter 7 6. Document the tests you perform • so that they can be re-run, extended etc. • “Software Test Documentation*” -- chapters 8 and 9 * the IEEE standard, which can be used to organize this documentation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  23. 6. Quality

  24. 1. Specify how to manage project documents 2. Identify process QAInvolvement 2. QA reviews process for conformance to organizational policy 1. QA Develops and/or reviews configuration management plans, standards ... QA 3. QA develops and/or reviews provision for QA activities 4. QA reviews, inspects & tests 5. QA reviews, inspects & tests 5. Deliver & main- tain the product 4. Design and build 3. Plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  25. Principle of Inspection AUTHORS CAN USUALLY REPAIR DEFECTS THAT THEY RECOGNIZE Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  26. Nominal process 1. PLANNING OVERVIEW Non-nominal process 2. PREPARATION CAUSAL ANALYSIS 3. INSPECTION 4. REWORK Inspection Process & Example Times 5. FOLLOW-UP 6. IMPROVE PROCESS Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  27. Time/Costs per 100 LoC*-- one company’s estimates Planning 1 hr  (1 person) [ Overview 1 hr  (3-5) ] Preparation 1 hr  (2-4 people) Inspection meeting 1 hr  (3-5 people) Rework 1 hr  (1 person) [ Analysis 1 hr  (3-5) ] Total: approx. 7 - 21 person-hours * lines of non-commented code Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  28. Hours Per Defect: One estimate If defect found ... … at inspection … at integration time time Hours to .. .. detect 0.7 to 2 0.2 to 10 .. repair 0.3 to 1.2 9+ Total1.0 to 3.29.2 to 19+ Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  29. Prepare For & Conduct Inspections One way to ... 1. Build inspections into the project schedule • plan to inspect all phases, starting with requirements • allow for preparation (time consuming!) & meeting time 2. Prepare for collection of inspection data • include # defects per work unit (e.g., KLOC), time spent • develop forms: include description, severity and type • decide who, where, how to store and use the metric data • default: appoint a single person to be responsible • failure to decide usually results in discarding the data 3. Assign roles to participants • Three adequate (author; moderator/recorder; reader) • Two far better than none (author; inspector) 4. Ensure every participant prepares • bring defects pre-entered on forms to inspection meeting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  30. IEEE 730-1989 Software Quality Assurance Plans Table of Contents 1. Purpose 2. Referenced documents 3. Management 3.1 Organization 3.2 Tasks 3.3 Responsibilities 4. Documentation 4.1 Purpose 4.2 Minimum documen- tation requirements 4.3 Other 5. Standards, practices, conventions and metrics 5.1 Purpose 5.2 Content

  31. IEEE 730-1989 Software Quality Assurance Plans Table of Contents 1. Purpose 2. Referenced documents 3. Management 3.1 Organization 3.2 Tasks 3.3 Responsibilities 4. Documentation 4.1 Purpose 4.2 Minimum documen- tation requirements 4.3 Other 5. Standards, practices, conventions and metrics 5.1 Purpose 5.2 Content 6. Reviews and audits 6.1 Purpose 6.2 Minimum requirements 6.2.1 Software requirements review 6.2.2 Preliminary design review 6.2.3 Critical design review 6.2.4 SVVP review 6.2.5 Functional audit 6.2.6 Physical audit 6.2.7 In-process audits 6.2.8 Managerial review 6.2.9 SCMP review 6.2.10 Post mortem review 6.3 Other 7. - 15. -- see next chapter

  32. Meaning of “V&V” (Boehm) Verification: are we buildingthe thing right? Validation: are we buildingthe right thing? Graphics reproduced with permission from Corel.

  33. IEEE 1012-1986 Software Verification & validation Plans Table of Contents (Reaffirmed 1992) 1. Purpose 2. Referenced documents 3. Definitions 4. V&V overview 4.1 Organization 4.2 Master schedule 4.3 Resource summary 4.4 Responsibilities 4.5 Tools, techniques & methodologies 5. Lifecycle V&V 5.1 Management of V&V 5.2 Concept phase V&V 5.3 Requirements phase V&V 5.4 Design phase V&V 5.5 Implementation phase V&V

  34. IEEE 1012-1986 Software Verification & validation Plans Table of Contents (Reaffirmed 1992) 1. Purpose 2. Referenced documents 3. Definitions 4. V&V overview 4.1 Organization 4.2 Master schedule 4.3 Resource summary 4.4 Responsibilities 4.5 Tools, techniques & methodologies 5. Lifecycle V&V 5.1 Management of V&V 5.2 Concept phase V&V 5.3 Requirements phase V&V 5.4 Design phase V&V 5.5 Implementation phase V&V 5.3 Test phase V&V 5.4 Installation & checkout phase V&V 5.5 Operation & maintenance phase V&V 6. Software V&V reporting 6.1 Required reports 6.2 Optional reports 7. V&V administrative procedures 7.1 Anomaly reporting & resolution 7.2 Task iteration policy 7.3 Deviation policy 7.4 Standards, practices & conventions

  35. Produce a Quality Product One way to ... 1. Quantify your quality goals minimum: number of defects per KLOC team: # defective requirements; # classesmissing from design; # defects in testing; # defectsfound in operation. personal: apply # defects to code, compile, unit test separately 2. Build inspections and reviews into the schedule (see scheduling, next chapter) follow the inspection procedure (see figure 1.27 on page ??) 3. Document your quality goals and procedures use a documentation standard to avoid missing issues SQAP (see case study for example); If time allows: SVVP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  36. 7. Documentation management

  37. Example of Hyperlinked Documentation Set (with Dynamic Content shown) STP software test plan Test results* SPMP software project management plan Project status* SRS software requirements specifications Direction of hyperlink Updates* References to all other documents Source Code SCMP software configuration management plan SDD software design document Configuration* Updates* *Dynamic component Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  38. Configuration Management Requirements • Procedure to identify CI's • Locking • to prevent more than one person working on a CI at one time • Authorization to check out • optional • Check-in procedure • authorization process • involves testing etc. • Historical record of prior groupings of consistent CI’s Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

  39. IEEE 828-1990 SCMP Table of Contents 3.2 Configuration control 3.2.1 Requesting changes 3.2.2 Evaluating changes 3.2.3 Approving or dis- approving changes 3.2.4 Implementing changes 3.3 Configuration status accounting 3.4 Configuration audits & reviews 3.5 Interface control 3.6 Subcontractor / vendor control 4. SCM schedules 5. SCM resources 6. SCM plan maintenance 1. Introduction 2. SCM management 2.1 Organization 2.2 SCM responsibilities 2.3 Applicable policies, directives & procedures 3. SCM activities 3.1 Configuration identification 3.1.1 Identifying configu- ration items 3.1.2 Naming configu- ration items 3.1.3 Acquiring configu- ration items Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  40. Plan Configuration Management One way to ... 1. Roughly sketch out your SCMP Determine procedures for making changes Omit tool references unless already identified one See the case study for an example 2. Specify what you need from a CM tool For class use, maybe only locking and backup 3. Evaluate affordable tools against your needs and budget Commercial tools are in wide use For class use, try free document storage web sites; try simple method of checking out e.g. renaming 5. Finalize your SCMP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  41. 8. Introduction to capability assessment

  42. The PSP Evolution (Humphrey) PSP3 Cyclic development 1000’s of lines Skills added to prior stage PSP2.1 Design templates PSP2 Code reviews Design reviews 100’s of lines Additional capability at the same level PSP1.1 Task planning Schedule planning PSP1 Size estimation Test report PSP0.1 Coding standards Process improvement proposal Size measurement PSP0 Current personal process Basic measurements (Adapted from [Hu1] )

  43. TSP Objectives 1 (Humphrey) • Build self-directed teams • 3-20 engineers • establish own goals • establish own process and plans • track work • Show managers how to manage teams • coach • motivate • sustain peak performance Graphics reproduced with permission from Corel.

  44. TSP Objectives 2 (Humphrey) • Accelerate CMM improvement • make CMM 5 “normal” • “Provide improvement guidelines to high-maturity organizations” • “Facilitate university teaching of industrial-grade teams”

  45. The Capability Maturity Model(CMM) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  46. 1. Initial (Software Engineering Institute) Process: undefined, ad hoc Result: outcome depends on individuals Lacking: any reasonable process

  47. 2. Repeatable (Software Engineering Institute) 1. INITIAL Process undefined, ad hoc, depends on individuals Process tracks documents, cost, schedule, functionality (after fact) Result repeatable only on similar projects Lacking:completeprocess

  48. 2. REPEATABLE Basic project management to track cost & schedule, repeatable on similar projects 3. Defined (Software Engineering Institute) Process documented, standardized, tailorable Result consistency Lacking: predictable outcomes

  49. 3. DEFINED Consistent: Documented, standardized, tailorable 4. Managed (Software Engineering Institute) Process detailed measurement; control Result process and products with quantified quality predictability Lacking mechanism for process improvement

  50. 5 Optimized (Software Engineering Institute) 4. MANAGED Predictable: process & products measured Process Continual process improvement through quantitative feedback; Extensible scope Innovative ideas and technologies Graphics reproduced with permission from Corel.

More Related