How to cope with team members (or functional teams) who do not easily follow deadlines / schedules ?

Aah, this is one of the most difficult posts to write, since there is no magic bullet answer. Let me take a situation where you have some team members or functional folks who are not really up to working with schedules, or are disciplined about schedules as the development or testing members of the team. What happens typically ? You have a schedule that has been worked out pretty diligently, that takes into account the work of different team members and functional folks, and gets them all integrated with each other to have a schedule that promises, if you follow the schedule, that you will have your software application ready.
So if everything is going well, if the project management structure of the team is tracking the schedule and the entry and exit of each of the team members as per the schedule, then everything can work out. Further, a lot can be done to help in the process, by setting up systems that provide advance schedule information to the team members, before their tasks are due to start, as well as close to when their tasks are about to end. This can be followed by status meetings and other to ensure that team members have all the information that they need to get their tasks done, and any problems that they are having can be followed up.
However, if everything went so smooth, schedules would always work and there would never be any kind of problems regarding risks, and so on. One of the biggest elements of risks in the entire schedule, just from the scope of delivery from the different functional teams is regarding adherence to the schedule. When you consider the functional requirements of the schedule, you will have requirements and feature details from the product management, followed by elements of design (architectural, workflow and others) from the development and user interface designers, and then the actual development and testing. One of the biggest problems that I have seen is with regard to the more creative elements of this process, namely the user interface designer or the workflow designer. We had an interesting interface designer who would just tell us that to give him a final date by which the entire design would be needed, and not bother about interim dates since that was not the way that he worked. There is some justification, since the user interface designers tend to be creative folks who are not really as bound to a schedule as the rest of the development and testing teams. However, this can screw up the entire schedule, since the assumption is that there are dates by which the designer needs to submit a first draft and there are iterations through which this draft is discussed, and then finally agreement is reached on the final draft to be used for the product development.
So, what do you do ? Well, here are some techniques that we used:
- Ensure that there is ongoing communication with the designer. Typically, it was during a regular phone call that we would find out about some issue that the designer was running into, but which the designer had not told us about via email.
- Remind the designer on a regular basis when the schedule for either the start of the tasks or the end of the tasks was coming up to ensure that this was on the top of the mind
- Add some buffer to the schedule of the user interface designer, and start harassing from the first schedule so that you know that you can expect to get the work by the buffer date

Program Manager - Ensuring that risks are consolidated and controlled

