OO Project Management

Transcription

1 OO Project Management Twin Cities Java User s Group November 17, 1999 Mary Poppendieck Poppendieck.LLC

2 Object Oriented Development Objects Simulate the Real World Example: Process Control On/Off Switch Timer Level Control Setpoint Control OO Design Creates s Instead of defining the task to be performed, the elements that perform the task. OO Programming Assembles Objects Fundamental business operations change slowly, Business rules and information needs change rapidly. ing the business objects creates a system that lasts. November 17, 1999 Poppendieck.LLC 2

3 Software Project Life Cycles Waterfall Spiral Software Concept Requirements Analysis Architectural Design Detailed Design Coding and Debugging System Testing Dean Muench, Sybase, 1994 November 17, 1999 Poppendieck.LLC 3

4 The Unified Process Life Cycle Inception Elaboration Construction Transition Requirements Analysis An Iteration in the elaboration phase Design Implementation Test Iter. #1 Iter. #2 Iter. #n-1 Iter. #n Adapted from The Unified Software Development Process by Ivar Jacobsen, 1999 Iterations November 17, 1999 Poppendieck.LLC 4

5 Several Mini Waterfalls Requirements Analysis Design Implement Test Iteration 1... Iteration 2 Iteration 3... Iteration n Inception Elaboration Transition Example - Six Iterations Inception - One iteration to produce a proof of concept prototype Elaboration - One iteration to produce an architectural prototype One iteration to fix the architectural baseline Construction - One iteration to implement most functionality One iteration to add details and allow maturing Transition - One iteration to go from initial operational capability to full product release November 17, 1999 Poppendieck.LLC 5

6 Iterative Development Visioning Requirements Scoping Planning Future Development Iteration 5 Iteration 6 Holistic Project View Deploy Version 1 Version Release Iteration 4 Beta Release Iteration 3 Most Functionality Iteration 2 Architectural Baseline Iteration 1 Architectural Prototype Proof of Concept Release November 17, 1999 Poppendieck.LLC 6

7 Project Management Tradeoffs Functionality fixed Time Iterative Resources Time Traditional Resources vary Functionality November 17, 1999 Poppendieck.LLC 7

8 OO Development is Based on s The goal of OO development is to move down the pyramid Requirements Application business requirements Business Analysis Business objects collaborating to fulfill requirements degree of abstraction number of objects User Interface Technical Design Implementation Visual interfaces to business object behavior Objects supporting business functionality in the tech environment Executable object code Copyright 1998 Fourth Generation, Inc.

9 OO Development s The Problem Statement and Business Case specify problem scope, solution constraints and priorities. The Requirements specifies problem domain entities, rules and behaviors and how they will interface to users. Technical Requirements constrain how the solution must be structured to deliver behaviors and interfaces. Problem Statement Entities & Process Analysis Objects & Behaviors Capabilities Needed Technical Reqts Design Anticipated Return Requirements Technical & Performance Reqts. Implementation Business Case Workflow User I/F Interfaces & Attributes Copyright 1998 Fourth Generation, Inc.

10 OO Development s The Analysis identifies the required domain objects and their required behaviors. The User Interface specifies domain attributes, business process rules, and user navigation. The Design satisfies all of these together and specifies exactly what needs to be coded. The Implementation is where the programming happens. Problem Statement Entities & Process Analysis Objects & Behaviors Capabilities Needed Technical Reqts Design Anticipated Return Requirements Technical & Performance Reqts. Implementation Business Case Workflow User I/F Interfaces & Attributes Copyright 1998 Fourth Generation, Inc.

11 Use Case The functionality of a system is defined by different use cases, each of which defines what happens when an actor interacts with the system to obtain a result. Withdraw Money Dr. Ivar Jacobsen invented use cases in 1967 to develop large telecommunications switching systems in Sweden. Transfer Money Check Balance In an automated teller machine the client can, for instance, withdraw money from an account, transfer money to an account, or check the balance of an account. These functions correspond to transactions that can be represented with use cases. November 17, 1999 Poppendieck.LLC 11

