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