One of the most critical areas of a software development project is about tracking the status of the project, and ensuring that the various risks of the project are controlled. No matter whether somebody says that their work is important, but these are the most critical items of the project. A definition of risks is difficult, but for our purposes, we would take a risk as something that could cause a problem in the project. What are items that could be risks for the project and would need to be controlled:
- Features taking more time than estimated (either because estimation was not correct or because there were problems during implementation).
- There are problems with the defects cycle in the project. This can be such as more defects being generated, defect ageing being a problem, more defects being rejected after fixed, and other issue in the defect cycle that can cause problems in the project execution.
- The team faces resourcing problems - these could be because of attrition, or the adequate number of people not being there in the project, or tensions between team members or other such reasons related to resourcing.
- Components being used in the software application can cause problems because of delivery or quality issues. So a component that is being used in the project is getting delayed which has a dependency problem in the project schedule or there are quality problems in the component that are unexpected.
- There could be a change in the feature requirement during the cycle. Now, such a change is not expected, but it can happen if a competing product comes out with some features that have been welcomed or some surveys come out with a view that the feature mix is not correct. In such cases, it is not wise business wise to continue with business as-is, and so there would be changes needed which will impact the project.
These are some of the key project risks that you would enumerate at the start of the project and then track through the project. But of course, these are only some of the risks that can come up in the course of a project. The beauty (or the horror of a software project) is that any new risk can come up anytime, and the only thing you can do is to figure out why you had not projected the risk at the start of a project, and how to handle it now.
Take an example of a risk that we had not anticipated during the course of the project. We were working on some new features for our project, and the Program Manager (I don't like to use the first person while speaking about responsibilities) had listed down a set of risks based on his experience (and also after discussion with some other senior members of the team) with the objective of tracking these risks and mitigating or handling them as they emerge. However, suddenly a shocker came.
We got a query from our legal contact about some user data collecting code that we were using in one area of our project. We had a component that we were using for data collection, and so it seemed fine since the component had been verified by the legal team in terms of privacy practices. However, our team had gone a bit ahead and used the component to collect some data which was going beyond the privacy criterion. This has gone by for the past 2 versions without any problems, but in a standard review we were doing for some new work, one of the legal team members had a query about what we had done earlier, and that lead to some serious trouble.
We had to redo the work that we had done 2 cycles back, the developer who had lead that particular project had left for another team, and we were already a bit behind in the schedule. These are the kind of ongoing risks that a Program (or Project) Manager need to consolidate and track, ensuring that the required people are aware of these risks, that mitigation strategies are in place and whatever work is needed to be done by the team or by external folks are all either in progress or are just waiting for the necessary confirmations. Without these, a software project would totally go haywire.

How not to put all your eggs in one basket - ensure some amount of knowledge sharing

Every software team has some great engineers, and some not so great ones. Typically, when you are doing a project, you would take your list of features and categorise them into a breakdown of how difficult or how easy they are. Once you have done this, you would get into the process of estimating these tasks and assigning them to different members of the team. One somewhat hidden portion of this entire exercise of estimation and assignment is that you would do the estimation based on a specific person to do the feature (for a more complicated feature, the person who is more skilled would take far less time than the mediocre engineer in your team - and every team has bright people and mediocre people). What this results in is that you have already done some amount of thinking about whom to assign to the more difficult features - typically you would look at the total time available for your skilled people and assign accordingly.
So, you have started the entire exercise of getting the work done, with different parts of the project assigned to different people and are tracking progress of these tasks. This is where I tell my example where some amount of bad planning and some assumptions landed the team in some serious trouble - we had some critical features that were very important for the ongoing version of the product, with marketing depending on these features to be the ones that would get highlighted in reviews, and these were the ones that were pulled up in stakeholder status and review sessions. In fact, part of discussion with stakeholders was about assignment of these features, and once we had presented the assignment of these features to the more skilled engineers, there was approval to proceed.
Now, how many of you have heard of Murphy's Law ? If something can go wrong, it will. And guess what, it did. We were deep into task assignment, and since the engineer doing the most complicated feature was skilled but a bit moody, we had neglected to do periodic sharing of the code and design with a buddy engineer. And of course, we ran into an issue where the engineer ran into some sudden health issues with his daughter, which caused him to take leave for a period of 2 weeks, causing him immense emotional stress. It landed us in a tricky situation. Given that he was already stressed and was already out to take care of his daughter, any kind of information sharing was very difficult. We had permission to drop a couple of features so that we could divert some engineers to this sudden issue, but the information sharing was proving to be a big handicap.
We asked the replacement engineers to study the code intensively, but it did cause us a 6 day delay in delivery of the important features, and also caused a higher number of bugs to turn up since these replacement engineers did not have the same level of familiarity with the code. You would not want to know about the reaction of stakeholders to this delay, especially since these features were critical. And, the biggest problem was that we had a process whereby we used to get engineers to share their current status with their buddy, but for tight-scheduling reasons, we had gone a bit slow on the buddy program; and that was what hit us the most.

What are the risks and liabilities with instant messaging?

There are a number of risks and liabilities associated with Instant Messaging. Till today several attempts have been done in order to create a unified IM standard. 

Few have been mentioned below:

1. Session initiation protocol or SIP of IETF.
2. SIP for instant messaging and presence leveraging extensions or SIMPLE.
3. APEX or application exchange.
4. IMPP or instant messaging and presence protocol.
5. XMPP or open XML – based extensible messaging and presence protocol.
6. Instant messaging and presence service of open mobile alliance (this one was developed exclusively for the mobiles.)

Although a number of benefits are given by instant message, there are also many risks and liabilities associated with it. This happens particularly when one uses IM at his/ her workplace. 

Associated risks and liabilities are:

1. Security risks
2. Inappropriate use
3. Compliance risks
4. Trade secret leakage

About Security Risks

- Security risks involve infecting the systems with viruses, worms, spyware and Trojans etc.

- Hackers and crackers make use of IM vectors for making phishing attempts, introducing the file attachments laden with virus and poisoned URLs. 

- Two main methods are used by the hackers for delivering the malicious code via instant messaging:

1. Delivering viruses, spyware or Trojan horses through an infected file.
2. Using the socially engineered text that has a web address enticing the recipient to go to an URL that in turn connects him/ her to a malicious website.

- The first kind of means i.e., the Trojans, worms and viruses propagate themselves by infecting the whole contact list of the user. 

- An attack done through means of a poisoned URL may infect 1000s of user’s system in a very short duration i.e., just when each of the person in the user’s contact list receives a message that appears to be from a trusted source. 

- Thus, when the recipients click on the web address, the whole cycle repeats. - Such infections might be for some criminal or a nuisance reasons. 

- These attacks are getting more sophisticated with time. 

- The connections in the instant messaging are usually in plain text. 

- This is what that makes them vulnerable to threats such as eavesdropping. 

- Also, with instant messaging, the UDP ports are left exposed to the world inviting many potential security vulnerabilities and raising many security issues.

About Inappropriate Use

 

- All the organizations, be of any type need protection against the liability of the inappropriate use of the IM service by the employees. 

- The nature of the IM, be it immediate, informal or anonymous marks it as an abuse of the workplace. 

- In a number of nations, a legal responsibility has been set up by the corporations in order to make sure that the working environment is free of any harassment for the employees. 

- Instant messaging is now included as an integral part of the policies of the companies regarding the appropriate use of services such as e – mail and world wide web and some other corporate assets.

About Compliance Risks

- Using the IM services at workplace also induces a risk concerning the non – compliance to laws and regulations that govern the use of electric communications. 

- The need for the production of the archived business communications that would satisfy the judicial requests is what to which most of the common regulations is related to. 

- There are a number of IM communications falling under the category of business communications and are retrievable. 

Product / Program Manager - Provides an example of lessons learnt

A project / program manager (from this point on, I will use the term Project Manager only for ease of writing, with the roles being similar in some respects) has many responsibilities as part of a software project, with a full detailing of such responsibilities being much beyond the scope of a single article. This article focuses more on the responsibilities of the project manager being the repository of a lot of experience related to risks ongoing in a project, and the advantages that come from being able to quickly recognize a risk and figuring out how best to alleviate it.
If you are a project manager, you would know this situation to happen often enough. There is a problem that starts to appear in a project, and you are able to draw upon your experience in this project or in similar projects, and as a result, you are able to take on the required actions that would ensure that the risk is contained (or quickly highlighted, if that be the need). Not all risk histories or course of action can be carried in a risk index, and the action that is taken by a project manager is based on his/her own set of thoughts and principles, so there is no one size fits all kind of next steps.
Typically, once you see a situation developing in a project, you will have some idea about whether the situation developing can quickly reach critical size, or is a small enough contained risk that does not need too much attention at this point. For example, I remember a recent case where a component vendor reported some issues in terms of test reports from their end of the component, and there was history already there in the mind of senior team members about a similar case from 2 years back. At that time, a reading of the situation seemed that there was not a problem, and it quickly caught fire until we spent the better part of week dousing the flames, repairing our burnt behinds, and learning from such an experience.
Once we saw the trend of such a situation, we quickly arranged a quick call with the vendor, figured out the problem area, and learnt that the vendor was under-stating the problem. If we had included this new version of the component with our product during the development phase, around 5% of our testing base (including external vendors) would have lost their data. The last time this happened, we had senior management being called in by some of the more irate external testers, and the inclination to minimize the recurrence of this issue was quickly minimized, and we got the situation in control within a short period of time.
Now, this was a problem. Out of the senior members of the team, we had lost 2 out of the 5 members due to attrition, and the new members did not have the history of this situation, and this was not an easy matter to capture in the database that we used to capture risks. We were lucky that we were involved with the same project, and hence knew the history of this problem and were able to quickly devise a solution that would prevent the worst impact of such a problem. This was why I wrote about how having a history of the project can enable quick and correct reactions to problems (there are some problems of course when you have the same person in the same project for a long time). With attrition, some valuable experience can be lost, and can lead to situations where the team has to spend more time reacting to problems that would be clearer with historical backgrounds.

Transition Phase - One of the phase of Rational Unified Process

There are 4 phases which together constitute the rational unified process namely:

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

The above mentioned phases are responsible for the representation of the rational unified process at the highest level in the way which is similar to waterfall model representation but the difference is that the key for the rational unified process lies in the development iterations which form an integral part of all the phases of the rational unified process. 

Also, each of the four phases of the rational unified process are characterized by two things namely the objective and the milestone. The objective drives the whole phase from the beginning to the end and the milestone concludes the end of it. 

The phase is said to be complete with successful result if and only if it passes the milestone since this only marks the conclusion of the phase. All of the phases of the rational unified process are visualized in the form of a chart called the RUP hump chart which is drawn over the course of the whole process. 

In this article we shall discuss exclusively about the fourth phase of the rational unified process i.e., the transition phase. 

Objective of Transition Phase

- The primary objective with which the transition phase is driven is “to transit the software system or application” from the phase of development in to the actual phase of production. 

- This also extends the availability of the software system or application to the end user in such a form that it is understandable by the end user. 

- This phase involves the below mentioned activities:

1. Training the end users
2. Training the maintainers as well.
3. Carrying out beta testing on the software system or application for validating it against the expectations of the end users.
4. Checking the software product against the quality level that was set in the inception phase.

- When all the objectives are said to be accomplished, the software system or application is said to reach the ‘product release milestone’ and the development cycle is said to be concluded.

- This fourth phase of the rational unified process does the fine tuning of the software product.

- It is based on the feedback from the user and the software product is made ready for the release. 

- The transition phase is basically focused on the availability of the software system or application to the end users.

- The transition phase often involves the spanning of the several iterations. 

- The software product is tested in order to prepare it for the release and also minor adjustments are made as per the feedback provided by the end users. 

- When this point in the software development life cycle is reached, it is required that the feedback from the end user should be majorly focused up on the following issues:

1. Fine tuning of the software system or the application.
2. Configuration of the product
3. Installation issues
4. Usability issues

- By this time, almost all the major issues of the product structure should have been worked out in the earlier phases of the software development life cycle. 

- The product release milestone can be defined as a point where it is decided that all the objectives of the project have been met and whether or not another development cycle is required. 

- The basic and majority of the evaluation as well as the refinement of the software system or application is done based up on the feedback from the user.

- This can be considered to be a kind of fine tuning exercise for the software system since the system has already met the requirements of the users as it is driven by the use cases. 

- At the end, a final evaluation is done and accordingly the project is released to the public or is considered for another development cycle. 

Construction Phase - One of the phase of Rational Unified Process

There are 4 phases which together constitute the rational unified process namely:

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

For representing the process at a high level, it is necessary that all of the above mentioned four phases should work together just as it is done for the water fall styled model. But here the key difference is that the primary key to the process is nothing but the development iterations that are involved in each of the development phase. Each of the above mentioned phases is driven by the objective and ended by milestone. The RUP hump chart gives the visualization for all the above 4 phases. 

Here we shall talk about the third phase i.e., the construction phase. 

About Construction Phase of Rational Unified Process

- The construction phase is driven by the primary objective for building the software system or application. 

- The primary focus of the construction phase is taken up by the components development as well as the development of the other features of the software system or application. 

- A bulk of coding is carried out in this phase only. 

- For developing a large project, it is required that several construction iterations are carried out in order to make an effort for dividing the use cases in to the segments that are manageable and that can be used in the production of the demonstrable prototypes. 

- The software version that is released in this phase is its first external release.

- The elaboration phase is concluded with the initial operational capability milestone. 

- The major thing with which the construction phase is concerned is moving the executable architecture that was created in the elaboration phase to the operational system. 

- Therefore, a beta version of the software system or application is ready to be evaluated by the project team. 

- In the elaboration phase the software product resides on the architectural baseline.

- Here, it is moved to a system that is so complete enough that it can make transition to the end users’ community. 

- The architectural baseline is grown enough to become the completed operational system via the refining of the designing in to the code. 

- This phase acquires the largest part of the whole rational unified process. 

- The remaining part of the software system or application is built on the foundation that was laid earlier in the elaboration phase. 

- Short and time boxed iterations help towards the implementation of the features of the system where an executable release of the system or application is released at the end of each iteration. 

- In this phase, writing the full test use cases becomes customary where each one marks the beginning of a new iteration. 

- The elaboration phase makes use of certain UML (unified modelling language) diagrams which are mentioned below:

1. Activity
2. Sequence
3. Collaboration
4. State i.e., transition and
5.  Interaction overview diagrams

- The purpose of the rational unified process is to provide the industry tested practices for the development, implementation and delivery of the software system or application. 

- It also provides a comprehensive frame work for the effective project management. 

- This process is actually one of the many other processes which are contained within the rational process library of the IBM RMC (rational method composer). - This makes it easy to make selection and deploy the only components that you need for your process. 

- The rational unified process is adopted for 1000s of the projects nowadays worldwide. 

- It lessens the burden of inventing a new thing again and again rather it focuses on re-usability. 

Elaboration Phase - One of the phase of Rational Unified Process

The life cycle for a project under the context of the rational unified process is known to consist of the following four phases:

1. Inception phase

2. Elaboration phase

3. Construction phase

4. Transition phase

Here we shall discuss about the second phase of the unified process i.e., the elaboration phase. In Rational Unified Process, the four phases represent the process at a high level although the iterations that are carried out in every phase of development are the key to the process. 

Each phase here is provided with an objective and a milestone. It is necessary to have a milestone for each so that it could be decided that when and where a particular phase is ending and the next one is starting. All the above phases as well as the process disciplines are visualized in to what is called an “RUP hump chart”. 

About Elaboration Phase in Rational Unified Process

- The primary objective of the elaboration phase is defined as the mitigation of the key risk items whose identification is done by the analyzation of the whole phase from the beginning till the end. 

- It is here in the elaboration phase where the project starts taking the shape. - In elaboration the following 2 basic things take place:

1. The analyzation of the problem domain is done.

2. Basic form is given to architecture. 

- The following are the outcomes of the elaboration phase:

1. A use case is obtained in which both the actors and use cases have been identified. This use – model consists of most of the developed use – case descriptions. It is required that this use – case model should be at least 80 percent complete. 

2. A description concerning the architecture of the software system in a development process. 

3. An architecture that is executable and realizes the use cases which have an architectural significance. 

4. A revised risk list.

5. A revised business case.

6. A plan for the overall development of the project. 

7. Prototypes which give a demonstration on the mitigation of the identification of the technical risks. 

8. An optional preliminary user manual.

- There is a milestone criteria called the life cycle architecture milestone which involves answering the following questions:

1. Stability of the architecture?

2. Stability of the vision of the product?

3. Have the major risk elements been addressed and resolved and has been indicated by the executable demonstration?

4. Has the sufficient detailing has been done for the construction phase plan and is it accurate?

5. Have all the stakeholders agreed for achieving the current vision using the current plan under the current architectural context?

6. Is the expenditure of planned resource vs. actual resource acceptable?

- It is important that the project should pass this milestone and if it doesn’t there are 2 possibilities:

1. It can either be redesigned or

2. It can be cancelled.

- However, when the project leaves this phase, the project is transitioned in to an operation that involves high – risk i.e., to say here the changes are quite detrimental as well difficult to be made. 

- The system architecture serves as the key domain analysis for the elaboration phase. 

- The basic thing here is addressing of the major technical risks threatening the project. 

- Another thing is to have a bare system which provides answers to all of the major technical questions. 

- Once all the questions have been answered by the end, the development team will know whether a working system can be successfully built or not. 

Inception Phase - One of the phase of Rational Unified Process

There are 4 phases which together constitute the rational unified process namely:

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

This article is dedicated entirely to the first phase of the unified process i.e., the inception phase. The major development takes place in the iterations of development which are carried out within each phase. All of the above four phases have their unique key objective as well as milestones.

The accomplishment of the objective is denoted by the milestone. An RUP hump chart is used for the visualization of all the four phases of the rational unified disciplines and phases over the time. 

Objective of Inception Phase

- The primary objective of the inception phase provide adequate scope to the software system or application as a basis on which the validation of the budgets and initial costing could be done.

- The inception phase involves the establishment of a business case which is inclusive of the following:

1. Business context
2. Success factors such as the market recognition, expected revenue and so on.
3. Financial forecast

- In order to complement the business case, the following things are generated:

1. A basic use case model
2. Project plan
3. Initial risk assessment
4. Project description which in turn includes the following:

    a)   Key features

    b)   Constraints and

    c)   The core project requirements

