A bench-mark for measuring the maturity

of an organization’s software process

CMM defines 5 levels of process maturity

based on certain Key Process Areas

(KPA)

Level 5 – Optimizing (< 1%)-- process change management

-- technology change management

-- defect prevention

Level 4 – Managed (< 5%)-- software quality management

-- quantitative process management

Level 3 – Defined (< 10%)-- peer reviews

-- intergroup coordination

-- software product engineering

-- integrated software management

-- training program

-- organization process definition

-- organization process focus

Level 2 – Repeatable (~ 15%)-- software configuration management

-- software quality assurance

-- software project tracking and oversight

-- software project planning

-- requirements management

Level 1 – Initial (~ 70%)

A framework that describes the activities

performed at each stage of a software

development project.

Requirements – defines needed information, function, behavior, performance and interfaces.

Design – data structures, software architecture, interface representations, algorithmic details.

Implementation – source code, database, user documentation, testing.

All requirements must be known upfront

Does not reflect problem-solving nature of software development – iterations of phases

Little opportunity for customer to preview the system (until it may be too late)

Requirements are very well known

Technology is understood

Construct a partial implementation of a total system

Then slowly add increased functionality

Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

Lowers initial delivery cost

Initial product delivery is faster

Customers get important functionality early

Requires good planning and design

Total cost of the complete system is not lower

Need to get basic functionality to the market early

On projects which have lengthy development schedules

A variant of the

Waterfall that

emphasizes the

verification and

validation of the

product.

Testing of the product

is planned in parallel

with a corresponding

phase of development

Emphasize planning for verification and

validation of the product in early stages

of product development

Each deliverable must be testable

Project management can track progress

by milestones

Easy to use

Time Consuming

Coastly

All requirements are known up-front

Solution and technology are known

Developers build a prototype during the

requirements phase

Prototype is evaluated by end users

Users give corrective feedback

Developers further refine the prototype

When the user is satisfied, the prototype

code is brought up to the standards

needed for a final product.

Customers can “see” the system requirements as they are being gathered

Developers learn from customers

A more accurate end product

Overall maintainability may be overlooked

The customer may want the prototype

delivered.

Process may continue forever (scope creep)

Requirements are unstable or have to be clarified

Develop user interfaces

Short-lived demonstrations

Agile methodology is an approach to

project management, typically used in

software development. It helps teams

respond to the unpredictability of

building software through incremental,

iterative work cadences, known as

sprints.

Speed up or bypass one or more life

cycle phases

Usually less formal and reduced scope

Used for time-critical applications

Adaptive Software Development (ASD)

Feature Driven Development (FDD)

Crystal Clear

Dynamic Software Development Method (DSDM)

Rapid Application Development (RAD)

Scrum

Extreme Programming (XP)

Rational Unify Process (RUP)

DePaul web site has links to many Agile references

http://se.cs.depaul.edu/ise/agile.htm

As a brief introduction, Scrum is an agile process for

software development. With Scrum, projects

progress via a series of iterations called sprints.

Each sprint is typically 2-4 weeks long. While an

agile approach can be used for managing any

project, Scrum is ideally suited for projects with

rapidly changing or highly emergent requirements

such as we find in software development.

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team.

This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.

Scrum team, typically made up of between five and nine people, but Scrum projects can easily scale into the hundreds. The team does not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that “we’re all in this together.”

Product owner;- The product owner is the project’s key stakeholder and represents users, customers and others in the process. The product owner is often someone from product management or marketing, a key stakeholder or a key user.

Scrum Master:- The Scrum Master is responsible for making sure the team is as productive as possible. The Scrum Master does this by helping the team use the Scrum process, by removing impediments to progress, by protecting the team from outside, and so on.

Scrum Master:- The Scrum Master is responsible for making sure the team is as productive as possible. The Scrum Master does this by helping the team use the Scrum process, by removing impediments to progress, by protecting the team from outside, and so on.

The product backlog is a prioritized features list containing every desired feature or change to the product.

Sprint planning meeting :At the start of each sprint, a sprint planning meeting is held during which the product owner prioritizes the product backlog, and the scrum team selects the work they can complete during the coming sprint.

That work is then moved from the product backlog to the, sprint backlog which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint.

Daily scrum Calls : Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track. All team members are required to attend the daily scrum.

At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint. Typically, this takes the form of a demonstration of the new features, but in an informal way; for example, PowerPoint slides are not allowed. The meeting must not become a task in itself nor a distraction from the process.

Requirements planning phase (a workshop utilizing structured discussion of business problems)

User description phase – automated tools capture information from users

Construction phase – productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”)

Cutover phase -- installation of the system, user acceptance testing and user training

Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs

Focus moves from documentation to code WYSIWYG. (What-You-See-Is-What-You-Get)

Accelerated development process must give quick responses to the user

Hard to use with legacy systems

User involved throughout the life cycle

Project can be time-boxed

High performance not required