12 Sample Use Case Format Overview Brief overview of Use Case Pre-conditions Required Pre-conditions Flow of Event(s) Flow of events for the Use Case Post-conditions Required post-conditions Derived Use Cases & Business Rules Use Cases and Business Rules that have been derived from requirements within the Use Case November 17, 1999 Poppendieck.LLC 12

13 Use Cases Drive Iterations Large systems should be delivered in iterations. Iterations are based upon Use Cases. Use Cases are prioritized based on complexity and risk levels. The first iteration begins with a few of the highestpriority Use Cases. Each iteration consists of additional Use Cases decided upon in advance. The number and timing of iterations is based on complexity and specified in the project plan. Each iteration results in a running executable increment. November 17, 1999 Poppendieck.LLC 13

14 Use Cases Drive Development Activity A User Does System Does Activity B Use Case Activity C Workflows Scenarios Interaction Diagrams Business Rules Classes Attributes Methods Relationships Class3 Class1 relates to Class2 Class4 Domains November 17, 1999 Poppendieck.LLC 14

15 Work Products Requirements Artifacts from Rational Unified Process. November 17, 1999 Poppendieck.LLC 15

16 Template for System Use Case and Analysis Scenarios ID SU<n Name <the name should be the goal as a short active verb phrase Goal in context <a longer statement of the goal, if needed Implements <business use case, business use case step(s), or system use case step(s) implemented Primary Actor <a role name for the primary actor, or description Secondary <other Template actors that for participate System in this Use use case Case and Analysis Scenarios Actors Trigger <the action upon the system that starts the use case; may be time event Frequency <how ID often the use case is SU<n expected to happen Name <the name should be the goal as a short active verb phrase Preconditions ID Description Goal in context <a longer statement of the goal, if needed PR1 <statement of what Implements is expected to be true <business before execution use case, of the business use case use (any case ) step(s), or [Implemented system use case step(s) implemented by: <subordinate use Primary case, interaction Actor diagram, <a role or name class responsibility] for the primary actor, or description PR2 < Secondary <other Template actors that for participate System in this Use use case Case and Analysis Scenarios Actors Trigger <the action upon the system that starts the use case; may be time event Frequency <how ID often the use case is SU<n expected to happen Scenarios Name <the name should be the goal as a short active verb phrase Preconditions Success Failure ID Description Goal in context <ID <ID <a longer statement < <ID of the goal, < if needed PR1 <statement of what Implements is expected <nameof to be true <name <business before execution use case, of <name the business use case use (any case ) step(s), or [Implemented system use case step(s) implemented by: <subordinate use Primary case, interaction main Actor diagram, of <a role or name class responsibility] for the of primary failure actor, or description success alternate PR2 < Secondary success <other Template actors that for participate System in this Use use case Case and Analysis Scenarios Actors Trigger <the action upon the system that starts the use case; may be time event ConditionsandSteps Frequency <how often the use case is expected to happen ID SU<n Ref ID Description Seq. Seq. Seq. Seq. Seq. Scenarios 1 S1 <actor <action or sub-use case, written Preconditions as Name <seq. # < Success <the name should be the goal Failure as a short active verb phrase though it succeeds [Implemented by: ID Description Goal in context <ID <ID <a longer statement of the goal, if needed < <ID < <subordinateusecase,interactiondiagram,or PR1 <statement of what Implements is expected <nameof to be true <name <business before execution use case, of <name the business use case use (any case ) step(s), or [Implemented system use case step(s) implemented classresponsibility] by: <subordinate use Primary case, interaction main Actor diagram, of <a role or name class responsibility] for the of primary failure actor, or description 2 C1 <conditioncausingbranching <seq. # < Secondary success [Implemented by: <subordinate use case, PR2 < alternate success <other actors that participate in this use case interaction diagram, or class responsibility] Actors Trigger 3 S2 < < <the action upon the system that starts the use case; may be time event ConditionsandSteps Frequency <how often the use case is expected to happen 4 S3 < Ref ID Description Seq. Seq. Seq. Seq. Seq. Scenarios 5 C2 < 1 S1 <actor <action or sub-use case, written Preconditions as 6 S3 < <seq. # < Success Failure (etc. though it succeeds [Implemented by: ID Description <ID <ID < <ID < ) <subordinateusecase,interactiondiagram,or PR1 <statement of what is expected <nameof to be true <name before execution of <name the use case (any ) [Implemented classresponsibility] by: <subordinate use case, interaction main diagram, of or class responsibility] of failure 2 C1 <conditioncausingbranching <seq. # < success [Implemented by: <subordinate use case, PR2 < alternate success interaction diagram, or class responsibility] 3 S2 < < ConditionsandSteps 4 S3 < Ref ID Description Seq. Seq. Seq. Seq. Seq. Scenarios 5 C2 < 1 S1 <actor <action or sub-use case, written as 6 S3 < <seq. # < Success Failure (etc. though it succeeds [Implemented by: <ID <ID < <ID < ) <subordinateusecase,interactiondiagram,or <nameof <name <name classresponsibility] main of of failure 2 C1 <conditioncausingbranching <seq. # < success [Implemented by: <subordinate use case, alternate success interaction diagram, or class responsibility] 3 S2 < < ConditionsandSteps 4 S3 < Ref ID Description Seq. Seq. Seq. Seq. Seq. 5 C2 < 1 S1 <actor <action or sub-use case, written as 6 S3 < <seq. # < (etc. though it succeeds [Implemented by: ) <subordinateusecase,interactiondiagram,or classresponsibility] 2 C1 <conditioncausingbranching <seq. # < [Implemented by: <subordinate use case, interaction diagram, or class responsibility] 3 S2 < < 4 S3 < 5 C2 < 6 S3 < (etc. ) Template for System Use Case and Analysis Scenarios ID SU<n Name <the name should be the goal as a short active verb phrase Goal in context <a longer statement of the goal, if needed Implements <business use case, business use case step(s), or system use case step(s) implemented Primary Actor <a role name for the primary actor, or description Secondary <other Template actors that for participate System in this Use use Case case and Analysis Scenarios Actors Trigger <the action upon the system that starts the use case; may be time event Frequency <how ID often the use case SU<n is expected to happen Name <the name should be the goal as a short active verb phrase Preconditions ID Description Goal in context <a longer statement of the goal, if needed PR1 <statement of what Implements is expected to be true <business before execution use case, of business the use case use case (any ) step(s), or system [Implemented use case step(s) implemented by: <subordinate Primary use case, Actor interaction diagram, <a role name or class for responsibility] the primary actor, or description PR2 < Secondary <other Template actors that for participate System in this Use use case Case and Analysis Scenarios Actors Trigger <the action upon the system that starts the use case; may be time event Frequency <how often the use case is expected to happen ID SU<n Scenarios Preconditions Name <the Success name should be the goal Failure as a short active verb phrase ID Description Goal in context <ID <a longer <ID statement of the goal, if needed < <ID < PR1 <statement of what Implements is expected <nameof to be true <business before <name execution use case, of business the <name use use case case (any step(s), ) or system [Implemented use case step(s) implemented by: <subordinate Primary use case, interaction Actor main diagram, <a role of name or class for responsibility] the primary of failure actor, or description Secondary PR2 < success <other alternate success actors that participate in this use case Actors Trigger <the action upon the system that starts the use case; may be time event ConditionsandSteps Frequency <how often the use case is expected to happen Ref ID Description Seq. Seq. Seq. Seq. Seq. Scenarios 1 S1 <actor <action or sub-use case, written Preconditions as <seq. # < Success Failure though it succeeds [Implemented IDby: Description <ID <ID < <ID < <subordinateusecase,interactiondiagram,or PR1 <statement of what is expected to <nameof be true before <namexecution of the <name use case (any ) [Implemented classresponsibility] by: <subordinate use case, interaction main diagram, of or class responsibility] of failure 2 C1 <conditioncausingbranching <seq. # < success [Implemented by: <subordinate use PR2 case, < alternate success interaction diagram, or class responsibility] 3 S2 < < ConditionsandSteps 4 S3 < Ref ID Description Seq. Seq. Seq. Seq. Seq. Scenarios 5 C2 < 1 S1 <actor <action or sub-use case, written as 6 S3 < <seq. # < Success Failure (etc. though it succeeds [Implemented by: <ID <ID < <ID < ) <subordinate use case, interaction diagram, or <nameof <name <name classresponsibility] main of of failure 2 C1 <condition causing branching <seq. # < success [Implemented by: <subordinate use case, alternate success interaction diagram, or class responsibility] 3 S2 < < ConditionsandSteps 4 S3 < Ref ID Description Seq. Seq. Seq. Seq. Seq. 5 C2 < 1 S1 <actor <action or sub-use case, written as 6 S3 < <seq. # < (etc. though it succeeds [Implemented by: ) <subordinateusecase,interactiondiagram,or classresponsibility] 2 C1 <conditioncausingbranching <seq. # < [Implemented by: <subordinate use case, interaction diagram, or class responsibility] 3 S2 < < 4 S3 < 5 C2 < 6 S3 < (etc. ) Template for System Use Case and Analysis Scenarios ID Name Goal in context Implements Primary Actor Secondary Actors Trigger Frequency Preconditions ID Description PR1 PR2 SU<n <the name should be the goal as a short active verb phrase <a longer statement of the goal, if needed <business use case, business use case step(s), or system use case step(s) implemented <a role name for the primary actor, or description <other actors that participate in this use case <the action upon the system that starts the use case; may be time event <how often the use case is expected to happen <statement of what is expected to be true before execution of the use case (any ) [Implemented by: <subordinate use case, interaction diagram, or class responsibility] < <ID <nameof main success Scenarios Success <ID < <name of alternate success <ID <name of failure Failure < ConditionsandSteps Ref ID Description Seq. Seq. Seq. Seq. Seq. 1 S1 <actor <action or sub-use case, written as <seq. # < though it succeeds [Implemented by: <subordinateusecase,interactiondiagram,or classresponsibility] 2 C1 <conditioncausingbranching <seq. # < [Implemented by: <subordinate use case, interaction diagram, or class responsibility] 3 S2 < < 4 S3 < 5 C2 < 6 S3 < (etc. ) Work Products Evolve Throughout the Project Problem Statement and Business Case Business Process shows flow between Business Use Cases System Use Cases automate Business Use Case steps Analysis Scenarios extend behavior of System Use Cases Business Case CPN is not flexible enough to support our constantly changing Problem products and Statement network configurations, and as as result, CPN CPN is maintenance not flexible enough to has become support extremely our constantly cumbersome changing and products resource and intensive. network If CPN configurations, is to be the and as central repository as result, CPN of provider maintenance and network has become information, extremely it must be cumbersome able to accommodate and resource all current intensive. and future If CPN needs is to for be the all lines central of business. repository of provider and network information, it must be able to accommodate all current and future needs for all lines of business. U E E E Name, goal and steps define details of Business Use Cases Name, goal, primary actor, preconditions, steps, postconditions define System Use Case details Success and failure Analysis Scenarios describe all possible threads. Variations describe differences to be dealt with later Use Case Templates Copyright 1998 Fourth Generation, Inc.

