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. 

What is a Unified Process? What are key practices and guidelines for unified process?

What is Unified Process?
- Unified process is actually the short name for the USDP or the unified software development process.
- This software development process has recently emerged as a very popular incremental and iterative software development process frame work. 
- There are some methodologies defined under the category of the unified process and the one that is most commonly implemented and extensively documented in the rational unified process known as RUP in the abbreviated form. 
- The concept of the unified process is very vast and it cannot be merely called as only a process! Rather it can be thought of as an extensible frame work which is customizable according to the needs of the software project or the specific organizations. 
- Concluding from this, the rational unified process can also be called a customizable frame work. 


However the name “unified process” in quite opposing to the rational unified process generally marks the generic processes that include the elements that hold common for most of the refinements. 
In addition to this this name also avoids the potential issues of the trade mark infringement that arise since the RUP and the rational unified process are the trademarks of the IBM. 
The unified process was first mentioned and described in detail in a book by Ivar Jacobson, James Rumbaugh and Grady Booch called “the unified software development process” in the year of 1999.

Six Practices of Unified Process

The unified process deploys the following 6 key practices of software development:

1. Development of the software in iterations: Increases understanding of the problem through successive refinements. An effective solution is achieved over several increments.
2. Management of requirements: Involves elicitation, organization and documentation of the required constraints and functionalities, trade offs and so on.
3. Implementation of component based architectures: A robust executable architecture is subjected to baselining first and then resources are deployed for full scale development. Promotes resiliency of the architecture.
4. Visual modelling of the software: This practice helps capture the behaviour of the architectural components of the software system.
5. Verification of the software quality: Poor reliability and poor performance are the factors that weigh down the quality of the software system or application. This practice reviews the software quality.  
6. Controlling changes that are to be made in the software: This practice ensures that the changes to be incorporated are acceptable and won’t hamper the performance. 

Developers often want the answer for the question, "how do I know if I’m implementing the unified process properly?" There is no certain answer for this question but there are certain guidelines which if followed properly can keep the process on track:

1. Figure out the major risks early and regularly or they will hamper the performance of your software system.
2. Ensure the value that you are going to deliver to your customer.

Unified process as a heavy defined process VS an Agile unified process approach

Unified process is another process in the list of the iterative and incremental processes apart from the agile processes. There are so many refinements and variations of the unified process as mentioned below:

1. RUP or Rational Unified Process: A refinement of the Unified process developed by the IBM/rational software.
2. RUP- SE or Rational Unified Process - System Engineering: This is a version of the rational unified process developed by the rational software for catering to the needs of the system engineering.
3. AUP or Agile unified process: It is a lightweight variation that was developed by Scott W. Ambler.
4. OpenUP or Open unified process: It is the eclipse process frame work software development process.
5. BUP or Basic unified process: It is also a lightweight variation but developed by the IBM. It is kind of a precursor to Open UP.
6. EssUP or Essential unified process: Another light weight variation developed by the Ivar Jacobson.
7. EUP or enterprise unified process: It is an extension of the RUP or the rational unified process.
8. OUM or oracle unified method: A development and implementation process developed by the oracle.

So you see that the agile unified process is a refinement of the unified process! So what is the difference between the two? This is what we have discussed in the article. Actually there is a subtle difference between the two in the way that they categorize the project work flows and the disciplines. 

Disciplines addressed by RUP

There are nine disciplines that are addressed by the rational unified process as mentioned below:

1. Business modelling
2. Requirements
3. Analysis and design
4. Implementation
5. Test
6. Deployment
7. Configuration and change management
8. Environment
9. Project management

9 disciplines is a big count! The agile refinements of the unified process simplify the whole rational unified process further and reduce the above mentioned nine disciplines to a lesser count making the whole development process simple and short. 

Points of Comparison between RUP and AUP

- Unified process though being quite an advance process for developing the software but it provides quite a heavy approach. On the other hand the agile unified processes are quite light. 

- These processes provide a way of streamlining the rational unified process by minimizing the number of the expected artifacts and simplify the whole work flow. 

- The UP and the AUP also vary in their specifications of what happens after the completion of the transition phase.

- In the agile unified processes, the transition phase is followed by a production phase rather than by a new inception phase in the case of the unified process.

- There are countless numbers of the unified process refinements and variations. 

- There are 4 phases in a unified process namely:

1. Inception phase
2. Elaboration phase
3. Construction
4. Transition

