1 / 33

Software Engineering Process

Software Engineering Process. Outline. [Chapter 2 of UPEDU text plus slides] Understanding the Development and Evolution of Software Defining the Software Life cycle and the Software Process Defining Elements of the Software Process

melina
Télécharger la présentation

Software Engineering Process

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 EngineeringProcess

  2. Outline [Chapter 2 of UPEDU text plus slides] • Understanding the Development and Evolution of Software • Defining the Software Life cycle and the Software Process • Defining Elements of the Software Process • Integrating the Software Life Cycle and the Software Process • Customizing the Software Process • Summary

  3. Learning Goals • Distinguish among development processes • Benefits and disadvantages • Understand USDP / RUP • Define software “quality” quantitatively • Must be measurable, plan for collection • Understand documentation needed • Plan for iterative update with each cycle Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  4. Introduction to the Software Engineering process

  5. 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 • Real-time • functions must execute within small time limit • typically microseconds • e.g., radar software • Network (Web) Centric • 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.

  6. Structured Programming (Function Oriented) Function definition handleAccount(…) getDetailsFromUser(…) getAccount(…) doTransaction(…) …… Function definition getDetailsFromUser (…) getName(…) …... Function definition getAccount(…) getFirstName(…) …... …... TOP DOWN Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  7. Object Orientation Real world concepts Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Direct correspondence Customer getFirstName() Transaction execute() Account getDetails() Software design entities Graphics reproduced with permission from Corel. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  8. Advantages of OO • Simplicity: software objects model real world objects • Modularity: data abstraction mean components are decoupled • Modifiability: component changes that respect the public interface do not affect the system • Extensibility: easy to add new objects or extend functionality of existing ones through inheritance • Maintainability: can be maintained separately and on different computers • Re-usability: objects can be reused in different programs and across a network

  9. Components and Reuse Common Object Model Idea (Java Bean or MS COM object) account getName() setName() • Meant to revolutionize software • development • Promotes reusable code, design, • architectures • Based on defined public interfaces • Internal attributes and functions are • abstracted (hidden) from external access • Can be written in different langauges • Reside on different platforms Interface Methods Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  10. Distributed / Network Centric Systems (n-tiered architecture) Customer Desktop DBserve.acadiau.ca webserve.acadiau.ca Browser Admin Admin Admin Tomcat App. Server Postgre SQL DBMS Server Apache HTTP Server Internet port 80 port 8080 Admin Desktop DB .html, .cgi, .class, .jsp Browser

  11. Expectations for SE process, project, product and people

  12. 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

  13. Process alternatives

  14. The Project Roadmap 1. Understand nature & scope of proposed product 2. Select the development process, and create a plan 3. Gather requirements 4. Design the product Various Approaches 5. Build/Implement the product 6. Test the product 7. Deliver and maintain the product Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  15. 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.

  16. 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.

  17. 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.

  18. USDP / RUP Methods • USDP – Unified Software Development Process • An iterative and incremental development process. Time-boxed iterations are grouped in to phases. Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release. • http://en.wikipedia.org/wiki/Unified_Process • RUP – Rational Unified Process • Defines nine disciplines: • Engineering disciplines - Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment; • Supporting disciplines - Configuration and Change Management, Project Management, and Environment. • Four development life-cycle phases … • http://en.wikipedia.org/wiki/Rational_Unified_Process

  19. USDP/RUP: Four Phases of Software LifeCycle • Inception iterations • preliminary interaction with stakeholders (customer, users, owners, financial backers) • Define objectives/requirements • Elaboration iterations • finalization of what is wanted and needed • Define architecture • Construction iterations • focus moves to detailed design, implementation and testing • Complete version of operational system • Transition iterations • Complete documentation • Release product Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  20. USDP/RUP vs. Standard Terminology (Booch, Jacobson & Rumbaugh) Phase of s/w life cycle Individual iteration Inception Elaboration Construction Transition Iter. #k Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 .. … ….. Requirements Analysis Discipline of s/wprocess (Classically called “phases”) Design Implemen- tation Test

  21. USDP/RUP vs. Standard Terminology RUP Terminology Classical Terminology Requirements Analysis Requirements analysis Design Implementation Test Design Implementation Integration Test Where basic classes are selected and related Integration is continual Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  22. RUP Matrix http://www.upedu.org/process/ovu_proc.htm 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 Overview Presentation Sys. Demo.

  23. Advantages of RUP/UPEDU • Focus on important risks / disciplines of each iteration • Detail plan only for current iteration • Coarse planning for next iterations • Allows incremental buildup of system • Reduces risks by identifying major issues early • Iterations allows people time to learn to work more efficiently / effectively

  24. Waterfall versus Iterative (USDP and RUP) • Process Trade-offs

  25. Influencial Factors in Customizinga S/W/ Process • Application domain factors • People and organizational factors • Product life-cycle factors • Process factors • (see page 42 of UPEDU)

  26. Identify the Process You Will Use 1. Decide which of waterfall, spiral, and incremental processes is appropriate Usually a spiral for a semester project Combine: 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. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  27. 5. Documentation

  28. IEEE 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.

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

  30. Example of Hyperlinked Documentation Set 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.

  31. 6. Quality

  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. Produce a Quality Product One way to ... 1. Quantify your quality goals team: # defective requirements,# classesmissing from design, # defects in testing, # defectsfound in operation, # defects per KLOC (1000 lines of code) personal: # defects; code, compile, unit test separately 2. Build inspections and reviews into the schedule • follow the inspection procedure (see figure 1.27) 3. Document your quality goals and procedures • use a documentation standard to avoid missing issues • SQAP and SVVP (see case study for example Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

More Related