What is an Agile Process Improvement?

A process improvement program is successful only when the meaning of the word ‘process’ is clearly understood. Process means work. So when one improves, the other one also improves. The quality of the software depends a lot on the process. Whenever a change is introduced, a temporary drop in performance is always recorded. In most cases what happens is that the organization stops the implementation of changes fearing the disruption in the normal work since so much effort is required. To avoid such situations, the changes need to be adaptive. It is the agile process improvement that makes this possible. You might say that such a way of iterative improvement is not new. Well, the agile techniques introduce discipline in the whole program.

Stages of Agile Process Improvement

The following are the stages of the agile process improvement:

1. Initiating:

Ø  Stimulus of change

Ø  Set context

Ø  Build sponsorship

Ø  Charter infrastructure

2. Diagnosing:

Ø  Characterize current and desired states

Ø  Develop recommendation

3. Establishing:

Ø  Set priorities

Ø  Develop approach

Ø  Plan actions

4. Action:

Ø  Create solution

Ø  Test solution

Ø  Refine the solution

Ø  Implement solution

5. Learning:

Ø  Analyze

Ø  Validate

Ø  Propose future actions

- The improvement cycles are meant to be followed systematically so that the results might be obtained in time ranging from 2- 6 weeks.

- The whole process lets you maintain a balance the workload as well as the improvement. 

- The flow of the process is as follows:

1. Prioritized list of improvements
2. Detailed plan for the current cycle
3. Implemented improvement
4. Feedback

- After this process, the following becomes possible for the organization:

1. Identification and resolving of the issues earlier in the cycle.
2. Learning process regarding how to tackle difficulties and working of this process.
3. Adaption to the business needs that keep changing.
4. Giving response to the feedback.

- The sponsor holds the responsibility for prioritizing the improvement backlog at the start of each sprint. 

- Also, he is the one responsible for ROI. 

- Prioritization is a good tool for the sponsor to direct the change. 

- Using prioritization, the goals and feedback can be revised from quality assurance. 

- A focus can be kept on the benefit received from each improvement cycle. 

- PPQA deploys and evaluates the improvement in organization in every sprint. - The improvement package consists of 4 sprints namely:

1. Prototyping
2. Piloting
3. Deploying
4. Evaluating

- Active participation and leadership is required for a change to take place. 

- An endorsed vision and status quo is required for the beginning of the process. 

- Both of these are established via SCAMPI and CMMI. 

- The change is led by the management on an everyday basis.

- An excellent description is provided by the generic practices of CMMI for the leadership purpose.

- Similarly participation is a key element that is facilitated by the change team. - A vision is required for initiating the improvement project. 

- The initial improvement backlog is defined by 3 things namely scrumMaster, change team and the work owner i.e., the sponsor all based up on an assessment. 

- The organization is facilitated by the change team.

- With each sprint a tangible improvement is delivered. 

- The change is led by the management in a sprint.

- The effect introduced by the change is evaluated at the end of each sprint by PPQA. 

-The new improvements are defined by the work-owner who is also responsible for adding those in to the backlog of improvements and prioritizes it.

-Commitment is supported at the end of the sprint by appraisal.

-The improvements can also be continuously integrated in to the organization’s way of working. 

What are requirements for Cleanroom Software Engineering? What is the need for CSE?

The process got its name from the term cleanroom which is part of the process that fabricates the semiconductors. The basic ideology behind the cleanroom software engineering process is that it is more focused up on avoiding the defects rather than removing them.  It makes use of a combination software quality methods and formal methods. Cleanroom software engineering has shifted the individual craftsmanship to peer reviewed process, from sequential development to incremental one, from informal designing to discipline specification and designing, from informal coverage to statistical usage testing and so on.

Cleanroom software engineering is actually an integration of the following three practices:

1. Program verification
2. Software engineering modeling
3. Statistical software quality assurance

The correctness of the design specifications is verified via mathematically based proof solutions. The role of the statistical usage testing here is to dig out the high impact errors. 

The following the stages through the incremental development:

1.   Establishing the requirements

2.   Formal specifications

3.   Development of the increment

4.   Delivery of the software

5.   Requirements change request

Why Cleanroom Software Enginnering is required?

- Cleanroom software engineering is required to develop software systems and application with zero defects. 

- Though it takes a lot of time to be implemented but the payoff is quite high and both quality and productivity are increased. 

- The actual cleanroom process begins after the formal specification has been done. 

- The focus then shifts towards building a more explicit design. 

- Next, the design is verified as per the specifications. 

- Two things namely statistical and mathematical reasoning are combined and used together by the cleanroom approach for test generation and testing as well. 

- Cleanroom software engineering has proven to be the first practical attempt for developing the software with statistical quality control and delivering the software product with a known MTTF.

Requirements of Cleanroom Software Engineering

