7. Project Management

Transcription

1 Subject/Topic/Focus: 7. Project Management Management of Systems Engineering Processes Summary: Project management Systems engineering Maturity model and process improvement Literature: Ian Sommerville: Software Engineering. Addison-Wesley 1996 (5th ed.). Grady Booch: Best of Booch. SIGS Roger Bate et.al.: A Systems Engineering Capability Maturity Model, Version 1.1. Software Engineering Institute Influences on Projects Maturity of technology: opportunities... risks Business influence: prototypical... mission-critical Implementation culture: Cobol... LISP... Java Domain: Nuclear plant control... management information system... video game Experience of team members: rookie... freak... expert Scope: isolated application... enterprise-wide information system

2 OO Project Maturity Distinguish isolated application development of independent applications from enterprise-wide development of application families. Project maturity of object-orientation shows in terms of architecture consolidate repeating (consistent) patterns institutionalize a chief architect process formalize, validate, re-evaluate and re-design the process continuously refine the architecture (patterns) regularly estimating costs & gains documentation systems have to endure the lifetimes of their creators standardize, deliver and review (architecture) documentation [Booch] 7.3 OOAD Project Experience Do Do not not underestimate the the importance of of failure failure in in object-oriented development. [Booch] The first projects using a new technology, method, language,... will fail - so their goal is to gain experience. Keep them small - a company that depends on the production results of these projects is doomed. A customer who depends on his business processes, who cannot afford even minutes of down-time (consider bank or stock market transactions), does not approve the elegance, modernity, reusability, extensibility,... of your solution, but its reliability. The technology (method, language,...) used in a project does not determine the result. It is determined by the team who drives the project, the experience of the team members and their cooperative work. To To remain remain nimble nimble in in the the marketplace, you you have have to to know know when when to to establish corporate guidelines and and when when to to break break them. them. [Booch]

3 7.1 Project Management Management techniques derived from small-scale projects do not scale up to large systems development. Projects deficiences: Software [Sommerville] is delivered late, is unreliable, costs several times the original estimates, exhibits poor performance, does not meet its requirements. Note: These are technology issues, but caused by management! Challenges for software managers in contrast to other engineering disciplines: The product is intangible. Progress cannot be reviewed directly. There is no standard process for software development. Large software projects are often one-of projects. Experience may not be transferred easily. 7.5 Software Manager Responsibilities Proposal writing objectives justification rough working plan cost and schedule estimates Project costing estimate book-keeping & re-estimation Project planning and scheduling identify activities, milestones, deliverables plan development guide estimate resources required Project monitoring and reviews keep track of progress compare actual to planned progress informal on daily basis formal at scheduled reviews adapt to objective changes Personnel selection and evaluation weigh experience vs. cost vs. availability consider skill development (learning process) Report writing and presentation concise, coherent, abstract for clients & contractors

4 Introduction Software Development Plan supplemented by by further further plans, plans, see see next next slide slide objectives & constraints (budget, time, staff,...) Project organization team organization & people involved & roles assigned Risk Analysis identification and likelihood of risks & risk reduction strategies Hardware and software resource requirements including prices and delivery schedule Work breakdown activities & milestones & deliverables of activities Project schedule dependencies between activities & estimated milestone dates & allocation of people to activities Monitoring and reporting mechanisms including management report structure & delivery dates 7.7 Auxiliary Plan Types Quality plan describes project quality procedures & standards Validation plan describes system validation approach, resources & schedule Configuration management plan describes configuration management procedures and structures Maintenance plan predicts system maintenance requirements, costs and effort Staff development plan describes how skills and experience of project team members will be developed Planning takes most management time!

5 Project Planning Procedure Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverables while project has not been completed or cancelled loop Draw up project schedule Initiate activities according to schedule Wait (for a while, usually 2-3 weeks) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables if (problems arise) then Initiate technical review and possible revision end if end loop + exceptions! 7.9 Activity Organization Managers need information, provided by documents, to control the process. Milestone: End-point of activity. Coding 80 % complete. short formal progress report Deliverable: milestone delivered to customer. This This is is not not a milestone because it it cannot cannot decided if if it it is is reached. Activities Feasibility study followed by Requirements analysis followed by Prototype development Feasibility report Requirements definition Evaluation report Milestones Deliverable