- Once the generation of the above mentioned sources is complete, the verification of the project begins against the following criteria:

1. Stake holder concurrence on the following:

  a)   Cost estimates

  b)   Schedule estimates and

  c)   Scope definition

2. Understanding of the requirements as per the evidence obtained by the fidelity of the use cases.
3. Credibility of the following:

  a)   Cost and schedule estimates

  b)   Priorities

  c)   Development process and

  d)   Risks involved

4. The depth and breadth that was developed for any architectural prototype.
5. Establishment of a base line using which the planned expenditures and actual expenditures can be compared.

- If for one or the other reason the project is unable to pass the milestone (commonly termed as the life cycle objective mile stone) then there are only two possibilities after redesigning the program (for meeting the criteria in a better way) as mentioned below:

1. It can be cancelled or
2. It can be repeated

- This phase is involved with launching the project. 

- A proper business case can be developed for the project. 

- It is by the end of the inception that the development team comes to whether to carry on with the project or not. 

- In inception phase, one can see a core idea being developed in to a vision for a product. 

- In this phase may reviews, discussions, etc. are carried out regarding the business case involved in the project. 

- The scope of the project is delimited in the inception phase and also the product feasibility is established. 

- This is perhaps the smallest of all the phases of a project and also according to its ideal nature it should be short. 

