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

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,

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

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,

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,

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,

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,

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

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,

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,

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,

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

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

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

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

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

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

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,

Some useful ideas, cont. Use reviews and inspections. Use 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,

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,

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

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,

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

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

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,

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,

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

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

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

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

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

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,

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

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,

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

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

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,

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,

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

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,

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

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

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,

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,

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,

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,

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,

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,

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,

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,

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,

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

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