- The key requirements of cleanroom approach are nothing but specifications, requirements and verification methods.

- These formal specifications and verifications are used for developing software of high quality and with a minimum of errors. 

- Statistical usage testing is also required for the evaluation of the reliability of the software product. 

Cleanroom software engineering is followed by a number of benefits:

1. Zero failures: This is the objective itself and the software is developed with a minimum number of errors if zero not possible.
2. Short development cycles: These are the resultant of the incremental process. The rework is avoided and therefore new teams get a chance to experience productivity increase that has increased by two folds.
3. Longer product life: The product life is kept longer with the help of a usage model and investments detailed specifications.

- It is also a fact that the cleanroom techniques are not much used since some people believe them to be too mathematical, theoretical, radical etc. to be used in the real development processes. 

- Also, these techniques rely heavily on the statistical quality control and correctness verification rather than relying on unit testing. 

- This means that there is a large deviation from the traditional software development approach. 

- Proving the program is always there in the option list but it requires a lot of intensive sophisticate mathematical work. 

- Therefore, in place of this, cleanroom uses an alternative.

- A team code inspection is structured in terms of verification conditions and program functions.

-  Then an informal review is carried out which confirms whether or not all the verification conditions have been satisfied. 

What are Six Best Practices in Rational Unified Process?

The IBM Rational Unified Process is a means of commercial deployment of the approaches and practices which have been proven for the development of the software systems and applications. It is based up on the following six best practices:

1. Iterative development of the software systems and applications
2. Management of the requirements
3. Use of architecture based up on the components.
4. Visual modeling of the software system
5. Verification of the software system.
6. Controlling the changes to the software system or application.

The above mentioned practices are called the best practices not because their value can be precisely quantified but because they are quite common in the software industry by most of the organizations which are successful and reputable.

In the rational unified process each and every member of the team gets templates, guidelines as well as the tools which are found necessary for the whole of the team in order to reap the full advantage.

Basic Practices In Rational Unified Process in Detail

Iterative development of the software systems or applications:  

- Software systems and applications are quite sophisticated and therefore they make it impossible to define the problem first in sequence.

- By sequence we mean, first defining the whole problem, designing a solution of the problem, building the software system or application and then finally testing the software system. 

- In order to deal with such software systems and applications there is a requirement of an iterative approach so that an increase in the understanding of the problem can be made in a series of successive refinements. 

- This also helps in developing an effective solution in increments done over multiple iterations.

Management of the Requirements: 

The rational unified process gives a description:

- On how the elicitation, organization and documentation of the constraints as well as the functionality is to be done, 

- how the trade-offs and decisions have to be tracked and documented and 

- how the business requirements are to be captured and communicated.

Use of architecture based up on the components: 

- The focus of the development process is on the base-lining and early development of an architecture that is robust and executable as well. 

- It gives a description of how a resilient architecture can be built with more flexibility that can accommodate the changes easily, can be easily understood and effectively promotes the reuse of the existing software artifacts. 

- The rational unified process provides a great support to the component based development. 

- By components we mean, the sub systems and non – trivial elements for a clear function.

Visual modeling of the software system: 

- The rational unified shows you exactly how a software system or application can be visually modeled and can be used for capturing the behavior and structure of its architectural components. 

- This further enables you to hide the details and develop the code with the help of the graphical building blocks. 

- With such visual abstractions, communication can be established between the different aspects of the software system or application.

Verification of the software system: 

- Poor reliability dramatically cuts down the chances of a software system or application from being accepted.

- Therefore it is important to review the quality concerning the factors namely functionality, reliability, system performance and application performance etc.

Controlling the changes to the software system or application: 

- The management and ability to track the changes are critical to the success of any software system or application. 

- However, the rational unified process helps you to cope with these issues also.

What are Rational Unified Process building blocks?

Whenever we talk about iterative software development process frame works, the first name that comes to our minds is of the rational unified process. It is not just a single hard coded prescriptive process rather it is quite an adaptable and flexible process frame work. 

This frame work comes with several facilities, the best one being that your organization can tailor it according to their needs. 

What is Rational Unified Process?

- Unified process when specifically implemented is called as the rational unified process. 

- Rational unified process is counted among the best products of IBM and the credit for its development goes to the rational software division.

- The RUP comes with a hyper linked base consisting of the descriptions of several types of activities and a few sample artifacts. 

- A part of the IBM’s rational method composer (RMC) is occupied by the rational unified process.

- It allows the users to customize the process as per their needs. 

What are building blocks of Rational Unified Process?

In this article we are to talk about the building blocks of the rational unified process.

- These basic best practices of the rational unified process were developed as a result of the combination of the experience of many companies. 

- The building blocks are:

