Software Engineering Process Learning Goals Distinguish among development

Software Engineering Process

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

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.

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

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

1. & 2. Introduction to the Software Engineering process

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.

Structured Programming (Function Oriented) Function definition handle. Account(…) get. Details. From. User(…) get. Account(…) TOP do. Transaction(…) …… Function definition get. Details. From. User (…) get. Name(…) …. . . Function definition get. Account(…) get. First. Name(…) …. . . DOWN …. . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

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

Components and Reuse Common Object Model Idea (Java Bean or Python lib object) account get. Name() set. Name() Interface Methods • 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 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

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

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

4. Process alternatives

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.

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

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

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

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

USDP/RUP: Four Phases of Software Life Cycle • 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.

USDP/RUP vs. Standard Terminology (Booch, Jacobson & Rumbaugh) Phase of s/w life cycle Individual iteration Inception Elaboration Construction Transition Prelim. Iter. … Iter. #k iterations #1 #n #n+1 #m #m+1 Requirements Analysis Design Implementation Test “discipline’ or “core workflows” of s/w process (Classically called “phases”)

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

USDP/RUP Matrix http: //www. upedu. org/process/ovu_proc. htm Inception Elaboration Jacobson et al: USDP Construction Prelim. Iter. iterations #1 #n #n+1 Requirements Analysis Design Implementation Test …. . Transition Iter. …. . #m #m+1 Iter. #k Amount of effort expended on the requirements phase during the first Construction iteration Overview Presentation Sys. Demo.

Advantages of USDP/RUP • 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

Waterfall versus Iterative (USDP and RUP) • Process Trade-offs Factor Ease of Doc. Customer Interaction Prob. of good design Waterfall Easier Harder Iterative Harder Easier Medium Leverage proj. data Harder Easier (Spiral) Harder (Increm. ) Medium/ Easier Medium Project Easier Management

Influencial Factors in Customizing a S/W/ Process • • Application domain factors People and organizational factors Product life-cycle factors Process factors

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.

5. Documentation

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

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

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

6. Quality

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

Produce a Quality Product 1. Quantify your quality goals team: # defective requirements, # classes missing from design, # defects in testing, # defects found 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.