Topics

Overview To top of page

The software-development process is influenced by the following factors:

  • Domain factors, such as application domain, business process to support, user community and offering available from competitors.
  • Lifecycle factors, such as time-to-market, expected life span of the software and planned future releases.
  • Technical factors, such as programming language, development tools, database, components frameworks, and existing software systems.
  • Organizational factors

All these factors are not equally important. The following sections describe some of the main factors - the main discriminants that are likely to affect the overall shape of the development case, and how you implement the process and tools in the development organization.

The Business Context To top of page

There are different types of business contexts that affect how you should configure the process. Examples of business contexts are:

  • Contract work, where the developer produces software to a given customer specification and for this customer only.
  • Speculative or commercial development, where the developer produces on its own funding, software to be put on the market.
  • Internal projects, where customer and developer are in the same organization.

There are many intermediate situations: for example, where only part of the software development is subcontracted, where the geographical dispersion is an additional factor, and so on. The total number of distinct stakeholders is a good indicator.

The business context affects the "level of ceremony", the level of formalism, and the rigidity of the process. The more stakeholders (buyers, customers, subcontractors, regulatory bodies, and so on.) are involved the more likely the project will be required to produce formal evidence (documents, reports, prototypes) at major project milestones.

The Size of the Software Development Effort To top of page

The size of the software development effort as defined by some metrics, such as Source Lines of Code (SLOC), Delivered Source Instructions, or Functions Points, number of person-months, or merely the cost.

The size will also affect the "level of ceremony", the level of formalism, and the rigidity of the process. The larger the project, the larger the development team, and regardless of the business context, the more formalism and visibility the various teams and the management need to have in requirements, interfaces, and progress indicators. Communication issues on large projects are further aggravated by geographically dispersed teams.

The Degree of Novelty To top of page

The degree of novelty is how "precedented" this software effort is, relative to the development organization, and in particular whether the development is in a second or subsequent cycle. This discriminant includes the maturity of the organization and its process, its assets, its current skill set, and issues such as assembling and training a team, acquiring tools, and other resources.

The degree of novelty of a project affects the process in a completely different way. A new project - first of its kind - will significantly affect the dynamic configuration: the inception and elaboration phases will be longer, and may span several iterations. But also more emphasis will be put on requirements elicitation and capture, on use case modeling, on architecture, and on risk mitigation. For a project that is an evolution cycle from a previous system, change management is more crucial. And the incorporation of legacy code poses some technical challenges.

Novelty is not only relative to the system being developed, but also relative to the maturity of the performing organizations; the introduction of new techniques or tools will affect the process. In particular, the introduction of the Rational Unified Process itself to an organization must be phased in careful steps: an organization will present some inertia to the adoption of a new process, and the development case must take into account a smooth transition from the existing practices to new ones.

Type of Application To top of page

There are different types of applications, for example, embedded real-time systems, distributed information systems, telecom systems, case tools, and so on. The type of application will affect the process, especially with respect to specific constraints the domain may impose on the development: safety, performance, internationalization, memory constraints, and so forth.

A specific example of how the type of application may affect the process is if the application is mission-critical, for example the flight-control system in an airplane. A mission-critical system requires a higher level of ceremony in general, both to trace requirements, and to assure the quality of the product. A mission-critical application will also require that more resources are spent on testing.

The type of development, or the target domain will bring in process issues such as:

  • Techniques and tools to support specific activities. For example, automatic code generation for finite-state machines.
  • Certification procedures. For example, for medical instrumentation.
  • Compliance to standards. For example, for accounting or fiscal issues, or for telecommunication equipment.

The Current Development Process To top of page

In most cases you will not replace the software-development process that is currently in practice in the organization. The reason for that is that in most cases you will implement the new development process step-by-step, focusing on some more critical and important areas first. Parts of the current software-development process will, in most cases, continue to exist for some time, maybe forever.

An important aspect of understanding a software-development organization is to understand the problems in the existing software-development process. This will influence which areas of the process you concentrate on in the beginning of the process implementation. The following are some common problems:

  • Inability to manage scope–the organization routinely try to do more than they actually do at the end.
  • Inability to capture requirements–they have difficulty specifying requirements.
  • Inability to manage requirements–requirements do not make it to the final product.
  • Inability to estimate–they are routinely too optimistic about their ability tot deliver to a schedule.
  • Design deficiency–they are good at meeting requirements, but poor at designing systems. What kinds of design problems do they have? Are the systems difficult to maintain and enhance; do they have performance problems, usability problems, capacity problems, etc.?
  • Inability to produce quality products–the product has too many defects; may be due to lack of testing, but usually also related to an inability to capture and manage requirements as well as design deficiency. 

Organizational Factors To top of page

The way you implement the process in an organization depends on organizational factors, such as organizational structure, culture in the project organization and management, competencies and skills available, previous experiences, and attitudes. See the Concepts: Implementing a Process in an Organization, for more details.

The organizational factors also affect how you configure the process. For example, if the people in the organization have been using a software-development process description before, then it will be easier to start using the Rational Unified Process. On the other hand if the people have not used a software-development process description, then you may decide to limit the scope of the process description. You could also put extra effort into making the development case easy to understand and use, making sure that it points to exactly those parts of the Rational Unified Process that will be of great value.

If there are some areas, which are new to many of the people then you probably want to develop as good guidelines as possible to make it easier to work. For example, if the programming language is new to many people, then you want to have very good Programming Guidelines and Design Guidelines, for people to learn.

Technical and Managerial Complexity To top of page

Different types of systems and their projects can be classified in terms of the technical complexity of the system and managerial complexity. The following figure, gives a rough idea of how different systems can be classified. For example, a typical small business spreadsheet application is often of low technical complexity, and easy to manage. The other extreme is a typical weapon system project, which is often both complex technically, and complex to manage.

In general, system size and business context affects the managerial complexity, while novelty, domain, and to a lesser extent size will affect the technical complexity. The increased managerial complexity (linked with project duration) will lead to more ceremony: more formalism and more artifacts. The increased technical complexity will lead to the introduction of specific techniques, roles and tools, and hence more activities.

Systems can classified in terms of technical complexity and managerial complexity.

Display Rational Unified Process using frames

 

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