Relationship to Textbook

• This lecture is based on material in the second part of Chapter 2 of the Jalote textbook

The Other Processes

• As mentioned in lecture 4, a software development process can be decomposed into many sub-processes
  • We looked primarily at the development process in Lecture 4
  • Here we look at other processes, ones which span the entire project and are not particular to any task in the development process
• The Other Processes
  • Project Management
  • Inspection
  • Software Configuration Management
  • Requirements Change Management
  • Process Management (aka Software Process Improvement)

Project Management

• Project Management is an integral part of software development
• As discussed in Lecture 4, a software development project involves
  • a lot of people
  • working together on many tasks
  • divided into phases
  • for a long time
• In order to successfully meet cost, quality, and schedule objectives, members of the development organization need to
  • allocate resources to each task properly
  • monitor the progress of each activity
  • take corrective action, if needed
• All of these activities are part of the project management process. This process ensures that
  • Someone has created a plan for the development activities of the project AND
  • that they have the proper mechanisms in place to see that the plan is followed in an optimal fashion
  • Some software systems exist to aid in this task, see for instance, Microsoft Project or OmniPlan.

Phases of Project Management

• There are three broad phases to project management
  • Planning
  • Monitoring and Control
  • Termination Analysis



• Planning
  • Key activity that is performed before a project begins
  • Tasks include
    • Cost and schedule estimation
    • Staffing
    • Monitoring and Risk Management Plans
    • Quality Assurance Plans
  • We will devote a lecture to this task later in the semester when we cover chapter 5 of the Jalote textbook
