What is a Cleanroom approach?

In this article we discuss the cleanroom approach in detail. The size of the team is usually small and is divided in to following three sub – teams:

1. Specification team: This team is responsible for the development and maintenance of the specifications.
2. Development team: This team is responsible for the development and verification of the software.
3. Certification team: This team is responsible for the development of statistical tests and reliability growth models. 

The incremental development is always carried out under statistical quality control so that the performance can be assessed at the end of every iteration using the following measures:

1. Errors per KLOC
2. Rate of growth in MTTF
3. Number of sequential error free tests.

The software development in cleanroom approach is purely based up on the mathematical principles whereas the testing is based up on the statistical principles. 

- Firstly, the system to be developed is formally specified and an operational profile is created. This profile and the formal specifications are then used to define the software increments which are then used for the two purposes namely:

1. Construction of a structured program
2. Designing of statistical tests: These tests also contribute to the first purpose.

- The constructed program is then formally verified and integrated with the increment.

Below mentioned is the flow of cleanroom approach:

1. Software requirements specification
2. Software design and development
3. Incremental software delivery
4. Incremental statistical testing
5. Regression testing
6. Software reliability measurement
7. Process error diagnosis and correction

- The incremental development planning is divided in to two parts namely:

1. Functional specification: It involves formal design correctness verification.
2. Usage specification: It involves statistical test case generation.

- Both these processes then merge down to statistical testing which then follows quality certification model and MTTF estimates.

- The whole cleanroom project develops around the incremental strategy. 

- Requirements are gathered from the customers and elicited and refined via the traditional methods.

- The definition of the data, its behavior and procedures are isolated and separated by the box structures at every level of refinement. 

- Specifications or the black boxes when iteratively refined become state boxes i.e., architectural designs and clear boxes i.e., the component–level designs.

- Formal inspections are carried out to make sure that the code confirms to standards, it is syntactically correct and its correctness has been verified. 

- Statistical usage planning involves creation of tests cases that match with the probability distribution of the usage pattern

- In place of the exhaustive testing, a sample of all the test cases is employed. 

- Once the programmers are done with all 3 activities (i.e., verification, inspection, usage testing, and defect removal) the increment is considered to be certified and ready to be integrated. 

- For developing a right system, customer feedback and involvement are 2 necessary elements throughout the process. 

- Increment planning is required so that the customer’s system requirements can be clarified. 

- There is a requirement of management of resources and control of complexity which is also achieved through incremental planning.

- In order to develop a quality product a control over the software development cycle and process measurement is very much required.

- Following are the benefits of concurrent planning:

1. Concurrent engineering
2. Step wise integration
3. Continuous quality feedback
4. Continuous customer feedback
5. Risk management
6. Change management

- All of the above benefits are achieved respectively by:

1. Certification and scheduling parallel development
2. Testing cumulative increments
3. Statistical process control
4. Through actual use
5. Treatment of the high risk elements in early phases
6. Systematic accommodation of the changes

Design verification advantage allows the cleanroom teams to verify each and every line of code. 

How does agile teams work?

Agile teams work together as a team but include roles filled by specific individuals.
- First is the product owner, who is responsible for the product vision and for prioritizing features the team will work on.
- Next is the customer, who is the person paying for the project or purchasing the software once it is available.
- Users, developers, and managers are other roles on an agile project.

How does agile team work?

- Agile teams work in short, time-boxed iterations that deliver a working product by the end of each iteration.
- The features developed in these iterations are selected based on the priority to the business.
- This ensures that the most important features are developed first.
- User stories are a common way for agile teams to express user needs.
- Agile teams understand that a plan can rapidly become out of date. Because of this, they adapt their plans as appropriate.

What kind of planning are used for agile teams?

Agile teams use three levels of planning:
- Release planning : The release plan looks ahead for the duration of the release - typically, three to six months.
- Iteration planning : The iteration plan looks ahead only the duration of one iteration - typically, two to four weeks.
- Daily planning : A daily plan is the result of team member commitments made to each other in a daily stand-up meeting.

During release planning, the whole team identifies a way of meeting the conditions of satisfaction for the release, which includes scope, schedule, and resources. To achieve this, the product owner may need to relax one or more of her conditions of satisfaction.
A similar process occurs during iteration planning, when the conditions of satisfaction are the new features that will be implemented and the high level test cases that demonstrate the features were implemented correctly.

Introduction to Crystal Agile Methodology and Agile Modeling

Crystal agile methodology is a software development approach. It is applicable for projects with small teams. It is a light weight approach. It is an adaptable approach. Crystal is a human powered methodology which means focus is on enhancing the work of the people. Crystal is ultra light which means it reduces the paper work, overhead involved. Crystal is stretch to fit methodology which means it grows just enough to get it to the right size. Crystal focuses on people and not processes.

Crystal consists of methodologies like Crystal Yellow, Crystal Orange, Crystal clear etc. It believes that project requires policies, practices and priorities as characteristics. Crystal methodology is based on the observation of various teams. Crystal methodology focuses on things that matter the most and make the most difference.