1. Iterative development with risk as its primary iteration driver.
2. Management of the requirements.
3. Employment of an architecture based up on components.
4. Visual modeling of the software.
5. Continuous verification of the quality.
6. Controlling the changes

- These best practices are used in the following two ways:

1. For driving the development process of the rational’s products.
2. To be used by the rational’s field teams so as to assist the customers in improving the predictability as well as the quality of the software development efforts.

- The task involves the assembling of the explicit process framework for the field of modern software engineering. 

- The delivery mechanism developed by the objector was based up on the HTML and employed in accomplishing this task.

- This task resulted in the creation of the rational unified process. 

- A set of content elements or the building blocks form the foundation for the rational unified process and give a description of the product that is to be produced and the required necessary skills. 

- They also give a detailed step by step explanation for achieving the specific development goals. 

Now we shall list all the building blocks of the rational unified process and discuss them in detail:

1. Roles: This building block can be defined as set consisting of related skills, responsibilities as well as competencies.
2. Work products: This building block gives the representation of thing that would result when a task would be completed inclusive of all the models and documentation produced during the course of the completion of that task.
3. Tasks: This building block gives a description of the units of works that are assigned to an element from the role which will produce a result that would be meaningful.

There are 9 disciplines in to which the tasks are categorized within each iteration. There are 6 engineering disciplines and 3 supporting disciplines which together make up total 9 disciplines. The 6 engineering disciplines are:

1. Business modeling
2. Requirements
3. Analysis and design
4. Implementation
5. Test and
6. Deployment

The following are the three supporting disciplines:

1. Configuration and change management
2. Environment and
3. Project management

The organization and the management of the above mentioned building blocks need to be solid and flexible in order to make the rational unified process a success which otherwise cannot be achieved. 

Explain Rational Unified Process (RUP)?

Rational Unified Process development framework was developed by a division of IBM known as the rational software corporation. Rational Software Corporation has been a part of IBM since the year of 2003. 

About Rational Unified Process

- Rational unified process is a single process that has a concrete prescription.

- It is a process frame work which is adaptable to a large extent and can be tailored by the organizations and development corporations as per their needs. - They can select the elements of the process that they want to be present in their development approach. 

- The rational unified process or RUP is a product that is used to process other products. 

- This product is built on a hyper linked base of knowledge consisting of detailed description about a lot of activities along with some sample artifacts.  - Rational unified process constitutes a part of the IBM’s RMC product or rational method composer.

- It is used for customizing the rational unified process. 

- All the companies combined their experiences and declared 6 best practices that are known to drive the rational unified process. 

- Those 6 best practices are:

1. Iterative development where the risk is taken as the primary iteration driver.
2. Management of the requirements.
3. Employment of an architecture based up on component.
4. Visual modelling of the software system or application.
5. Continuous verification of the quality.
6. Controlling of the changes.

- The above mentioned 6 best practices are followed by the rational’s field teams in order to assist the customers in improving the predictability as well as quality of the efforts that they put for the development of the software.

- The resulting rational unified frame work had the following three main strategic characteristics:

1. This process is tailor-able for the effective guidance of the development process.
2. Consists of tools that are used for the automation of the process.
3. Involves services that accelerate and make the adoption of both the tools and processes easy.

- Rational unified process came into existence on the acquiring of the objector y process in the year of 1996 that was written by Ivar Jacobson. 

- This original process consisted of the content from the following three things:

1. Object modelling technology or OMT from Jim Rumbaugh,
2. Booch approach by Grady Booch and
3. UML 1.0

- Later the year of 1997 saw the addition of the test discipline and requirements to the approach. 

- Below mentioned are the additions to the approach that were made subsequently after the year of 1997:

1. Year 1998 saw the addition of two new disciplines namely configuration and change management discipline and business modelling. Other things that were added included the following techniques:

a)   Performance testing

b)   UI design

c)   Data engineering

Further the rational unified process was updated to 1.1 version of the UML.

2. Year of 1999 saw the addition of the project management discipline and techniques that supported the real time development of the software. Also the rational unified was again updated to UML 1.3.
3. From year 2000 onwards most of modifications were centered around the adding tool mentors, adding techniques along with a basic guide containing step by step instructions up on how the rational tools are to be used and how the customization of the rational unified process can be automated using which customers could customize their own process and at the same time incorporating improvements in the following releases. 

What are the characteristics of the unified process?

- Unified process is one of the most popular software development frame works based on the iterative and incremental approach.

- Unified process is a frame work that is extensible according to the needs of the software development project or according to the needs of the specific organizations. 

- The unified process signifies the generic processes that include elements that have been declared common for most of the refinements. 

- The unified process was first discussed in detail in a book called “the unified software development process” in the year of 1999. 

- Every process has got some characteristics and so does the unified process.

Characteristics of Unified Process

1. Iterative and Incremental Process: 

