Project Planning and Management Team Polk. Ricardo Carrion-Carrero, Matthew Luker, Arnold Lestin

Transcription

1 Project Planning and Management Team Polk Ricardo Carrion-Carrero, Matthew Luker, Arnold Lestin 1 1

2 Progress Tracking: Customer s Concerns Typical customer questions: Do you understand my problem and my needs? Can you design a system that will solve my problem or satisfy my needs? How long will it take you to develop such a system? How much will it cost to have you develop such a system? We need a little more help to answer the last two questions... 2

3 Progress Tracking: Project Schedule A project schedule describes the software development cycle for a particular project. The schedule will describe the interactions between tasks as well as the time which task will take. The phases of the project will be broken down into discrete tasks/activities to be done. The project schedule acts as a sort of timeline to shows when different stages will be complete or when products will be ready Break the problem down into smaller parts! 3

4 Progress Tracking: Project phases, steps and activities We can break down any project into phases, each of which are composed of steps, and further described by activities. Phases: Major phases of development could include the following: Activities: Parts of the project that takes place over a period of time The completion of an activity is called a milestone Engineering Implementation Testing Etc. Steps: Each major phase can be broken down into steps. These steps each require coordination between team members, customers, etc. 4

5 Progress Tracking: Progress tracking with activity graph At any point during the development process, a customer may want to follow the progress of the project. By using activity graphs we can easily relay this information. Parallel tasks Activity graphs can help relay to customers: Activities: What work is underway Milestones: What work has been completed Activity graphs can help communicate to team members: Precursor: event must occur before activity begins Due dates Endpoints: Milestones or deliverables 5

6 Estimating completion: Critical Path Method (CPM) Critical Path Method: minimum amount of time it will take to complete the entire project. Uses estimates for each activities duration Shows which activities may bottleneck projets and are most critical Important aspects of CPM: Real Time vs Available Time Real Time: time required for an activity to be completed Available Time: amount of time available in schedule Slack Time = available time - real time 6

7 Estimating completion: Activity graph with duration Possible paths to be taken: After analyzing the possible paths, if we find that the critical path has no slack, that means there is no margin for error when performing the tasks along that route. *NOTE: There may be more than one critical path 7

8 Estimating completion: Critical Path Method (CPM) chart Horizontal bars represent duration of an activity Asterisks indicate critical path Dashes are noncritical paths F represents slack(float) time 8

9 Tools to track progress: Gantt chart Gantt charts are quite similar to CPM charts Degree of completion is shown for each activity Often used by project managers to see which activities can be performed at the same time The dashed bar shows an example of what today might look like 9

10 Tools to track progress: Resource histogram Histograms are a good way to portray data relating two types of values This chart shows the relationship between the number of people needed for a task at a given time Charts like this allow management to make quick and informed decisions about how to ensure their resources are being properly allocated We can modify the graphs input data to try to optimize this particular process 10

11 Tools to track progress: Expenditure graph Tracking development costs and budget expenses are extremely important in product development We can use combinations of budget tracking and personal tracking to determine the best resources for a limited budget Quickly and easily understanding the finances can allow for corrections to be made or to motivate teams to stay on track toward goals 11

12 Project personnel What do you need to take into consideration to pick project personnel? Project size Every project requires someone to acquire requirements from customers Every project requires someone to write programs that meet the customer s requirements Depending on the size of the project you can: Separate personnel to have checks and balances in your process: Have one team write the program and another team test it Have one person design the system and another design the program Have the separate sub-teams meet often to assess each other in order to catch mistakes earlier and make the development process more efficient Personnel experience Experience can be in terms of leadership experience, testing experience, programming language/framework experience, or industry experience Someone who understands a problem space well can create a more useful product than someone who can code in the same language better Experience can be leveraged to help the entire team be more productive Personnel expertise It is important that each member is interested and focused on their work, so the best person for a particular role may be the person who has a lot of passion for it 12 12