Agile Modeling suggests modeling is essential for all systems, but that the complexity, type, and size of the model must be in accordance with the software that is to be built. Some principles of agile methodology are:
- Agile Modeling is a practice based methodology.
- Values, principles and practices combine together for modeling.
- Agile Modeling is not a prescriptive process.
- Agile Modeling is not a complete software process.
- Agile Modeling focus on effective modeling and documentation.
- Developers using agile modeling should model with a purpose.
- Different models should be used to present different aspect and only those models should be kept that provide value.
- Traveling light is an appropriate approach for all software engineering work. Build only those models that provide value - no more, no less.
- During modeling, content is more important than representation.
- Be aware of the models and tools that are used to create them.
- The modeling approach should be able to adapt to the needs of agile team.

Agile modeling becomes difficult to implement in large teams, lack of modeling skills or team members are not co-located.

Team Software Process (TSP) - Framework Activities and Phases

Team Software Process (TSP) scripts define elements of the team process and the following framework activities:

- LAUNCH
It reviews course objectives and describes the TSPi structure and content. It assigns teams and roles to students and describes the customer needs statement. It also establishes team and individual goals.
- STRATEGY
It creates a conceptual design for the product and establishes the development strategy and decide what will be produced in each cycle. Strategy makes initial size and effort estimates and establish a configuration management plan, reuse plan and risk management.
- PLAN
It estimates the size of each artifact to be developed. Planning also identifies tasks to be performed, estimates time to complete each task;, assign tasks to team members, make a weekly schedule for task completion and make a quality plan.
- REQUIREMENTS
Requirements analyze need statements and interview the customers, specify and inspect the requirements and develop a system test plan.
- DESIGN
It creates a high-level design, specify the design, inspect the design, develop an integration test plan.
- IMPLEMENT
Implementation uses the PSP to implement modules/units, creates detailed design of modules/units, reviews the design, translates the design to code, review the code,
compile and test the modules/units and analyze the quality of the modules/units.
- TEST
Testing builds and integrate the system. It conducts a system test and produce user documentation.
- POSTMORTEM
It conducts a postmortem analysis, writes a cycle report and produce peer and team evaluations.

TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members in their work. Scripts defines specific process activities and other more detailed work functions that are part of the team process.
TSP recognizes that the best software teams are self directed. Team members set project objectives, adapt the process to meet their needs, have control over schedule, and through measurement and analysis of the metrics collected, work continually to improve team's approach to software engineering.

Team Software Process (TSP) - Strategy and Objectives

The goal of Team Software Process (TSP) is to build a self directed project team that organizes itself to produce high quality software. The objectives of TSP are:
- The TSP is intended to improve the levels of quality and productivity of a team's software development project.
- Using TSP, organizations establish a mature and disciplined engineering practice that produces secure, reliable software in less time and at lower costs.
- Accelerate software process improvement by making CMM level 5 behavior normal and expected.
- Show managers how to coach and motivate their teams and how to help them to sustain peak performance.
- Build self directed teams that plan and track their work, establish goals, and own their processes and plans. To form a self directed team, you must collaborate well internally and communicate well externally.

A self directed team should do the following:
- understand overall goals and objectives.
- defines roles and responsibilities for each team member.
- tracks quantitative project data.
- identifies a team process appropriate for project.
- implementing strategy for the process.
- defines local standards.
- assess risk and reacts to it.
- tracks, reports and manages project status.

TEAM SOFTWARE PROCESS (TSP) STRATEGY

- Provide a simple process framework based on the PSP.
- Use modest, well-defined problems.
- Develop products in several cycles.
- Establish standard measures for quality and performance.
- Provide detailed role definitions.
- Use role and team evaluations.
- Require process discipline.
- Provide guidance on teamwork problems.

Cleanroom Software Engineering - Advantages, Principles and Process Teams

Cleanroom software engineering involves the integrated use of software engineering modeling, program verification and statistical software quality assurance.
- Cleanroom software engineering verifies design specification using mathematically-based proof of correctness.
- Cleanroom software engineering relies heavily on statistical use testing to uncover high impact errors.
- Cleanroom software engineering generally follows an incremental development process.

CLEANROOM PRINCIPLES

- Small Teams include independent specification, development, and certification sub-teams.
- Incremental development under statistical quality control.
- Software development is based on mathematical principles. The box principle is used for specification and design. The formal verification is used to confirm correctness of implementation of specification. The program correctness is verified by team reviews using questionnaires.
- Testing is based on statistical principles.

CLEANROOM PROCESS TEAMS

- Specification team develops and maintains the system specification.
- Development team develops and verifies software. The software is not compiled or executes during verification.
- Certification team develops set of statistical test to exercise software after development. Reliability growth models are used to assess reliability.

BENEFITS OF CLEANROOM SOFTWARE ENGINEERING

- Zero failures in the field which is a goal but a realistic expectation is<5 failures per KLOC on first program execution in the first team project.
- Short development cycles
- Longer product life.