In addition to the above 4 mentioned phases, the agile unified processes go through the two additional phases namely: 
    1. The retirement phase and
    2. The Production phase.

The below mentioned are the philosophies up on which the agile processes are based:

1. The development knows what is being done.
2. Simplicity is maintained.
3. The whole process confirms to the principles and values of the agile software.
4. Focus is on high value activities.
5. It is tool independent.

The agile unified process makes use of two types of iterations namely:

1. Development release iteration: deployment to the quality assurance and
2. Production release iteration: deployment to the production area.

What are common mistakes and misunderstandings in a unified process?

As it is always said “to err is human”, one may make innumerable mistakes. This truth holds good for every aspect of our lives and so for the technology also. While programming, it is obvious that some mistakes will be made but they are not intended, some mistakes might creep in without the knowledge of the programmer; other mistakes might arise due to a lack of knowledge of the programmers and the developers! 

Anything is possible. With so much complex and advanced software systems and applications to build around it is obvious for the programmers and the developers to make mistakes while programming the software because it is not the feature of human intelligence to keep of check of each and every bit of the program that is being built.

Well, this article has been focused up on the mistakes and misunderstandings that result in mistakes in a unified process. Such mistakes and misunderstandings in a development can cause severe problems in the whole development process causing further problems in the software system or application that is being built. 

What are common mistakes in unified process?

There are various mistakes that one can make while programming using the unified process. 

- The very common mistake that is done is that the complex problems might be made more complex due to lack of sufficient understanding of the methodologies that are available for programming or may be because wrong or inappropriate methodologies might have been put in to use. 

- The problem that occurs here is for adopting any software development process different people assume different values and hence it is like using a single software development process for every programmer or developer.

- For getting the appropriate solutions to the programming problems it is not necessary that the programs should be developed with the extreme agile or test driven development methodologies. See this is where the people make mistakes!

- When a software system or application can be developed using the simplest of the methodologies available then why go for the complex and the tough ones? 

- Even though the agile processes and the unified software development processes are a big step towards the advancement of the software development, it is not always that they can be extended for all sorts of softwares and applications.

- The best way to avoid much of the problems is to train the programmers and developers in information protection. It does not require months and weeks to learn about common software security mistakes and misunderstandings. 

Examples of Common Mistakes

- Suppose that during programming a file was not locked properly and there are two parts of the programs that access the same file without properly locking it. 

- Such a case can result in a race condition between the two programs that can make the file quite unstable or in a vulnerable condition. 

- Another mistake can be logging in trying many passwords in just few seconds without giving the system a proper time to check. 

- The spirit of a programmer should be as such that even if he/ she has not made the mistakes he/she should take the responsibility to correct them before they cause more harm to the software system or application. 

- The longer the time is spent on writing the programs the more you avoid the mistakes. 

Phase 3 of Unified Process Lifecycle - Construction

Unified process has never been so late in making its mark in the field of the iterative and incremental software development approaches. The unified process has got many refinements and one of them is the rational unified process. The whole process has been divided in to 4 phases the names of which are:

1. Inception
2. Elaboration
3. Construction and
4. Transition

The third phase i.e., the construction phase is what we have discussed throughout this article. So let us see what does this phase actually consists of. This is perhaps the largest phase of the whole unified software development process.

The progress that is to be made in this phase is completely dependent on the foundation that was laid in the previous phase. We mean to say that the remaining structure of the software system is built on the baseline that was developed in the elaboration phase. 

What is the Construction Phase

- Since the construction will be based up on the architecture baseline it is required that the baseline must have been properly developed along with the addressing of the risk factors. 

- In this phase, the implementation of the features and functionality of the software system takes place in an iterative manner and involves the time boxed iterations which are generally of very short duration. 

- These iterations are developed as a time boxed series and with every iteration an executable release of the software system or application is produced. 

- It is quite customary that the full length use cases must be written during the construction phase which then serves as a beginning for a new iteration and the process continues. 

- This phase makes use of the common UML (unified modelling language) diagrams. 

- Some of the common UML diagrams that are generally used are mentioned below:

1. Activity diagrams
2. Sequence diagrams
3. Collaboration diagrams
4. State diagrams
5. Transition diagrams
6. Interaction overview diagrams and so on.

- This is the phase that witnesses a lot of coding takes place since the primary objective is to build the software system or application. 

- However, the primary focus is on the development of the features and components of the system throughout the construction of the software system or application. 