6 Task Duration and Dependencies Task/Activity Duration (days) depends on T1 15 T2 8 T3 15 T1, T2 T4 5 T2 T5 15 T3, T4 T6 20 T1, T2 Typical duration of tasks/activities: 1-10 weeks finer grained (days): increases time needed for reviewing and re-scheduling coarser grained (months): decreases control and delay detection 7.11 Activity Network activity contributes to milestone task/activity with duration 4/7/98 Start 15 T1 8 T2 activity contributes to several milestones milestone with delivery date 15 25/7/98 T3 M1 14/7/98 5 M2 T4 15/8/98 M3 milestone results are used in activity 20 T6 milestone is built from several activities 15 T5 6/9/98 Finish critical path: any delay here causes delay of the project Start T1 M1 T3 M3 T5 Finish

7 PERT Chart sophisticated variant of activity networks distinguishes pessimistic/likely/optimistic duration/dates leading to many potential critical paths critical path analysis only with tool-support 7.13 Activity Bar Chart 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 Start planned task duration T1 T2 M2 T4 M1 T3 T6 possible delays without affecting the project schedule M3 T5 Gantt Gantt chart chart Finish

8 Staff Allocation 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 Peter T1 T5 Paul T2 T3 Mary T4 T6 Include time for holidays, training courses, other projects. Be prepared to handle delays. People may not be available. Specialists cannot be replaced Capability Modeling The Systems Engineering Capability Maturity Model (SE-CMM) describes essential elements of an organization s systems engineering process. Business goal: Organization, that efficiently translates customer needs into a product that effectively meets those needs. Key to this activity: Systems Engineering. Goal of SE-CMM: Measure and enhance performance

9 Systems Engineering: Example Denver International Airport, built in the early 1990s Opening delayed for 25 months $375,000,000 loss Costs per day of delay: $500,000 Main reason for delay: faulty system s software and hardware of baggage system using telecars Errors occurred although the prime-contractor was well experienced, redundancies were built into the system and the components were tested. But: The size and complexity of the system requirements were unique. [Linda [Linda Geppert: Faults Faults and and Failures. IEEE IEEE Spectrum, August August 1994] 1994] 7.17 Value-Adding Processes in Enterprises Product/Service Quality Enterprise Capability People Capability Process Capability Technology Capability

10 Systems Engineering... is the selective application of scientific and engineering efforts to transform an operational need into a description of the system configuration which best satisfies the operational need according to the measures of effectiveness; integrate related technical parameters and ensure compatibility of all physical, functional, and technical program interfaces in a manner which optimizes the total system definition and design; integrate the efforts of all engineering disciplines and specialties into the total engineering effort. [USALMC Army Army Field Field Manual: Systems Engineering. Training Support Center, Center, Ft. Ft. Eustis, Eustis, 1978] 1978] Project Management: Balances cost, schedule, quality, and functionality objectives. Systems engineering provides engineering viewpoint in business decisions SE-CMM: Model Architecture Domain Aspects Capability Aspects Process Area Categories Engineering - Project - Organization Capability Levels (0-5) applied to each process area Process Areas Common Features Base Practices Systems Engineering Generic Practices Process Management

11 Focus of SE-CMM Organizational Factors Culture Size Structure Roles SE-CMM Guidance Focus Area (Domain) Capability Support + = Organization s Systems Engineering Process Development Design Development Validation & Verification Business Factors Strategic Focus Market Pull vs. Technology Push Contract vs. Market Driven Technology/Method Support 7.21 Systems Engineering: Definitions Basic terms of systems engineering (see next slides): Organization: projects & infrastructure Project: process-oriented development of a product System: composite, product Process: set of activities that transform work products

12 Organization unit within a company, the whole company or other entity projects + infrastructure projects many projects are managed as a whole projects share common policies infrastructure supports projects supports common strategic, business and process-related functions has to be maintained business goal: be effective in producing, delivering, supporting and marketing products, i.e., be successful in terms of profit 7.23 Project aggregate of effort and resources focused on developing and/or maintaining a product own funding, cost accounting, delivery schedule structured as (part of) organization, i.e., team, task force process areas engineering project organization