- If the duration of the inception phase is too long it indicates that there has been an excessive up – front specification (even though this goes against the spirit of the rational unified process.).

What factors are needed to prioritize themes?

Need of users is considered before planning for a project. To achieve the best combination of product features, schedule, and cost requires deliberate consideration of the cost and value of the user stories and themes.
We need to prioritize and this responsibility is shared among the whole team. Individual user stories or features are aggregated into themes. Stories and themes are then prioritized relative to one another for the purpose of creating a release plan.

There are four primary factors to be considered when prioritizing:
1. The financial value of having the features.
2. The cost of developing new features.
3. The amount and significance of learning and new knowledge created by developing the features.
4. The amount of risk removed by developing features.

1. Determine the Value of Theme
- Estimate the financial impact over a period of time.
- It can be difficult to estimate the financial return on theme.
- It usually involves estimating number of new sales, average value of sales and so on.

2. Determine the Cost of Developing new Features
- Estimating cost of a feature is a huge determinant in overall priority of a feature.
- The best way to reduce the cost of change is to implement a  feature as late as possible.
- The best time to add feature is when there is no more time to change.
- Themes seem worthwhile when viewed in terms of time they will take.
- It is important to keep in mind that time costs money.
- The best way to do this while prioritizing is to do a rough conversion of story points or ideal days into money.

3. Learning New Knowledge
The knowledge that a team develops can be classified in two areas:
Product Knowledge
- It is the knowledge about what will be developed.
- It includes knowledge about features that are included and the features that are not included.
- Better knowledge of product will help the team to make better decisions.

Project Knowledge
- It is the knowledge about how product will be created.
- It includes knowledge about technologies, skills of developers, functioning of team together etc.
- The other side of acquiring knowledge is reducing uncertainty.

4. Risk
- A risk is anything that has not happened yet but might happen. It would threaten or limit the success of the project.
- Types of risks involved in a project are : schedule risk, cost risk and functionality risk.
- Struggle exists between high risk and high-value features of a project.
- Each approach has its drawbacks and the only solution is to give neither risk nor value total supremacy when prioritizing.

All these factors are combined by thinking first of the value and cost of the theme. Doing so will sort the themes into an initial order. Themes can then be moved forward or back in this order based on the other factors.

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.