• Monitoring and Control
  • Lasts for the duration of the project and covers the development process
  • Monitors all key parameters like cost, schedule, risks
  • Takes corrective actions when needed
  • Needs information on the dev process – provided by metrics (we'll look at various types of metrics throughout the semester)
• Termination Analysis
  • Termination analysis, aka postmortem analysis, is performed when a development process ends
  • Its key task is to analyze the development process looking for data about its performance
    • This data is used to improve the process on subsequent projects
    • In an iterative development process, you could apply postmortem analysis, at the end of each iteration

Inspection

• The main goal of an inspection process is to find defects in work products
• Software Inspections
  • Proposed by Fagan back in the 70s
  • Initially focused just on code, now applied to all work products
  • Inspections are now a recognized best practice and data shows that it supports the goals of improving quality and productivity
• Characteristics of an Inspection
  • Peer-Review Process
  • Process is structured with clearly defined roles
  • The focus is on finding problems, not resolving them
  • Review data is recorded and used for monitoring the effectiveness of an inspection process
• Inspections are performed by a team of reviewers including the author.
• One of the participants is the moderator, who is charged with managing the review and insuring that all steps of the inspection process are followed

Stages of an Inspection

• Planning
  • The author prepares the document for inspection
  • The moderator ensures that the document meets the entry criteria for the inspection process, which will vary by document type
  • The review team is created and the review package is assembled.
  • The review package includes
    • The document itself
    • The specifications for that document (output of previous process step)
    • any relevant checklists and/or organizational standards for this document type
• Overview and Preparation
  • Package is distributed to reviewers
  • Moderator arranges an (optional) initial meeting and the author provides an overview of the document and its purpose
  • Each reviewer then performs a self review of the document, logging all potential defects found
  • This stage is over when all reviewers have completed their personal reviews
• Group Review Meeting
  • This meeting creates the final defect list, based on the union of defects found by individual reviewers with any defects found during the group review meeting
  • A team member (called the reader) goes over the work product line by line
  • For each line, all issues related to the line are raised, typically from the reviewer's personal reviews, and discussed
  • The author either accepts the issue as a defect or clarifies why it is not a defect
  • After an agreement is reached, the scribe records the defect in the log.
  • At the end of the meeting, the scribes reads out all discovered defects one more time for final review
• Rework and Follow Up
  • After the meeting, the author attempts to solve the problems associated with each defect.
  • After producing a new version of the work product, the author meets with the moderator to review the set of corrections
  • The status of this meeting is conveyed to the rest of the review team
  • The group may decide to re-review the new work product

Configuration Management

• Process to handle changes to work projects over the lifetime of a software project
• Configuration management (CM) is typically supported by tools, and these tools rely on a technology known as versioning
• The CM process is one of systematically identifying what work products must be placed under source control and then ensuring that changes to those work products are tracked by an organization's CM tools

Versioning

• Versioning involves
  • tracking the changes to a file between editing sessions
  • providing services that make each version persistent and retrievable
  • providing support for complex dependencies between versions such as extensions, splits, and merges
• Note: the emphasis is on a single file
• What about collections of files?

Configuration Management

• Versioning a collection of files is known as configuration management
  • A collection can occur at many levels of granularity
    • the collection of files that make up a module
    • the collection of files that make up a library
    • the collection of files that make up a subsystem
    • etc.
• NOTE: each file is still individually versioned, but now we can track the configuration to which a particular version belongs

Relationship of Versioning to Configuration Management

• In a typical situation, the version number of a file has nothing to do with the release number of its associated software system

• The release number is the version number of a configuration!
• This example is pretending that somehow this single file represents an entire software system; in real world contexts, a system is make up of many (hundreds to thousands) of files

Configuration Management Example

Configuration Management, continued

• Configurations become first-class objects that can be manipulated by explicit commands
  • (Versions of ) Files can be added/removed from configurations
  • Configurations can be checked in and checked out
    • This helps with bug tracking, if a customer reports a bug on release 1.3, the software engineer can check out a clean copy of release 1.3 without affecting the current release
    • Each developer can have their own copy of a configuration; changes to a configuration are handled similarly to changes to individual files
  • Configurations can be automatically built and packaged for deployment

Configuration Management Tools

• Unfortunately, most configuration management tools are commercial systems
  • ClearCase, Continuus (now Telelogic SYNERGY), Razor, TrueChange
• Tools like RCS, CVS, and Subversion (which are freely available) are versioning systems
  • CVS and Subversion have only one feature that provides a configuration management-like capability
    • Its called “tags” and it allows you to tag a particular version of a file with a release number…
    • … but that’s it! It does not have an explicit notion of collections that can be versioned independent of its individual files

CM Process Overview

• Tools provide only part of a solution
• Another important part is having a clearly defined CM process
  • Identify items to be placed under CM
  • Define library structure for CM
  • Define change control procedures
  • Define access control, baselining, and reconciliation procedures
  • Define release procedure
• The final piece of the puzzle is the CM audit
  • This sub-process occasionally verifies that employees are following the CM process
    • are items stored where they should be
    • are version histories available for all specified items
    • are developers tagging check-ins with high quality comments
    • etc.

Requirements Change Management Process

• Background
  • Requirements will change. At any point in a development process
  • Changes have to be allowed, but in a controlled manner
    • Uncontrolled changes can have a huge adverse impact on project in cost and schedule
• Steps
  • Log all changes
  • For each change, perform impact analysis on effected work products
  • Estimate impact on effort and schedule
  • Review impact with stakeholders
  • Rework selected work products
• Impact analysis for a change request involves identifying the changes needed to various artifacts, and the nature of change
• The impact of changes on the project is reviewed to decide whether to go ahead with each change

Process Management Process

• aka Software Process Improvement
• Background
  • A process is not a static entity – it has to change to improve to improve Q&P
  • Focus of process management is to evaluate and improve each process employed by an organization
  • It is different from project management which focuses on the project itself
• Basic Process
  • To improve a process, an organization must understand its current processes
  • This requires that
    • a process be properly documented
    • properly executed on subsequent projects
    • Data is collected from each process instance to help improve the performance of this process during a software development task
  • Changes to process are best made in small increments

Software Process Improvement Frameworks

• A SPI framework suggests ways of how process improvement can proceed
• Answers the question: What changes can be made to a process and when?
• The Capability Maturity Model (CMM) is an example SPI framework

CMM

• CMM has five maturity levels for a software process (level 1 is ad-hoc)
• Within a level, a process has some capabilities and lays the foundation for the next level
• For moving from one level to another, CMM specifies the areas to focus on
• CMM is used heavily by the software industry

CMM Levels

• Level 1: ad-hoc process, no formalized method for any activity, process capability is unpredictable
• Level 2: repeatable process, project management is well developed, policies and procedures for implementing a process exist
• Level 3: defined process, the organization has a standardized software process which is properly documented
• Level 4: managed process, quantitative goals exist for process and products; data is collected to help improve process
• Level 5: optimizing process, organization is in state of continuous process improvement, data is collected and routinely analyzed to find areas that need improvement

Coming Up Next

• Lecture 7: Concurrent Execution
• Lecture 8: Concurrent Execution: Part 2