13 Project personnel Communication problems that can arise: If a project has n workers, then there are n(n-1)/2 pairs of people who might need to communicate and 2 n - 1 possible teams that can be created to work together Increasing the size of a team from two to three people triples the number of possible lines of communication One pair becomes three pairs that might collaborate Three possible ways of working alone or together becomes seven The more people there are, the more people who will need to communicate to make sure requirements are met and understood by each subgroup of the project 13 13

14 Project personnel Communication problems that can arise: 14 14

15 Project personnel Work styles: Project personnel are as different as each project and can differ in as simple ways as: Project wiki vs. human knowledge Phone calls vs. face to face Vim/Emacs vs. IDE Detailed planning vs. experimenting Weekly meetings vs. daily Work styles can be broken down by: Way thoughts are communicated and ideas gathered Degree to which emotions affect decision making Types of people for communications: Extroverts: tells others their thoughts Introverts: asks others for suggestions before forming an opinion 15 15

16 Project personnel Work styles: Types of people for emotionality: Intuitive: bases decisions on feelings about and emotional reactions to a problem Rational: decides primarily by examining facts and carefully considering all options 16 16

17 Project organization Content outline: Chief programmer team Chief programmer team: First used at IBM One person is totally responsible for the system design and system development Allows the team to divide labor and focus on programming by minimizing communication and eliminating peer reviews Roles: Chief programmer has the final say on every decision supervises other programmers assigns tasks to other team members An understudy assists the chief substitutes as chief programmer when necessary A librarian assists the team documents the project compiles and links the code does preliminary testing of all modules submitted to the library Harlan Mills of IBM (1971) 17 17

18 Project organization Content outline: Chief programmer team Chief programmer team: If the team consists of n - 1 programmers plus the chief, there are only n - 1 paths of communication out of n(n - 1)/2 paths Harlan Mills of IBM (1971) 18 18

19 Project organization Content outline: Chief programmer team Egoless approach: Democratic system that holds everyone equally responsible Criticism is made of the product and not the individual Good when: There is high uncertainty in requirements New techniques or technologies are being tried Small project and small team Open communication is possible and effective Gerald M. Weinberg Introduced egoless programming in

20 Project organization Combining chief programmer and egoless approaches: Highly structured teams are efficient but may suffer in high uncertainty projects or lack creativity Egoless teams are creative and adaptable but may fail to deliver on time One should try to merge the two approaches to maximize benefit for a particular team size and project. Examples include: Use an egoless approach within a hierarchical structure by assigning entire subsystems to a programmer or team One aspect of the project can adapt one organization method while another adapts the other depending on the size of each team 20 20

21 Project organization Chief programmer vs. egoless approaches: 21 21

22 Effort estimation Why is it necessary? Cost overruns can cause customers to cancel projects, cause developers to work much harder than they estimated they should be paid for, and cause product quality to drop Project budgets include: Facilities Silicon Valley $5000/month for a team of 10 people with 75 square feet per person IBM recommended 100 square feet per programmer Staff Developers Non-developer help and contractors Tools including Computer-Aided Software Engineering tools Slack (communication) $12.50 per employee Office 365 (document creation) $15.40 per employee Asana (project management) $11.50 per employee Github $25.00 per employee Security All of the above can vary or more might be added as your company grows 22 22

23 Effort estimation Why might costs change? Customer often request changes Some requirements were not included initially Original effort estimation was not detailed enough Inefficiencies in communication Project became more complex than expected Team was not as capable as expected The programming language is not up to the task or is too inefficient Teams was not experienced enough with the hardware Estimates get more accurate as you learn more about a project 23 23

24 Effort estimation Expert Judgment: Can be informal based on employee s previous experience or done by a specialized expert Affected by the expert s competence, experience, objectivity, and perception Either top-down or bottom-up analysis Compare the new project to previous ones Consult several experts for three predictions: Pessimistic prediction Optimistic prediction Most likely guess Take the mean of the beta probability distribution determined by the three numbers to get a normalized estimate Delphi Technique: 1. Experts are asked to make individual predictions secretly 2. The average estimate is then presented to the group so the experts can revise their estimates 3. When no expert wants to revise, the process is done 4. Discussion between experts may or may not be allowed to justify their 24 24

