1/11/2008

Overview Slide 2.1 Chapter 3 The Unified Process (3.1) Slide 2.2 z Software life-cycle models z Until recently, three of the most successful object- – Theoretical model oriented methodologies were – Iterative and incremental model – ’ s method – Code-and-fix life-cycle model – Ivar Jacobson’s Objectory – Waterfall (documentation driven model) – Jim Rumbaugh’s Object Modeling Technique (OMT) – Rapid prototyping life-cycle model – Open-source life-cycle model – Agile processes – Synchronize-and-stabilize life-cycle model – Spiral life-cycle model (risk driven) z Unified process z Capability Maturity Models (CMM) CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

3.2 Iteration and Incrementation within the Object-Oriented Paradigm The Unified Process (contd) Slide 2.3 Slide 2.4 z In 1999, Booch, Jacobson, and Rumbaugh z The Unified Process is a modeling technique published a complete object-oriented analysis and – A model is a set of UML that represent design methodology that unified their three various aspppects of the software product we want to separate methodologies develop – Original name: (RUP) – Next name: Unified Software Development Process z UML stands for unified modeling language (1997 (USDP) by three Amigos) – Name used today: Unified Process (for brevity) – Graphically represent (model) the target software product

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

1 1/11/2008

Iteration and Incrementation within the Object-Oriented Paradigm (contd) Slide 2.5 3.10 The Phases of the Unified ProcessSlide 2.6 z The object-oriented paradigm is iterative and z The increments are identified as phases incremental in nature – There is no alternative ttoo repeated iteration and incrementation until the UML diagrams are satisfactory

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue Figure 3.1

Requirements Workflow Slide 2.7 Requirements Pyramid Slide 2.8 z From Chapters 1 and 2 of the book “Requirement Management Using IBM Rational RequisitePro” – Online simplified version » http://www.ibm.com/developerworks/rational/library/04/r-3217/ z Definitions – Requirement – a condition or capability to which a system must conform » Capability – the needs of customers » Condition – constraints – Stakeholder – someone who is affected by the system that is being developed » Customer » User – A travel agency website CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

2 1/11/2008

Requirements Pyramid Slide 2.9 Requirements Pyramid Slide 2.10 z Need z Supplementary requirement – a requirement from a stakeholder – Other requirement (usually nonfunctional) that cannot – Usually 5-15 high level needs be captured in use cases » “Data should be persistent” » “System should use Oracle 9i” z Feature z Test case – a service provided by the system, usually formulated by – A specification of test inputs, execution conditions, and a business analyst; a purpose of a feature is to fulfill a expected output need z Scenario » “System should use a relational database” – A specific sequence of actions; a path through a use z Use cases case; an instance of the – a description of system behavior in terms of sequences z Vision statement of actions – Needs and features

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

Traceability Slide 2.11 RequisitePro Slide 2.12 z Everything z A CASE tool z Nothing more – Integrated with z Impact word » Text-based – Management of traceability

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

3 1/11/2008