- The number of the iterations involved in the construction depends largely up on the size of the project.

- This is generally done with the purpose of dividing the use cases in to small segments that are manageable enough and lead to the production of the demonstrable prototypes. 

- This is the phase in which the first external release of the software product is produced and this stage is marked by the IOCM or initial operational capability milestone. 

Goals defined for Construction Phase

Few goals have also been defined for this phase of the unified process as mentioned below:

1. Describing the remaining requirements that were not addressed in the preceding phases.
2. Drawing up a design for the system.
3. Ensuring that the system meets the needs of the customers and fit in to the port folio of the organization.
4. Completing component development.
5. Testing of the system and its documentation.
6. Optimizing the resources so that the development cost is reduced.
7. Achieving as much quality as possible.
8. Developing useful versions of the software product.

There is always a rush among the software development organizations to improve the software development processes they are using. Around 80- 90 % of the software failure arises due to faults that are made during the construction phase of the unified process. It is obvious that a more sensible approach will be followed out of all the options available.   

Phase 2 of Unified Process Life cycle - Elaboration

Unified process is one of the outstanding processes that follow an iterative and incremental approach for the software development. The whole process of the unified process is constituted of the 4 stages or phases namely:

1. Inception
2. Elaboration
3. Construction and
4. Transition

This article is dedicated to the second phase of the unified process i.e., the elaboration phase. So let us see what all processes are involved in this phase. 

There exists a short phase between the inception phase and the elaboration commonly knwn as the “elicitation” phase. It is sometimes regarded as apart of the elaboration phase only but to keep the elaboration phase short and simple it is often treated separately.

First let us know what is this elicitation phase? 

Elicitation addresses the below mentioned three main problems of the software development process:

1. Problem of volatility
2. Problem of scope
3. Problem of understanding

What is an Elaboration Phase?

- During this whole elaboration phase, it is required that the project team captures quite a large number of the requirements of the software system or the application. 

- But this is not to be confused with the primary goal of the elaboration phase. It is quite different. 

- The primary goal involves the addressing of the involved and known risk factors. 

- Another aspect of the primary goal is to validate the architecture model being used in the system. 

- This is done with the help of various processes like those mentioned below:

1. Creation of use case diagrams
2. Creation of class diagrams
3. Creation of class with basic notation only and
4. Creation of architectural or the package diagrams.

- All these above mentioned processes fulfil only the first aspect of the primary goal that is to identify the risk factors. 

- The second aspect is fulfilled through the implementation of an EAB or an executable architectural baseline.

- It helps greatly in validation of the system architecture. 

- This is just a partial implementation rather than being a full implementation. 

- The partial implementation is of the components that are architecturally significant like the system including the core.

- The executable architecture baseline is built out of a series of small iterations that have been time boxed so that there is the stabilization of the architecture of the system by the end of the elaboration phase. 

- The executable architectural baseline provides a means to demonstrate that the key system functionality are supported by the architecture and also exhibit proper expected behaviour when it comes to the terms like the scalability, performance and cost. 

- The outcome of the elaboration phase i.e., the elaboration phase deliverable actually serves as a plan for the construction phase that also lays down the cost estimate and the schedule estimates.

- The plan at this point needs to be credible and quite accurate since the elaboration phase experience is what on which it is dependent and also because all the significant risk factors have been addressed during this phase. 

- The ultimate purpose of this phase is to provide the software with a baseline for the architecture of the software system that serves as a foundation for the further efforts. 

Goals of Elaboration Phase

- The following are the goals of the elaboration phase:

1. To have a detailed understanding of the key requirements.
2. To mitigate significant risks.
3. To produce accurate schedule and cost estimates.
4. To design, validate and implement the architecture baseline

- The number of iterations in the elaboration phase is not fixed; it varies depending up on the factors such as the maintenance cycle and the green field development. 

Phase 1 of Unified Process Life cycle - Inception

Unified process like any other process has got some phases through which the whole development process takes place. The unified process follows through the following 4 steps:

1. Inception
2. Elaboration
3. Construction and
4. Transition

Throughout this whole article we are going to discuss in detail the first phase of the unified process i.e., the inception phase. So let us a take a deep dive in to the understanding of the first phase “inception” of the project life cycle.

What is an Inception Phase

- The inception phase to say is usually short in most of the development cases but in some rare cases it can be quite lengthy. 

