1. Chapter 2: Project Management Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 1

2. Project Management Soft skills – motivating people Hard skills – making plans – obtaining and managing resources – setting deadlines – quality control Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 2

3. Every Project Has Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 3 StakeholdersResources SchedulesOrganization CoordinationCommunication DeliverablesDocumentation RiskLife cycle Each of these must be managed

4. Sub-teams Systems Analysis TeamPlanning Team Requirements TeamSystem Design Team Implementation TeamTesting and Integration Team Training TeamDelivery & Installation Team Maintenance TeamQuality Assurance Team Metrics TeamDocumentation Team System Administration Team Reuse & Reengineering Team Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 4

5. Some Specific Activities Managing people Allocating resources Defining roles Motivating project personnel Dealing with inevitable slippage in the schedule Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 5

6. Some Specific Activities, cont. Handling changes in requirements Handling changes in designs Handling changes in code Handling changes in anything, while maintaining consistency – Operating systems, databases, APIs, IDEs, COTS products, components, … Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 6

7. Some Specific Activities, cont. Measuring system progress and quality Reacting to unexpected events Informing upper level management Ensuring proper reviews of major milestones Interacting with prospective customer or customer representatives Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 7

8. Project Cost Estimation Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 8

9. Estimating Project Costs Bigger projects are more expensive Complex projects are more expensive “Experience databases” can be helpful in estimating costs Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 9

10. Work Breakdown Structure Examine the list of detailed requirements. For each requirement, estimate the effort needed to implement the requirement. Ignore any requirements for which an existing component can be reused as is. Compute the total of all new lines of code. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 10

11. COCOMO Model (Boehm) Effort E = a b * K * exp(b b ) Development Time D = c b * E * exp(d b ) Constants depend on software project type Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 11

12. COCOMO Model (Boehm), cont. Project typeababb cbcb dbdb “Small”2.41.052.50.38 “Embedded”3.61.22.50.32 “Intermediate”3.01.122.50.35 Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 12 COCOMO has been extended to COCOMO 2 (Constants are determined empirically)

13. Project Scheduling Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 13

14. Project Scheduling Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 14 Team sizes vary over time

15. Typical milestone chart for waterfall development Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 15

16. Ideas and Tools Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 16

17. Ideas and Tools Coordination Groupware Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 17

18. Some useful ideas Standard format for graphical files. Make sure that the format is compatible with the browser to be used. Mechanism for feedback about deficiencies in on-line documents. Make on-line documents subject to configuration management and revision control. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 18

19. Some useful ideas, cont. Use reviews and inspections. Use e-mail to coordinate meetings and to notify members of the project team that documents have been changed. Use “chat rooms” for project management. Use wikis for concurrent access to documents by multiple users if appropriate. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 19

20. Groupware Use this if it is available to all and has been installed and tested. Either free or commercial groupware can be used. Google Docs? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 20

21. Project Life Cycles Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 21

22. Project Life Cycles Classical Waterfall Model Rapid Prototyping Model Spiral Model Market-Driven Model Open Source Model Agile Development Model Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 22

23. The classical waterfall model Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 23

24. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 24

25. The rapid prototyping model Assumes that, unlike the waterfall model, requirements are not completely known in advance. Requirements are developed in an iterative manner, along with prototypes that are created iteratively. An initial set of requirements is created in order to create the first prototype. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 25

26. The rapid prototyping model, cont. Initial specific ations Develop prototype Test and integrate prototype Evaluate prototype Create new specifications System Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 26

27. The spiral model Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 27

28. The spiral model, one quadrant Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 28

29. The spiral model, one quadrant Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 29

30. The spiral model, one quadrant Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 30

31. The spiral model, one quadrant Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 31

32. Open-Source Projects All source code is freely available Repositories must be managed A select group of experts often is used to determine quality Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 32

33. Case Study: Project Management for Agile Processes Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 33

34. Agile Processes – the Team It all starts with the team – Small – seven members – Highly experienced in the application domain (spacecraft and satellite control systems) – Worked well together – Charismatic leader – Excellent relationship with upper-level management Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 34

35. Agile Processes – the Management Highly supportive Trusted the team Had the same goals – More – Better – Cheaper – Faster Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 35

36. Agile Processes – the Customers Really wanted – More – Better – Cheaper – Faster Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 36

37. Agile Processes - The context The seven-member team was part of a larger effort in which multiple teams and internal organizations competed to get their ideas implemented. Multi-year effort Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 37

38. Goal: Improve the Team’s Self- Organizing Factor SOF = (management + external test) / ( management + systems engineering + requirements gathering + implementation + internal test + external test + maintenance + system administration + documentation) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 38

39. Why improve the SOF? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 39

40. Why improve the SOF? Because projects with a low SOF made greater improvements in costs and greater reduction of testing costs Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 40

41. Configuration Management Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 41

42. Configuration Management Necessary to coordinate team activities Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 42

43. Configuration Management Every non-trivial software system or component is developed under software configuration management (SCM). Most software development environments, especially CASE tools, provide support for SCM. SCM can provide insight into component or system quality. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 43

44. The SCM Process Includes identification of the elements of every software configuration, both before and after release? Helps manage all versions of a system (both active and pre-release) How does an organization control changes before and after software is released to a customer? How are changes approved? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 44

45. The SCM Process, cont. How can we ensure that changes have been made properly? How are users and developers notified of changes? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 45

46. SCM, cont. The first widely accepted SCM system was developed by Marc Rochkind. It was called SCCS, for Source Code Control System, and worked on UNIX environments. Source code components to be developed were placed in a special directory named SCCS. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 46

47. SCM, cont. Developers could work on components separately. – Developers had to check components out, blocking others from working on it. – Files were stored as an original file, with a set of incremental changes. – The SCCS software showed the developers the latest version by default. – Developers could work on any earlier version, if they found errors later. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 47

48. SCM, cont. The number of changes provided insight into the volatility of the software. Too many changes often meant overly complex software. The UNIX prs utility allowed the changes made to a system developed under SCCS to be analyzed for certain patterns that indicated potential testing problems. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 48

49. SCM, cont. The system worked well for projects of moderate size that were to be hosted on a single computer. – SCCS directories usually were hosted on a single computer! The process became unwieldy in larger, more distributed development environments. Marc Rochkind himself moved to RCS (Revision Control System) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 49

50. SCM, cont. SCCS and several of the early SCM systems were fine stand-alone systems, but did not integrate well with modern development practices. Data was hard to link directly to databases. Hard to link to the cause of software problems that cut across several products, as is common in software product-line architectures. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 50

51. SCM, cont. One of the newer SCM systems is Razor, produced by Visible Systems. This tool can be used either stand-alone, or as an integrated part of a larger system. For example, Razor can be integrated with any set of files that are under a source code control system that is Microsoft-compliant. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 51

52. The Razor SCM Tool Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 52

53. The Razor SCM Tool, cont. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 53