1. Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project Management Discipline

2. Purpose It does not cover :  Managing people: hiring, training, coaching  Managing budgets: defining, allocating  Managing contracts with suppliers and customers 2

3. Purpose This discipline focuses on:  Planning an iterative project through the lifecycle and planning a particular iteration  Risk management  Monitoring the progress of an iterative project and measurements 3

4. Purpose plans to be realistic must have a very good understanding of what will be built Therefore:  Must have stable requirements and  A stable architecture, and  Must have built a similar system from which  you can derive a detailed work breakdown structure (WBS). 4

5. Planning and Iterative Project In an iterative process, the development is based on two kinds of plans:  A coarse-grained plan  the phase plan  A series of fine-grained plans  the iteration plans 5

6. Purpose 6

7. The Concept of Risk  Direct risk  a risk over which the project has a large degree of control  Indirect risk  a risk over which the project has little or no control 7

8. The Concept of Risk Risk important attributes:  The probability of occurrence (its likelihood )  The impact on the project (its severity ) 8

9. The Concept of Risk Strategies : How to Cope with Risks The key idea in risk management: You dont wait passively until a risk becomes a problem 9

10. The Concept of Risk Main routes:  Risk avoidance  Reorganize the project so that …  it cannot be affected by the risk.  Risk transfer  Reorganize the project so that someone or something else bears the risk.  For example: the customer, vendor, bank, or another element  Risk acceptance  Decide to live with the risk as a contingency.  Monitor the risk symptoms and  determine what to do if the risk materializes. 10

11. The Concept of Risk When accepting a risk, you should do two things:  Mitigate the risk  steps to reduce the probability or the impact of the risk.  Define a contingency plan  Determine the action to take if the risk becomes an actual problem 11

12. The Concept of Measurement  Measuring key aspects of a project adds a non-negligible cost  We must set precise goals for a measurement effort and  Collect only measurements that allow us to satisfy these goals. 12

13. The Concept of Measurement Two kinds of goals:  Knowledge goals  Assess product quality,  Monitor test coverage or  Monitor requirements changes.  Change goals  They express an interest in seeing how things change or improve over time,  from one iteration to another, and  from one project to another. 13

14. The Concept of Measurement Goals examples:  Monitor progress relative to the plan.  Improve customer satisfaction.  Improve productivity.  Increase reuse. 14

15. The Concept of Measurement Goals  Action goals For example: "Improve customer satisfaction"  Define customer satisfaction.  Measure customer satisfaction over several releases.  Verify that satisfaction improves. 15

16. The Concept of Measurement Goal  Sub-goals Example: "Improve productivity"  Measure effort.  Measure progress.  Calculate productivity over several iterations or projects.  Compare the results. 16

17. Roles and Artifacts 17

18. 18

19. Workflow Staff/Schedule Trade-off Cannot trade staff for schedule. COCOMO (Constructive Cost Model) 19

20. Workflow 20

21. Workflow Some heuristics: 1) Stretch the inception phase  If need a long time to  scope the project,  find the funding,  conduct market research, or  build an initial proof-of-concept prototype, 21

22. Workflow 2) Stretch the elaboration phase  If  No architecture in place,  Using new and unknown technology,  Have severe performance constraints,  Have a number of technical risks, and  Have a lot of new staff,. 22

23. Workflow  If this is the second generation of a product or  if you will make no major changes to the architecture, shrink the inception and elaboration phases. 23

24. Workflow  If you must hit the market quickly  because you are late or  because you are creating the market  If you must plan to finish the product gradually,  you can shorten the construction phase and  lengthen the transition phase 24

25. Workflow- Duration of an Iteration  An iteration starts with planning and requirements and ends with a release, either internal or external.  Ideally, an iteration should span from two to six weeks, but this varies from project to project. 25

26. Workflow- Duration of an Iteration How quickly you can iterate depends on:  Size of the development organization.  Degree of the organization's familiarity with the iterative approach;  Level of automation used by the team to manage code  Testing and automation of it. an iteration has some fixed overhead for planning, synchronizing, and analyzing the results. 26

27. Workflow- Number of Iteration In inception phase:  there will be no real iteration;  no software is produced, and  there are only planning and marketing activities. In some cases, an iteration for:  Building a prototype 27

28. Workflow- Number of Iteration In elaboration phase:  Should plan at least one iteration.  If have no architecture must accommodate a lot of new factors  New people,  New tools,  New Technology,  New Platform, or  New programming language  Then should plan two or three iterations.  Cannot tackle all the risks at once.  May need to show a prototype to the customer or end users  Need an iteration to correct early mistakes on the architecture. 28

29. Workflow- Number of Iteration In construction phase  Should plan at least one iteration.  Two is more reasonable for a better integration and testing.  For more ambitious projects, three or more iterations are even better 29

30. Workflow- Number of Iteration In transition phase  At least one iteration,  Too often,  The realities of the market or  The (poor) quality of the initial release will force you to do more iterations. 30

31. Workflow- Number of Iteration Over the entire development cycle [I, E, C, T]:  Low: three iterations [0, 1, 1, 1]  Typical: six iterations [1, 2, 2, 1]  High: nine iterations [1, 3, 3, 2] 31

32. Building an Iteration Plan Follow these four steps: 1) Define objective criteria for the success of the iteration.  These criteria will used in an iteration assessment review 2) Identify the artifacts that will need to be developed or updated and the activities that will be required to achieve this. 3) Beginning with a typical iteration work breakdown structure (WBS), and aarange it to take into account the actual activities that must take place. 4) Use estimates to assign duration and effort to each activity, keeping all numbers within your budget. 32

33. Building an Iteration Plan Objective drivers of an iteration in elaboration phase: 1) Risk 2) Criticality 3) Coverage 33

34. Building an Iteration Plan- Objective Drivers 1) Risk  For damaging risks, identify a scenario in one use case that would force the development team to "confront" the risk.  Examples:  If there is an integration risk, such as "database D working properly with OS Y," be sure to include one scenario that involves some database interaction even.  If there is a performance risk, such as "excessive time to compute the trajectory of the aircraft," be sure to include one scenario that includes this computation, at least for the most obvious and frequent case. 34

35. 2) Criticality  Select scenarios from the use cases that represent the most common or the most frequent form of the service or feature offered by the system. 3) Coverage  Include scenarios that touch areas you know will require development even if these scenarios are neither critical nor risky 35 Building an Iteration Plan- Objective Drivers