- But in an ideal project it is advisable to keep it short and simple other wise it will be required to divide in to much smaller iterations which in turn will be a complete waste of time.

- Furthermore a lengthy inception phase may indicate that there is an excess of up front specification which is something that is not in accordance with the principles of the unified process. - Every phase of the unified process has some pre defined goals that are needed to be satisfied in that phase itself. 

Goals defined for Inception Phase

- For inception phase the below mentioned goals have been defined:

1. To define and establish a scope for the software project.
2. To establish boundary conditions for the software project.
3. To establish a justification for developing the software system or application.
4. To outline the use cases for driving the design trade offs.
5. To outline the key requirements for the same purpose as the use cases.
6. To outline all the architectures those are to be implemented in the process.
7. To identify the associated risks.
8. To prepare a preliminary project schedule.
9. To estimate the cost of the whole software project.

When all of these mentioned goals are established then the inception phase is said to be concluded and completed. 

In short, what is inception phase is all about?

- The inception phase is all about developing a close enough vision of the software project, defining its scope and making the business case and providing an approximate estimate of the schedule and cost for the whole development project. 

- The inception phase seeks to build concurrence among all the stake holders involved in the development process on the basis of the objectives. 

- In an overall sense, the inception phase determines the feasibility of the solution that has been intended to build the software system or application. 

- In a way it helps the developers to understand what to build and risks associated with the project. - Another advantage is that the key system functionality can be easily recognized. 

- Due to some reasons the developers may be forced to have more than one iterations in the inception phase. 

- The possible reasons can be:

1. The project is so large that it is difficult to define its scope.
2. The system is unprecedented.
3. There are too many stake holders with complex relationships and competing needs.
4. Creation of proof of concept or prototype is required by the major technical risks involved.

- Over the inception phase sometimes counter productive patterns are observed. 

- In such situation a team may postpone providing estimate until the whole domain has been analyzed and documented. 

- But such behavior can lead to a condition called “analysis paralysis”. 

- Even the poor planning of the iterations of the inception phase can make the whole process go awry. 

- This can be avoided only if the iterations have been planned in such a way that they are risk driven and have been integrated and tested earlier. 

What is a Unified Process? What are key characteristics and guidelines for unified process?

If you might have heard even a little about the unified process, you must be having a clue that it has something to do with the development of software system or methodologies. Yes! Certainly it has to do not a little but all with the software development, after all it is one of the most sought after software development frame work.

Well! This article is all about the unified process. Unified process is actually the short name for the USDP or the unified software development process.

What is a Unified Process?

- This software development process has recently emerged as a very popular incremental and iterative software development process frame work. 

- There are some methodologies defined under the category of the unified process and the one that is most commonly implemented and extensively documented is the rational unified process known as RUP in the abbreviated form.

- The concept of the unified process is so very vast that it cannot be merely called as only a process! Rather it can be thought of as an extensible frame work which is customizable according to the needs of the software project or the specific organizations. 

- Concluding from this, the rational unified process can also be called a customizable frame work.  

- However, the name “unified process” is quite opposing to the rational unified process which generally marks the generic processes that include the elements that hold common for most of the refinements. 

- In addition, this name also avoids the potential issues of the trade mark infringement that arise since the unified process and the rational unified process are the trademarks of the IBM. 

- The unified process was first mentioned and described in detail in a book by Ivar Jacobson, James Rumbaugh and Grady Booch called “the unified software development process” in the year of 1999. 

Characteristics of Unified Process

This process is marked by some special characteristics that we have discussed below:

1. Iterative and incremental process: All the 4 phases of the unified process namely:

(a)    Inception

(b)   Elaboration

(c)   Construction and

(d)   Transition have been divided in to a frames or sets of time boxed iterations.

The inception phase is quite large and may be further divided into small iterations for large projects. Increments are the results of the iterations which in turn are responsible for improving the functionality of the software system or application as compared to what it had in the previous release. The emphasis and the effort of the iterations changes in due course during the development process though most of the process disciplines are focused like those mentioned below are focused on requirements, design, implementation and testing.

   2. Use case driven: The whole process is driven by the use cases whose work is to capture functional requirements and the definitions of the content of all the iterations.

    3. Architecture Centric: Architecture lies at the heart of the whole unified process and shapes the development of the whole system. Till now no such model has been developed that will cover all the aspects of the system and so multiple architectural models are implemented.

    4. Risk Focused: The unified process does not leave out any critical risks and they are discovered early in the development cycle.