1 / 67

Requirements Engineering

Requirements Engineering. Lesson 3 PROJECT MANAGEMENT. Project and Project Management. A project is a [temporary] sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by specific time, within budget, and according to specification.

tricia
Télécharger la présentation

Requirements Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements Engineering Lesson 3 PROJECT MANAGEMENT

  2. Project and Project Management A project is a [temporary] sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by specific time, within budget, and according to specification. Project management is the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.

  3. Project versus Process Management Project management is the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame. Process management is an ongoing activity that documents, manages the use of, and improves an organization’s chosen methodology (the “process”) for system development. Process management is concerned with the activities, deliverables, and quality standards to be applied to all projects.

  4. Causes of Project Failure • Failure to establish upper-management commitment to the project • Lack of organization’s commitment to the system development methodology • Taking shortcuts through or around the system development methodology • Poor expectations management • Premature commitment to a fixed budget and schedule • Poor estimating techniques • Overoptimism • The mythical man-month (Brooks, 1975) • Inadequate people management skills • Failure to adapt to business change • Insufficient resources • Failure to “manage to the plan”

  5. Business awareness Business partner orientation Commitment to quality Initiative Information gathering Analytical thinking Conceptual thinking Interpersonal awareness Organizational awareness Anticipation of impact Resourceful use of influence Motivating others Communication skills Developing others Monitoring and controlling Self-confidence Stress management Concern for credibility Flexibility Project Manager Competencies (Adapted from Wysocki, Beck, and Crane, Effective Project Management: How to Plan, Manage, and Deliver Projects on Time and within Budget.)

  6. Project Management Functions • Scoping • Planning • Estimating • Scheduling • Organizing • Directing       • Controlling • Closing

  7. Measures of Project Success • The resulting information system is acceptable to the customer. • The system was delivered “on time.” • The system was delivered “within budget.” • The system development process had a minimal impact on ongoing business operations.

  8. The Variables of Project Management • Can somewhat vary the following factors. 1. The total cost of the project, • e.g., increase expenditures 2. The capabilities of the product, • e.g., subtract from a list of features 3. The quality of the product, • e.g., increase the mean time between failure 4. The date on which the job is completed. • e.g., reduce the schedule by 20% • e.g., postpone project's completion date one month

  9. Bullseye Figure for Project Variables cost Target: 100% Target : $70K capability duration Target : 30 wks Target : 4 defects/Kloc defect density Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  10. Bullseye Figure for Project Variables cost Target: 100% Target : $70K Actual: $90K Actual: 100% this project capability duration Target : 30 wks Target : 4 defects/Kloc Actual: 20 wks Actual: 1 defect/Kloc defect density Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  11. 1. Understand project content, scope, & time frame 2. Identify development process (methods, tools, languages, documentation and support) 3. Determine organizational structure (organizational elements involved) 4. Identify managerial process (responsibilities of the participants) 5. Develop schedule (times at which the work portions are to be performed) 6. Develop staffing plan 7. Begin risk management 8. Identify documents to be produced 9. Begin process itself A Road Map for Project Management Planning

  12. Hierarchical Project Management Organizations Smaller Projects: Larger Projects: No separate Marketing? No separate QA organization? • Subdivide QA into testing, …? • Subdivide Engineering into • system engineering, …? Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  13. Horizontal Project Management Organizations Ian Corliss Team member Gil Warner Team leader Nel Tremont Team member Team facilitator? Fran Smith Team member Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  14. Peer Organizations for Larger Projects Team of leaders Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  15. Organize a Team 1. Select team leader: responsibilities: • ensure all project aspects active • fill all gaps 3. Designate leader roles & document responsibilities team leader: proposes and maintains… SPMP configuration management leader: ... SCMP quality assurance leader: ... SQAP, STP requirements management leader: ... SRS design leader: ... SDD implementation leader: ... code base 2. Leaders’ responsibilities: • propose a straw man artifact (e.g. SRS, design) • seek team enhancement & acceptance • ensure designated artifact maintained & observed • maintain corresponding metrics if applicable 4. Designate a backup for each leader One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  16. The Four Risk Activities (1) Identification Mindset: try to continually identify risks (2) Retirement (Mitigation) planning (3) Prioritization (4) Retirement or mitigation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  17. The Risk Management Mindset Identification Retirement 2. “Java skills not high enough.” 2. Retirement by avoidance:Use C++ Project finish Project finish Risk 2 Risk 2 Risk 1 Risk 1 1. Retirement by conquest:Demonstrate image super- imposition 1. “May not be possible to superimpose images adequately.” Project start Project start Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

  18. One way to ... Identify and Mitigate Risks 1.* Each team member spends 10 mins. exploring his or her greatest fears for the project’s success 2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader 3.* Team leader integrates and prioritizes results 4.M Group spends 10 mins. seeking additional risks 5.M Team spends 10 mins. finalizing the risk table • Designates responsible risk retirement engineers 6.** Responsible engineers do risk retirement work 7.M Team reviews risks for 10 mins. at weekly meetings • responsible engineers report progress • team discusses newly perceived risks and adds them *:in advance of first meeting M: at meeting **: between meetings

  19. To support project management schedule work breakdown To support configuration management For managing requirements For drawing designs functional object-oriented use-case-based Tracing tools requirements to designs designs to code To support testing To support maintenance Choosing development tools and support – [CASE Tools ]-

  20. Creating schedules: high level planning • Methods • Backward Planning • Forward Planning

  21. High Level Task Chart with Fixed Delivery Date: Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 SCMP complete SRS Complete SQAP complete Milestones Delivery SPMP rel. 1 complete Freeze requirements Iteration 1 Iteration 2 Risk identification & retirement Prep. for maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  22. Create an Initial Schedule 1. Indicate the milestones your must observe • usually includes delivery date 2. Back these up to introduce the milestones you need • e.g., begin system testing well before delivery 3. Designate a time at which all requirements frozen The remaining steps depend on the process used. We will assume an iterative process. 4. Show first iteration: establishes minimal capability • usually: keep it very modest, even trivial, in capability • benefit: exercises the development process itself 5. Show task of identifying & retiring risks • starting from project inception 6. Show unassigned time (e.g., week) near middle? 7. Complete the schedule Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  23. Level Labor Allocation for Fixed Labor Total Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Milestones Freeze requirements Complete testing Karen vacation Release to production 2 2 2 3 2 2 3 Iteration 1 Hal vacation 4 4 4 3 3 4 4 4 4 4 4 4 Iteration 2 2 2 2 1 1 1 4 To be assigned Risk ID & retire Given team size: 4 4 4 4 4 3 3 4 4 4 4 3 3 4 4 4 4 4 4 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  24. Project Management Tools & Techniques A PERT chart is a graphical network model that depicts a project’s tasks and the relationships between those tasks. A Gantt chart is a simple horizontal bar chart that depicts project tasks against a calendar. Each bar represents a named project task. The tasks are listed vertically in the left-hand column. The horizontal axis is a calendar timeline.

  25. PERT Chart Project Initiation Legend 5-3-2001 N/A Task Task 5-3-2001 N/A Scheduled Scheduled Scheduled Scheduled intertask Start Finish Start Finish dependency Actual Actual Actual Start Actual Start Finish Finish Preliminary Investigation 5-3-2001 5-12-2001 5-3-2001 5-11-2001 Problem Analysis Requirements Analysis Decision Analysis 5-28-2001 7-15-2001 6-13-2001 7-30-2001 5-12-2001 6-12-2001 5-30-2001 7-18-2001 6-13-2001 8-3-2001 5-12-2001 6-14-2001 Design Construction 7-3-2001 9-25-2001 7-19-2001 11-13-2001 7-5-2001 10-9-2001 7-20-2001 In Progress Implementation 9-10-2001 12-14-2001 TBD TBD

  26. 2001 ID Task Name May Jun Jul Aug Sep Oct Nov Dec 1 Preliminary investigation 2 Problem analysis 3 Requirements analysis 4 Decision analysis 5 Design 6 Construction 7 Implementation Today Complete Task Legend Incomplete Task Gantt Chart

  27. Microsoft Project Gantt Chart

  28. Microsoft Project PERT Chart

  29. Project Management Life Cycle

  30. Joint Project Planning Strategy Joint project planning (JPP) is a strategy wherein all stakeholders in a project (meaning system owners, users, analysts, designers, and builders) participate in a one-to-three day project management workshop, the result of which is consensus agreement on project scope, schedule, resources, and budget. (Of course, subsequent workshops or meetings may be required to adjust scope, budget, and schedule.)

  31. Negotiate Scope Scope defines the boundaries of a project—What part of the business is to be studied, analyzed, designed, constructed, implemented, and ultimately improved? • Product • Quality • Time • Cost • Resources A statement of work is a narrative description of the work to be performed as part of a project. Common synonyms include scope statement, project definition, project overview, and document of understanding.

  32. Statement of Work I. Purpose II. Background A. Problem, opportunity, or directive statement B. History leading to project request C. Project goal and objectives D. Product description III. Scope (notice the use of your information system building blocks) A. Stakeholders B. Data C. Processes D. Locations IV. Project Approach A. Route B. Deliverables V. Managerial Approach A. Team building considerations B. Manager and experience C. Training requirements D. Meeting schedules E. Reporting methods and frequency F. Conflict management G. Scope management (continued)

  33. Statement of Work (concluded) VI. Constraints A. Start date B. Deadlines C. Budget D. Technology VII. Ballpark Estimates A. Schedule B. Budget VIII. Conditions of Satisfaction A. Success criteria B. Assumptions C. Risks IX. Appendices

  34. Identify Tasks A work breakdown structure (WBS) is a hierarchical decomposition of the project into phases, activities, and tasks. Milestones are events that signify the accomplishment or completion of major deliverables during a project.

  35. 0 PROJECT GOAL 1 3 2 PHASE PHASE PHASE 2.1 2.2 2.3 ACTIVITY ACTIVITY ACTIVITY 2.2.1 2.2.2 2.2.3 TASK TASK TASK Work Breakdown Structures 1 Phase 1 of the project … 2 Phase 2 of the project … 2.1 Activity 1 of Phase 2 … 2.2 Activity 2 of Phase 2 2.2.1 Task 1 of Activity 2.2 in Phase 2 2.2.2 Task 2 of Activity 2.2 in Phase 2 2.2.3 Task 3 of Activity 2.2 in Phase 2 2.3 Activity 3 of Phase 2 … 3 Phase 3 of the project … =

  36. 1.  Estimate the minimum amount of time it would take to perform the task. We'll call this the optimistic duration (OD). 2.  Estimate the maximum amount of time it would take to perform the task. We'll call this the pessimistic duration (PD). 3.  Estimate the expected duration (ED) that will be needed to perform the task. 4.  Calculate the most likely duration (D) as follows: D = (1 x OD) + (4 x ED) + (1 x PD) 6 Estimate Task Durations

  37. Specify Intertask Dependencies • Finish-to-start (FS)—The finish of one task triggers the start of another task. • Start-to-start (SS)—The start of one task triggers the start of another task. • Finish-to-finish (FF)—Two tasks must finish at the same time. • Start-to-finish (SF)—The start of one task signifies the finish of another task.

  38. Entering Intertask Dependencies

  39. Scheduling Strategies Forward scheduling establishes a project start date and then schedules forward from that date. Based on the planned duration of required tasks, their interdependencies, and the allocation of resources to complete those tasks, a projected project completion date is calculated. Reverse scheduling establishes a project deadline and then schedules backward from that date. Essentially, tasks, their duration, interdependencies, and resources must be considered to ensure that the project can be completed by the deadline.

  40. A Project Calendar

  41. Assign Resources • People—inclusive of all the system owners, users, analysts, designers, builders, external agents, and clerical help that will be involved in the project in any way, shape, or form. • Services—a service such as a quality review that may be charged on a per use basis. • Facilities and equipment—including all rooms and technology that will be needed to complete the project. • Supplies and materials—everything from pencils, paper, notebooks, toner cartridges, etc. • Money—A translation of all of the above into the language of accounting—budgeted dollars!

  42. Defining Project Resources

  43. Assigning Project Resources

  44. Resource Leveling Resource leveling is a strategy used to correct resource overallocations by some combination of delaying or splitting tasks. There are two techniques for resource leveling: • task delaying • task splitting

  45. Task Splitting and Delaying • The critical path for a project is that sequence of dependent tasks that have the largest sum of most likely durations. The critical path determines the earliest possible completion date of the project. • Tasks that are on the critical path cannot be delayed without delaying the entire project schedule. To achieve resource leveling, critical tasks can only be split. • The slack time available for any noncritical task is the amount of delay that can be tolerated between the starting time and completion time of a task without causing a delay in the completion date of the entire project. • Tasks that have slack time can be delayed to achieve resource leveling

  46. ORIENTATION STAGE Ÿ Establish structure and rules FORMING Ÿ Clarify team member relationships Ÿ Identify responsibilities Ÿ Develop a plan to achieve goals INTERNAL PROBLEM-SOLVING STAGE Ÿ Resolve interpersonal conflict STORMING Ÿ Further clarify rules and goals Ÿ Develop a participative climate GROWTH AND PRODUCTIVITY STAGE Ÿ Direct team activity toward goals NORMING Ÿ Provide and get feedback Ÿ Share ideas–growing cohesion Ÿ Individuals feel good about each other EVALUATION AND CONTROL STAGE Ÿ More feedback and evaluation PERFORMING Ÿ Adherence to team norms Ÿ Roles of team strengthened Ÿ Strong team motivation to share goals Direct the Team Effort • Supervision resources • The DEADLINE – A Novel About Project Management • The One Minute Manager • The Care and Feeding of Monkeys • Stages of Team Maturity (see figure to the right)

  47. Monitor and Control Progress • Progress reporting • Change management • Expectations management • Schedule adjustments—critical path analysis (CPA)

  48. Progress on a Gantt Chart

  49. Critical Path Analysis (and Slack Time) • Using intertask dependencies, determine every possible path through the project. • For each path, sum the durations of all tasks in the path. • The path with the longest total duration is the critical path. • The critical path for a project is that sequence of dependent tasks that have the largest sum of most likely durations. The critical path determines the earliest completion date of the project. • The slack time available for any noncritical task is the amount of delay that can be tolerated between the starting time and completion time of a task without causing a delay in the completion date of the entire project.

  50. TASK D Duration Tue 2/20/01 7 days Tue 2/20/01 0 days TASK A TASK B TASK C TASK E TASK I Mon 2/5/01 3 days Wed 2/7/01 2 days Fri 2/9/01 2 days Mon 2/19/01 6 days Tue 2/27/01 5 days Mon 2/5/01 0 days Wed 2/7/01 0 days Fri 2/9/01 0 days Tue 2/20/01 1 day Tue 2/27/01 0 days TASK F TASK G Wed 2/14/01 3 days Fri 2/16/01 2 days The critical path is highlighted in red Fri 2/16/01 2 days Tue 2/20/01 2 days Slack Time TASK H Thu 2/15/01 1 day Tue 2/20/01 3 days Critical Path

More Related