17 OO Projects are Different Incremental implementation Iterative approach to workproducts Extensive Customer involvement Stability under rules changes due to domain modeling Adaptability to change Flexible functionality with predictable budget and schedule November 17, 1999 Poppendieck.LLC 17

18 Impact on Managing Projects Scheduling and staff loading are different: More time in requirements and analysis modeling Less time coding and testing Validation throughout the Life Cycle Deliverables Come Sooner. So does feedback. Workproducts are living, evolving documents: Configuration Management is essential. The focus shifts from project phase to phase: Early focus on Requirements and Analysis Later focus on Design and Implementation November 17, 1999 Poppendieck.LLC 18

19 Project Management Responsibilities Business Case Development Plan Project Plan Iteration Plan Risk Assessment Staffing Small, highly skilled, requirements and analysis staff. Experienced Technical Lead to design system architecture. Process Management (See next page.) Status Reports November 17, 1999 Poppendieck.LLC 19

20 Process Management Process Tailoring and Conformance Define the Process: Determine the techniques, tools and standards used to produce and validate work products. Tailor the Process: Select the work products to be produced Manage the Process: Establish a structure in which the process generates valid work products Architectural Vision Established by Technical Lead Assessed and supported by Project Manager Implemented through the Process Configuration Management November 17, 1999 Poppendieck.LLC 20