1. Ch 3: Unified Process CSCI 4320: Software Engineering

2. Unified Process Adaptable methodology for Object- Oriented Software production Iterative and Incremental UML diagrams –Unified Modeling Language (UML) –Redrawn as more knowledge about system is gained (more accurate, extended)

3. UML Class Diagram Models the classes needed and relationship associations, inheritance, compositions and dependencies

4. Iteration and Incrementation The basic software development process is Iterative –Each successive version is intended to be closer to its target than its predecessor An Incremental Process –Miller’s Law : concentrate on ~ 7 chunks –Use stepwise refinement –handle in order of current importance

5. Waterfall vs. Unified Process Waterfall One dimensional Each phase must be completed before you begin the next phase. Unified Process Incremental and Iterative Two dimensional Task is divided into increments (phases) Within each increment the developers have to iterate (workflows) until task is complete Consecutive series of waterfall models

6. Waterfall vs. Unified Process Waterfall Iterative and Incremental Model: Unified Process

7. Phases of the Unified Process Inception : –Determine whether it is worthwhile to develop product –Initial scope and financial details Elaboration: –Refine requirements, produce software management plan Construction –Produce beta-release, initial user manual Transition –Client feedback, correct faults, complete manuals

8. Workflows in the Unified Process Different workflows (activities) are performed over the entire life cycle However, there are times when one workflow may be dominant Core Workflows –Requirements –Analysis –Design –Implementation –Test

9. Requirements Workflow 1.Acquire basic understanding of the application domain (banking, automobile manufacturing) 2.Identify Customer Impact 3.Identify Constraints (deadlines, costs, existing hardware, software) Written in Language of Client Problem: Sometimes the client does not know what is going on in his organization. GOAL: Assist client in gaining understanding of system

10. Analysis Workflow Analyze and refine requirements for detailed understanding Written in language of developer – more precise. Specifications produced are essential for testing and maintenance OO Architectural Design: UML diagrams and descriptions are given to client for confirmation (Use Cases and Class Diagrams) Detailed planning and estimating: Software Project Management Plan with deliverables, milestones and budget GOAL: Spell out what the project is to do

11. Design Workflow Refine analysis artifacts until it is a form that can be implemented by programmers OO Detailed Design: For each class select algorithms and data structures Have a written record of why specific decisions were made Design to allow for future enhancements GOAL: Show how the product will complete specifications

12. Implementation Workflow Code in the chosen language(s) Each programmer is only given the detailed design of his module Only during integration will individual programmer know if architectural design is correct GOAL: Code and Integrate modules

13. Test Workflow Carried out in parallel with all other workflows Artifacts should be properly numbered, cross- referenced and index for traceability  Requirements: –SQA group review requirements  Analysis : – Representatives of SQA, analysis team and clients walkthrough and inspect artifacts –Obtain additional independent estimates of cost and duration GOAL: Find Faults Early!

14. Test Workflow (cont)  Design –Client is not usually present –Look for logic faults, interface faults, error handling, conformance to specifications –Every aspect of design is linked with an analysis artifact  Implementation –Desk check each component as you code –Code review – programmer guides members through listing –SQA performs unit, integration and product ( comparison against specifications ) testing –Client performs acceptance testing GOAL: Find Faults Early!

15. PostDelivery Maintenance Common problem: Lack of existing documentation A proper record must be kept of all changes made and reasons for the change. Testing ensures that: –Required changes have been made –No faults have been introduce