13 System integrated composite of people, products, and processes that provide a capability to satisfy a need or objective an assembly of things or parts forming a complex or unitary whole a collection of components organized to accomplish a specific (set of) function(s) an interacting combination of elements, viewed in relation to function product: hardware and/or software and/or service sum of products delivered to customers or users all elements and their interfaces are treated in a disciplined and systematic way 7.25 Process set of activities performed to achieve a given purpose activities may be performed iteratively, recursively, and/or concurrently may transform work products, i.e., all documents, files, data, etc. generated while performing a process. activity sequences are determined by (input) work products, resources, and management control well-defined process activities input and output work products of each activity mechanisms to control the performance of activities defined process formally described used/performed by systems engineers

14 Process Category SE-CMM: Domain Aspect Set of process areas addressing the same general area of activity. Here: engineering, project, organization Process Area Set of related practices, which when performed collectively, can achieve the purpose of the process area. In systems engineering18 different process areas can be isolated (see next slide). Base Practice Engineering or management practice (activity) that addresses the purpose of a particular process area and thus belongs to it. Deliver work products Process Areas in Systems Engineering Process Area Category: Engineering Understand Customer Needs and Expectations Analyze Candidate Solutions Derive and Allocate Requirements Integrate Disciplines Integrate System Verify and Validate System Evolve System Architecture Process Area Category: Project Plan Technical Effort Monitor and Control Technical Effort Process Area Category: Organization Define and... Improve Organization s Systems Engineering Process Manage SE Support Environment Ensure Quality Manage Configurations Manage Risk Coordinate with Suppliers Manage Product Line Evolution Provide Ongoing Knowledge and Skills

15 Processes: Systems Engineering & Project Management Characteristics of Systems Engineering Processes: problem-solving process transforms customer needs and requirements into a life-cycle balanced solution set of system product and process designs generates information for decision makers provides information for the next product development or acquisition phase base practices are part of of the systems engineering process Characteristics of Project Processes: management process set of activities and infrastructures used to predict, evaluate, and control the performance of a process product- and process-related planning, performance, evaluation, monitoring, and corrective action 7.29 SE-CMM Architecture: Capability Aspects Process Capability: quantifiable range of expected results that can be achieved by following a process predicts achievement of cost, schedule, functionality, and quality targets Institutionalization: building of infrastructure and corporate culture methods, practices, and procedures defined and performed independent of time and persons Capability Maturity: stages through which processes progress when defined, implemented, and improved measurement of current practice guide for improvement

16 Capability Level: Capability Maturity Model Set of common features (sets of activities) that work together to provide a major enhancement in the capability to perform a process. example: 2 Planned and Tracked Common Feature: Set of practices that address the same aspect of process management or institutionalization. Example: 2.1 Planning performance Generic Practice: Series of activities that apply to all processes. Addressing management, measurement, and institutionalization. Enhances the capability to perform a process. Example: Document the process 7.31 Capability Levels: Overview Capability Level 5: Continuously Improving 4: Quantitatively Controlled 3: Well Defined 2: Planned and Tracked 1: Performed Informally Common Features (overview) 5.1 Improving organizational capability 5.2 Improving process effectiveness 4.1 Establishing measurable quality goals 4.2 Objectively managing performance 3.1 Defining a standard process 3.2 Perform the standard process 2.1 Planning performance 2.2 Disciplined performance 2.3 Verifying performance 2.4 Tracking performance 1.1 Base practices performed

17 Capability Levels 0 & 1 0: Not Performed Base practices are not performed. Work products are not identifiable or accessible. 1: Performed Informally: Features and Practices Base practices are generally performed. Performance may not be planned or tracked. Performance depends on individual knowledge and effort. Work products (demos) are identifiable. 1.1 Base Practices are Performed Perform the process Common Feature Generic Practices 7.33 Capability Level 2 2: Planned and Tracked: Features and Practices Base practices are planned and tracked. Performance is verified. Work products conform to standards and requirements. Performance is measured and management may react on measures. 2.1 Planning Performance Allocate resources & people Assign responsibilities Document the process Provide tools Ensure training Plan the process 2.2 Disciplined Performance Use plans, standards, and procedures Do configuration management 2.3 Verifying Performance Verify process compliance Audit work products 2.4 Tracking Performance Track with measurement Take corrective action