25 Effort estimation Wolverton software cost matrix: Description: Row name represents type of software, column designates its difficulty (O) old (N) new, (E) easy (M) moderate (H) hard Matrix elements are cost per line of code from historical data at TRW software development company Usage: Partition desired software into modules Estimate module sizes in terms of lines of code Use the matrix to calculate costs of each module Sum up the costs of all the modules 25 25

26 Effort estimation Wolverton software cost matrix: Example: System with one I/O module (O) (E) lines, one algorithm module (N) (H) lines,, one data management module (O) (M) 100 lines (100 x 17) + (200 x 35) + (100 x 31) = $11,800 in 1974 dollars if you work at TRW then 26 26

27 Effort estimation Algorithmic Methods: Often described using equations Replaces biased/unreliable expert based methods Effort is the dependent variable Factors such as size, application type, etc. are independent variables Size if the most important factor but can be hard to estimate early Some models use multiple sizing techniques to account for inaccuracy 27 27

28 Effort estimation Algorithmic Methods - Walston and Felix model: One of the first models published was by Walston and Felix of IBM: IBM data from 60 projects Systems with sizes ranging from 4000 to 467,000 lines of code 28 different high-level languages 66 computers Representing from 12 to 11,758 person-months of effort Size was measured in lines of code and some comments Size was supplemented with a productivity index of 29 factors that affected their type of development at IBM Federal Systems 28 28

29 Effort estimation Walston and Felix Model: Each factor was weighted by: 1 if it increases productivity 0 if it has no effect on productivity -1 if it decreases productivity The weighted sum of the 29 factors generates an effort estimate 29 29

30 Effort estimation Algorithmic Methods - Bailey and Basili (1981) model: They developed a meta-model that can be calibrated for different organizations: Demonstrated on data from 18 Fortran projects at NASA s Goddard Space Flight Center Produced a very accurate equation: 30 30

31 Effort estimation Algorithmic Methods - Bailey and Basili (1981) model: Each category was scored from 0-5 by the project manager Extension was intended to make the model more accurate by using multilinear least square regression 31 31

32 Effort estimation Constructive Cost Model (COCOMO): Dr. Barry W. Boehm Created in 1981 from TRW data Considers software engineering from both an engineering and an economics viewpoint Used size as the primary determinant of cost then adjusted the initial estimate using over a dozen cost drivers including: Attributes of the staff Project/product type Development environment COCOMO II was later created to account for the three major stages of any software project and the fact that lines of code are hard to estimate in the beginning 32 32

33 Effort estimation Constructive Cost Model II (COCOMO II): Created in the 1990s Accounts for the maturation of the software development industry Stage 1: Projects build prototypes to resolve high risk issues Little is known about the size of the final product so size is estimated from application points involving the numbers of screens and reports Stage 2: Designers explore alternative architectures Estimates functionality captured in the requirements using function points which are a richer description than application points Stage 3: Post-architecture stage when development has begun Sizing can be done in terms of function points or lines of code Many cost factors can be estimated with more comfort COCOMO II includes models of reuse, takes into account maintenance, and changes in requirements over time

34 Effort estimation Constructive Cost Model II (COCOMO II): Basic form: E = effort bs c is the initial size based estimate m(x) is a vector of cost driver information 34 34

35 Effort estimation Constructive Cost Model II (COCOMO II): 35 35

36 Effort estimation Constructive Cost Model II (COCOMO II): 36 36

37 Effort estimation Constructive Cost Model II (COCOMO II): 37 37

38 Effort estimation Constructive Cost Model II (COCOMO II): 38 38

39 Effort estimation Constructive Cost Model II (COCOMO II): 39 39

