Purpose
  • To describe the current status of the software organization in terms of its current process, tools, people's competencies, people's attitudes, customers, competitors, technical trends, problems, and improvement areas.
Steps
Input Artifacts:
  • The existing organization
Resulting Artifacts:
Worker: Process Engineer
Guidelines: Process Discriminants

In order to configure a process and create a development case for a specific project, you need to understand the context of the project; that is the current state of the software-development organization in terms of its people, its process, and its supporting tools. To successfully configure the process, it is important to understand the problem areas and potential areas for improvement, as well as information about external issues such as competitors, and trends in the market. When this step is complete, you should know:

  • What is the current state of the software-development organization.
  • What kind of people there are, their levels of competence, skills, and motivation.
  • Which tools are currently used in the organization.
  • What is the current software-engineering process, and how it is described.

The reasons for assessing the current state is so you can:

  • Use the current state as an input when configuring the process.
  • Identify which areas need to be improved first. You may not want to introduce the entire process and all of the tools at once. Instead, you may want to do it in increments, starting with the areas that have the greatest need and the best potential for improvement.
  • Explain to the sponsors why you need to change process, tools, and people.
  • Create motivation and a common understanding among the people in the organization that will be directly or indirectly affected by the changes.

Collect Information To top of page

Analyze the existing organization, process and tools. Interview both managers and people in the organization. Use the following checklists as a guideline. In the Guideline: Process Discriminants, several of the discriminating factors are explained.

The Business Context

  • In which business domain does the organization work? How does the business domain look?
  • Is the business context speculative or commercial? Or is the business context contractual development? Or are the products developed for internal use? 

External factors

  • Customers. What requirements do customers have on the products? For example, in terms of time-to-market, features, security, robustness and safety, and complexity.
  • Competitors. Who are the competitors? In which areas are the competitors strong? What can be learned from competitors?
  • Other stakeholders. Are suppliers and partners involved? Are relationships with them a problem?

Internal factors

  • Development process. What are the characteristics of today's software-development process? How is the process described?  Is there a perception that something is broken? Are project routinely behind schedule or over budget? What problems do they have? Have any metrics been collected that can be analyzed?
  • Supporting tools. What supporting tools do they currently use? What problems are related to the use of tools? In which areas do the developers lack tool support?
  • Internal organization. What roles and teams do they currently have? What is the relationship between development and maintenance? What is the relationship between development and test? What is the scope of the process implementation effort?
  • The competencies, skills and attitudes of individuals. Make an inventory of knowledge and skills. Interview people to understand their attitudes towards the existing organization and their attitudes towards changes.
  • Key persons. Who are the key persons in the organization? It could be important to have their support. Involve them in the process implementation effort.
  • Capacity for change. Analyze the capacity for change in the organization and among individuals. When looking at the organization's problems there is a tendency to try to fix everything at once, especially since many of these problems occur together. This is usually a fatal trap. Organizations, just like individuals can accommodate change but only within a limited range. Different organizations are better prepared for change than others. To understand the organizational capacity for change we recommend that you interview the people in the organization, to understand the attitudes, and willingness to change.

Product characteristics

  • Size of software-development efforts. What is the size of the product?
  • Degree of novelty. Where is the product on a scale between "green-field development" and maintenance?
  • Type of application. Is the application mission-critical? Are there any requirements on following specific standards?
  • Technical complexity. Is the application complex? For example, is the application a distributed system, a safety-critical system, or a high integrity system? Are there any legacy systems that will be reused?

Involve People To top of page

It is best to collect information in small groups. When you begin the assessing activity, it is very important to involve the people who are going to work in the new organization. First, these people know how things work, and they are the best sources of ideas for improvement. Second, they must feel that they are part of the work, because they are going to "own" the new organization.

When you begin the assessment work, there are at least three ways to involve the people who are going to work in the new organization:

  • Make them members of the process-implementation team.
  • Interview them for their ideas and opinions based on their experience.
  • Ask them to review the results.

Draw Conclusions To top of page

Study the results and summarize the most important aspects of the current state. The reason for doing this is to highlight the areas on which you should focus, both in the short term and in the long term.

  • Define the areas where you can make short-term profits. Look at all areas, processes, tools and people.
  • Define major problem areas.
 

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)