18 Capability Level 3 3: Well Defined: Features and Practices Base practices are performed according to a well-defined process. Approved, tailored versions of standard, documented processes. Planning and managing uses an organization-wide standard process. 3.1 Defining a Standard Process Standardize the process Tailor the standard process 3.2 Perform the Defined Process Use a well-defined process Perform defect reviews Use well-defined data 7.35 Capability Level 4 4: Quantitatively Controlled: Features and Practices Detailed measures of performance are collected and analyzed Process is understand quantitatively. Performance may be predicted quantitatively. Performance is objectively managed. Quality of work products is quantitatively known. 4.1 Establishing Measurable Quality Goals Establish quality goals 4.2 Objectively Managing Performance Determine process capability Use process capability

19 Capability Level 5 5: Continuously Improving: Features and Practices The organization establishes quantitative performance goals (targets) for process effectiveness and efficiency, based on business goals. The organization continuously refines and improves the process by gathering quantitative data from performing the defined process and from piloting innovative ideas and technologies. The quantitative impact of process changes is understood. 5.1 Improving Organizational Capability Establish process effectiveness goals Continuously improve the standard process 5.2 Improving Process Effectiveness Perform causal analysis Eliminate defect causes Continuously improve the defined process 7.37 Why Separating Capabilities & Domain? Why is process capability separated from the domain (process areas)? Product development activities encompass many disciplines and domains. Process improvement across those disciplines provides leveraging opportunities. Opportunity for guidance that transcends organizational and role-based boundaries. Common features, detailed by generic practices, are independent of business area and application domain and are therefore widely applicable

20 Improving Systems Engineering Maturity Example 0 Project Engineering Organization Bringing the engineering processes to capability level 3 - Well defined - can most effectively be done after the project process areas have been brought to level 2 and after the organizational process areas have been brought to level Capability of Systems Engineering Processes Process Capability Level Domain 1: Performed Informally 2: Planned and Tracked 3: Well Defined 4: Quantitatively Controlled 5: Continuously Improving Process Area 1 Process Area 2... Process Area n Are Are base base practices included in in performance of of the the process? How How well well are are the the bases bases practices/ process areas areas managed and and their their processes institutionalized?

21 Principles: Process Improvement You have to do it before you can manage it. Understand what s happening on the project (where the products are!) before defining organization-wide processes. Use the best of what you ve learned from your projects to create organization-wide processes. You can t measure it until you know what it is. Managing with measurement is only meaningful when you re measuring the right things. A culture of continuous improvement requires a foundation of sound management practice, defined processes, and measurable goals. Goals: Predictability of project cost and schedule. Control of performance and application of corrective actions. Effectiveness, i.e., decreasing cost, shorter development time, increasing quality and productivity Process Design: Organizational Context Analyze & improve processes Baseline: describe current processes. Starting point: What are systems engineers responsible for? Which changes are improvements? Understand business, product, and organizational context of process What life-cycle will be used as a framework for this process? How is the organization structured to support projects? How are support functions handled (e.g., by the project or the organization)? What are management and practitioner roles used in the organization? How critical are these processes to organizational success?

22 Process Design: Roles and Structure Organizational Context Guidance Role Assignment Organization Structure Specific Work Products Base Practice Generic Practice Sound Sound systems engineering processes with with a potential for for deliberate improvement Selected Life Cycle 7.43 Summary: Project Management Activity: Software Systems Engineering and Project Management Goal: Sound Systems Engineering Processes with a potential for deliberate improvements Means: Process Orientation in Engineering and Management

23 Summary Software Systems Engineering Project Management Activity: Application Analysis and Software Systems Design Software Systems Engineering and Project Management Goal: Sound Software Systems... Sound Systems Engineering Processes with a potential for deliberate improvements Means: Object Orientation in Analysis and Design Process Orientation in Engineering and Management