40 Effort estimation Machine Learning Methods: Design of a neural network: Each activity in a software process is represented by a neuron Each activity has inputs and outputs Each neuron produces an output if the weighted sum of its inputs exceed a threshold value The output of one neuron may be the input of another The neural network s final output is the sum of many neurons Neural networks are trained on large datasets from previous projects 40 40

41 Effort estimation Machine Learning Methods: 41 41

42 Risk management Content outline: Sources of risks Risk is an unwanted event that has negative consequences Project managers are responsible for understanding and managing risks Aspects of a risk: Causes a loss in time, quality, money, control, or understanding (risk impact) Has a probability of occuring (risk probability) Problem if it is guaranteed to have an impact on the project Degree to which it can be controlled Steps can be taken to mitigate or reduce a risk Design can be made flexible Alternatives can be had for contingencies Risk exposure is the risk impacts multiplied by risk probability: A change in requirement may be 30% likely That redesign might cost $50, * = $15,000 in risk exposure Generic risks are common to all software projects whereas specific risks are unique to a particular project 42 42

43 Risk management Content outline: Risk management activities 43 43

44 Risk management Content outline: Steps in risk management Steps you can take to combat risks: 1. Identify risks 2. Analyze the risks to understand when, why, and where they might occur 3. Prioritize the risks to fit your amount of resources (sorted by risk exposure) 4. Choose whether to avoid the risk, transfer the risk, or assume the risk 5. Calculate the risk leverage (the difference in risk exposure divided by the cost of reducing the risk) If the risk leverage is not high enough, take a different option to reduce the risk A risk management plan should be recorded so both the customer and development team can understand how to avoid or handle problems that arise

45 Project Plan Content outline: Items to be included in the project plan 1. Project Scope 2. Project Schedule 3. Project Team Organization 4. Technical Description of the Proposed System 5. Project STandards, Procedures, and Proposed Techniques 6. Quality Assurance Plan 7. Documentation Plan 8. Data Management Plan 9. Resource Management Plan 10. Test Plan 11. Training Plan 12. Security Plan 13. Risk Management Plan 14. Maintenance Plan 45 45

46 Enrollment Management Model One project management system used by the Digital Equipment Corporation was the Enrollment Management system. 1. Establishing an appropriately large shared vision 2. Delegating completely and eliciting specific commitments from participants 3. Inspecting vigorously and providing supportive feedback 4. Acknowledging every advance and learning as the program progressed This model was used to develop the Alpha AXP System and kept its development on schedule. Managers realized that engineers are usually motivated more by recognition than by financial gain 46 46

47 Process Models and Management 47 47

48 Accountability Model 48

49 Activity Roadmap The activity roadmap was a method developed to visually understand what tasks needed to be completed and the time that had been allotted to complete each task. 49

50 Earned-Value Chart Content outline: Chart and explanation Earned progress was a method of establishing progress on different activities. The earned progress would be calculated with weights to determine how much each activity contributed to the end goal. Overall it is a metric used to measure performance, and keep track of progress to hold people accountable

51 Earned Value Chart 51

52 Anchoring Milestones Content outline: Life-cycle objectives Boehm identified three milestones common to all software development processes. 1. Life Cycle Objectives 2. Life Cycle Architecture 3. Initial Operational Capability Boehm also laid out initial life-cycle plan 1. Objectives: Why is the system being developed 2. Milestones and Schedules: What will be done and when? 3. Responsibilities: Who is responsible for a function 4. Approach: how will the job be done, technically, and managerially? 5. Resources: How much of each resource is needed 6. Feasibility: Can this be done, and is there a good business reason for doing it? 52 52

53 Win-Win Spiral Model 1. This win-win model was used by the US Department of Defense STARS program. 1. Technical name is Theory W 1. Useful when there is a mismatch between what the designers and clients need and want

54 Works Cited Software Engineering: Theory and Practice S. L. Pfleeger and J. M. Atlee, Prentice Hall er/view_group.php?id=7295 (Chief Programmer) (Effort estimation) Wikipedia images Thanks! 54