Overview > Guidelines > Software Process & LifeCycle: Process Discriminants
The software-development process is influenced by the following factors:
These factors are not equally important. The following sections describe some of the main factors-those most likely to affect the overall shape of the development case, and how you implement the process and tools in the development organization.
There are different types of business contexts that affect how to best configure the process. Examples of business contexts are:
There are many intermediate situations; for example, those where only part of the software development is subcontracted, those where the geographical dispersion is an additional factor, and so on. The total number of distinct stakeholders is a good indicator of the business context.
The business context affects the level of ceremony, the level of formality, and the rigidity of the process. The more stakeholders-buyers, customers, subcontractors, regulatory bodies, and so on-involved, the more likely the project will need to produce formal evidence, such as documents, reports, and prototypes, at major project milestones.
The size of the software development effort as defined by certain metrics such as Source Lines of Code (SLOC), Delivered Source Instructions or Functions Points, number of person-months or merely the cost.
The effort's size will affect the level of ceremony, the level of formality, and the rigidity of the process. The larger the project, the larger the development team and, regardless of the business context, the more formality and visibility the various teams and 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 is based on what has preceded this software effort relative to the development organization and, in particular, whether the development is in a second or subsequent cycle. This 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.
A project's degree of novelty affects the process in a completely different way. A new project-the first of its kind-significantly affects the dynamic configuration: the inception and elaboration phases will be longer, and may span several iterations. Also more emphasis will be put on eliciting and capturing requirements, on use-case modeling, on architecture, and on mitigating risk. For a project that is an evolution cycle from a previous system, change management is more crucial and incorporating legacy code poses some technical challenges.
Novelty is not only relative to the system being developed, it's also relative to the maturity of the performing organizations because introducing new techniques or tools affects the process. In particular, introducing the Rational Unified Process (RUP) 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 existing practices to new ones.
There are different types of applications, for example, embedded real-time systems, distributed information systems, telecom systems, Computer-Aided Software Engineering (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 such as safety, performance, internationalization, memory constraints, and so forth.
The type of application may affect the process 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 also requires that more resources are spent on testing.
The type of development, or the target domain, bring in process issues such as:
There are various types of development, such as:
In most cases, you won't replace the software-development process currently in practice in the organization because, in most cases, you'll implement the new development process step-by-step, focusing on the more critical and important areas first. Some of the current software-development process may even continue to exist for some time, perhaps forever.
An important aspect of understanding a software-development organization is to understand the problems in the existing software-development process. This influences those areas of the process you will concentrate on in the beginning of the process implementation. It's important to note that, if there is no established way of working in the organization, it may be pointless to find problems. Instead, you may need to identify the root causes of the problems. To eliminate the problems, you will tackle the root causes by improving their process, introducing tools to automate the process, and training people.
Examples of common problems
The following are examples of some common problems:
Examples of root causes
A problem is often a symptom that something is wrong. You need to identify the root causes of the problems. The following are examples of some common root causes:
To implement the process in an organization, it depends on organizational factors such as organizational structure, culture in the project's organization and management, competencies and skills available, previous experiences, and current attitudes.
The organizational factors also affect how the process is configured. For example, if the people in the organization have previously been using a software-development process description, then it will be easier to start using the RUP. 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 RUP that will provide the greatest value.
If there are some areas that are new to many of the people, then developing the best guidelines possible will make the transition easier. For example, if the programming language is new to many people, then you'll want to have very good Programming Guidelines and Design Guidelines to assist their learning.
Negative attitudes among an organization's personnel toward changing to a new technology, a new process or new tools is probably the biggest threat toward the successful implementation of process and tools. Over-enthusiasm toward process can also be a problem, because it can cause people to focus too much on the process.
To assess people's attitudes towards the new technology, process, and tools ask questions like:
To assess people's motivation, find answers to questions like:
Signs of a negative attitude may include statements like these:
Some ways to handle negative attitudes are:
Signs of over-enthusiasm include these:
Some ways to handle over-enthusiasm are:
Different types of systems, and their projects, can be classified in terms of the technical complexity of the system and the managerial complexity. The following figure illustrates one concept of how different systems can be classified. For example, a typical small business spreadsheet application is often of low technical complexity and is easy to manage. The other extreme is a typical weapon system project, which is often both technically complex, and complex to manage.
Usually increasing system size, project duration or business context also increases the managerial complexity. Increasing the novelty, in either the problem domain or the solution space, increases the technical complexity. There is an interaction between managerial and technical complexity as well-many large projects are also technically complex. This results in:
Systems are classified in terms of technical complexity
and managerial complexity