Use Cases Slide 2.13 Uses Cases Slide 2.14 z Goals of use cases z Format – To facilitate agreement between developers, customers, – Brief description and users about the syy(stem (contract ) – Flow of events – A basis for use-case realizations » Basic flow – An input for test cases » Alternative flow 1 » Alternative flow 2 – Special requirements – Preconditions – PtPost-conditions – Extension points – Context – Activity diagram

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

Use Cases Slide 2.15 Analysis and Design Workflow (Rational ROSE)Slide 2.16 z Example (the basic flow of the “place an order” z ROSE= Rational Object Oriented Software Engineering use case in an online bookstore project) z Used for object-oriented – B1 User enters web site address in the browser. System displays login page. analysis, modeling, design, and – B2 User enters an email address and a password. System confirms correct login, presents main page, and prompts for a search string. construction. – B3 User enters search string – partial name of a book. System returns all books z A set of visual modeling matching search criteria. components. – B4 User selects a book. System presents detailed information about a book. – B5 User adds the book to a shopping cart. Shopping cart contents is presented to the user. – B6 User selects "proceed to checkout" option. System asks for confirmation of a shipping address . – B7 User confirms shipping address. System presents shipping options. – … z Example (alternative flows) – Unregistered user – … – Invalid credit card CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

4 1/11/2008

Diagrams in Rational Rose Slide 2.17 Use Case Diagram Slide 2.18 z Structural Diagram z Actor – – – z Behavioral Diagram – Use-Case Diagram – Interaction Diagram » Sequential Diagram » Collaboration Diagram – State Diagram – Activity Diagram

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

Activity Diagrams Slide 2.19 Class Diagrams Slide 2.20

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

5 1/11/2008

Sequence Diagrams Slide 2.21 Test Workflow Slide 2.22

z From Use Cases to Test Cases (functional testing) – Scenarios

Infinite loops – 2 times

CS510 Software Engineering at Purdue Explosion – exclude CS510unreasonable Software Engineering atcombination Purdue

From Scenarios To Test Cases Slide 2.23 Step 1. Identify Variables Slide 2.24 z Identify variables for each use case step z Example – B2 User enters an email address and a password. System confirms z Identify significantly different options for each correct login, presents main page, and prompts for a search string. variable » Email and password z Combine options to be tested into test cases – B3 User enters search string – partial name of a book. System returns all books matching search criteria. z Assign values to variables » Search string – B4 User selects a book. System presents detailed information about a book. » Book selection ……

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

6 1/11/2008

Step 2. Identify Options Slide 2.25 Option Examples Slide 2.26

Step Variable Options to be tested z Options are “significantly different” B1 Website Actual URL One more Min Max – Trigger different flow than Very long Invalid (no B2 Email Regular Blank allowed (1 allowed (50 allowed (51 (257 char) @ sign) char) char) » Vaadlid v s. inv adusedsalid user ids char) One more – Trigger different error messages Min Max Too short than Very long B2 Password Regular Blank allowed (6 allowed (10 (5 char) allowed (11 (257 char) » “Email too long” vs. “Invalid email address” char) char) char) One more – Trigger different UIs Min Max Search than B3 Regular Blank allowed (1 allowed » Credit card vs. Gift card string allowed char) (300 char) (301 char) – Trigger different business rules First Last B4 Selection » Overnight shipping <6pm and >6pm selection selection Add to Action B5 shopping – Boundary values selection cart Action Proceed to … … B6 selection checkout Confirm the Shipping B7 address on address file Shipping B8 5 days 3 days 2 days Overnight CS510 Software Engineering at Purdue method CS510 Software Engineering at Purdue

Step 3. Combine Options Into Test CasesSlide 2.27 Step 3. Combine Options Into Test CasesSlide 2.28

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

7 1/11/2008

Step 4. Assign Values to Variables (T1)Slide 2.29 Rational Robot and Test Manager Slide 2.30

Variable or Expected Step number Value Actual result Pass/Fail Comments selection result z Robot www.amazon. B1 Website Logon Screen com – GUI scripts for functional testing jsmith@hotmai B2 Email lcoml.com – Virtual users (VU) sessions for performance testing B2 Password Johnsm Main Screen z Test Manager B3 Search string “Rational” List of books

B4 Book selection First selection Book details – Scripts play back. Action Add to B5 Cart contents selection shopping cart Action Proceed to Prompt for B6 selection checkout address Shipping Confirm the Prompt for B7 address address on file shipping Shipping Prompt for B8 5 days method payment Confirm the Payment Prompt for B9 credit card on method confirmation file Action B10 Place an order Order number selection CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

3.12 Improving the Software Process (OOSE C3)Slide 2.31 What is the CMM (I)?... Slide 2.32

z The fundamental problem with software – The software process is badly managed z Software process improvement initiatives “The CMM is a 5 -level model where each – Capability maturity model (CMM) by Software maturity level is “a well-defined evolutionary Engineering Institute (SEI) plateau on the path towards becoming a mature – ISO 9000-series software organisation”.” – ISO/IEC 15504 SEI

SEI CMM CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

8 1/11/2008

® What is the CMM (II)?... Slide 2.33 SEI CMM Levels Slide 2.34

continuous improvement OPTIMISING “ The CMM provides a conceptual structure for improving the management and predictable MANAGED change development of software products in a standard, management disciplined and consistent way. “ consistent DEFINED quantitative SEI management (process vs. product?) discipline REPEATABLE engiiineering management

INITIAL project management

SEI CMM Software Measurement CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

Level 1. Initial Level Slide 2.35 Level 2. Repeatable Level Slide 2.36 z Ad hoc approach z Basic software management – The entire process is unpredictable – Management decisions should be made on the basis – Management consists of responses to crises of ppprevious experience with similar products – Measurements (“metrics”) are made – These can be used for making cost and duration z Most organizations world-wide are at level 1 predictions in the next project – Problems are identified, immediate corrective action is taken

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

9 1/11/2008

Level 3. Defined Level Slide 2.37 Level 4. Managed Level Slide 2.38 z The software process is fully documented z Quality and productivity goals are set for each – Managerial and technical aspects are clearly defined project – Continual efforts are made to improve quality and – Quality and productivity are continually monitored productivity – Statistical quality controls are in place – Reviews are performed to improve software quality – CASE environments are applicable now (and not at levels 1 or 2)

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

Level 5. Optimizing Level Slide 2.39 Summary Slide 2.40 z Continuous process improvement – Statistical quality and process controls – Feedback of knowledge from each project to the next

Figure 3.3

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

10 1/11/2008

Experiences with SW–CMM Slide 2.41 Goals Slide 2.42 z It takes: z Original goal: – 3 to 5 years to get from level 1 to level 2 – Defense contracts would be awarded only to capable – 1. 5 to 3 years from level 2 to level 3 firms – SEI questionnaires highlight shortcomings, suggest ways to improve the process z The U.S. Air Force stipulated that every Air Force contractor had to attain SW–CMM level 3 by 1998 – The DoD subsequently issued a similar directive

z The CMM has now gone far beyond the limited goal of improving DoD software

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

3.15 Costs and Benefits of Software Process ImprovementSlide 2.43 Costs and Benefits of Software Process Improvement (contd)Slide 2.44 z Hughes Aircraft (Fullerton, CA) spent $500K z Tata Consultancy Services (India) used ISO 9000 (1987–90) and CMM (1996–00) – Savings: $2M per year, moving from level 2 to level 3 – Errors in estimation decreased from 50% to 15% – Effectiveness of reviews increased from 40% to 80% z Raytheon moved from level 1 in 1988 to level 3 in 1993 z Motorola GED has used CMM (1992–97) – Productivity doubled – Results are shown in the next slide – Return of $7 .70 per dollar invested in process improvement

CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

11 1/11/2008

® Results of 34 Motorola Projects Slide 2.45 Applying the CMM Slide 2.46

z Self assessment possible because the CMM document is detailed, cheaper to do in-house, lack of experience/independence

z Formal assessment Figure 3.4 independent and experienced, identifies improvement priorities z MEASL – Million equivalent assembler source lines z Software Capability Evaluation z Motorola does not reveal productivity data to identify qualified contractors – Productivity is measured relative to that of a selected level-2 project – No fault or productivity data available for level-1 projects

(by definition) SEI CMM CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

® Assessment Steps Slide 2.47 ISO9001 and CMM compared Slide 2.48

CMM ISO 9001 • Team selection small, qualified team chosen; as independent as possible Specific to software development Intended for most industries Used in USA, less widely Recognised and accepted in most elsewhere countries • Maturity questionnaire Provides detailed and specific Specifies concepts, principles and sample of depts/projects is questioned; results are analysed for further definition of what is required safeguards that should be in place investigation/clarification for given levels Assesses on 5 levels Establishes one acceptable level • Site visit CMM Level 2 - 3 ≈ ISO 9001 actual depts/projects visited; interviews conducted, documents reviewed, Relevant to s/w development Stabilises the customer - supplier priority process areas scrutinised process relationship No time limit on assessment Certification valid for three years • Presentation of findings to management No ongoing audit Auditors may return for spot checks 2 parts - CMM assessment of current level of orgg,., identify streng ths & during the lifetime of the certificate weaknesses and key improvement areas

Software Measurement SEI CMM CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue

12