- There is no doubt believing that the unified process is an iterative and incremental one. 

- This is evident from the fact that the all the below mentioned 4 phases of the whole process are divided in to a set of time boxed iterations:

(a)  Inception

(b)  Elaboration

(c)  Construction and

(d)  Transition

- Depending up on the complexity and the size of the project, the inception phase may also be further divided in to a large number of small iterations to keep the over all development process as simple as possible. 

- The increments are the result of the individual iterations that are performed during the whole development process.

- These increments can be defined as a system containing improved and added functionalities that extend over those that were present in the previous version of the same software system or application.

- Mostly the iterations take care of the following aspects of the software:

       (a)  Requirements

       (b)  Testing

       (c)  Design implementation and so on.

2. Use case driven: 

- The unified process is rightly called the use case driven software development methodology since it is driven by the use cases that are quite effective in capturing the contents of the iterations and the functional requirements.

- Each iteration involves a number of use cases as well as scenarios for the proper identification of the requirements, their implementation, testing and deployment.

3. Risk Focused: 

- The unified process requires that the most critical risks in the whole development cycle are focused up on in the early stages of the life cycle of the process. 

- For addressing the factors with the highest risk rating, the deliverable of all the iterations especially in the second phase of the life cycle i.e., the elaboration phase are selected in a pre-defined order.

4. Architecture Centric: 

- It is obvious that the success of any software development process is greatly dependent on what kind of architecture is being used in it. 

- Architecture seems to work the very best at the heart of any software development process. - With the right architecture in the process, the efforts of the teams can shape the software system or application the way they want. 

- One problem is encountered here which is that only one model never suffices in providing coverage in a unified process, several models have to be conjoined and used. 

- It is one of the attractive features of the unified process that it supports multiple architectural views and models. 

- The elaboration phase witnesses the creation of an executable architecture baseline which can be called as an important deliverable. 

Differentiate between Capability Maturity Model (CMM) and Scrum?

In the year of 2002, when both the CMM (capability maturity model) and agile software development models were on the list of the highest demanded software development methodologies, the CMM model and agile processes were considered to be to pretty much same.

But, later in the same year two of the software engineers Jain and Turner argued that these two software development models or processes have much difference between them if investigated in detail.

This article discusses about the differences between the cmm model and agile methods. There is no fixed or appropriate way to develop a software system or application but at different stages a different methodology is to be adopted. 

Coming to the scrum, it is a pre defined development life cycle based entirely up on the agile principles. The CMM on the other hand comprises of many practices that can be adopted by a team so as to improve its overall performance. The CMM model pays more attention to the areas that require change and project management. 

Another aspect of the CMM is focussed up on the following three aspects:

1.      Engineering skills

2.      Organizational learning

3.      Advanced project management

Differences between Capability Maturity Model and Scrum

Difference #1:

- In CMM, it is required that an understanding is developed with the requirement

providers  based upon the definition of the requirements.

- In Scrum, there are reviews of the requirements listed in the product back log with

development team and product owner.

Difference #2:

- In CMM, commitment to the requirements is demanded from all those involved in    

the project. 

- In Scrum practice, the commitment is needed in the sprint planning and release 

planning.

Difference #3:

- In CMM, practice any changes to be made are directly carried out on the

requirements.

- In Scrum practice, the changes are recorded in the product back log and are worked 

up on in the later sprints.

Difference #4:

- In CMM, it involves the identification of the inconsistencies among the work 

products and the requirements.

- In Scrum practice, the inconsistencies are identified during the sprint planning and

release planning sessions.

Difference #5:

- CMM develops a top level work breakdown structure for the proper estimation of the  

project scope. 

- In scrum, the standard tasks combined with the specific project tasks define the 

scope of the project.

Difference #6:

- In CMM, the attributes of the work products and tasks are maintained kept for the 

maintenance of the estimates.

- In scrum, this task is done with the help of story points.

Difference #7:

- In CMM, the whole project budget and schedule is prepared in CMM.

- In scrum, a project is broken down in to several sprints and for every sprint there is a 

separate schedule and back log.

Difference #8:

- The main estimates that are carried out in CMM are of the resources required to 

perform the development tasks. 

- On the other side, the scrum maintains the estimates of the sprint back log, release 

plan and assignments.

Difference #9:

- In CMM a plan of involvement is prepared for all the stakeholders separately during 

the planning process.

- In Scrum, there are predefined core and ancillary roles that saves a lot of time.

Difference #10:

- In CMM, at the end of the day the project plan is re-conciliated to check out the 

available resources.

- In scrum, there is sprint planning meetings and daily scrum meetings to do this task.

Difference #11:

- The project development in CMM is tracked by monitoring the actual values of the 

project parameters against the already prepared project plan. 

- On the other hand the scrum is aided by the sprint burn down charts for the same 

purpose.