Guidelines:
Process Discriminants
Topics
The software-development process is influenced by the following factors:
- Domain factors such as application domain, business process to support,
user community, and offerings 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.
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:
- 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 and
covers the cost of putting the software on the market.
- Internal projects where customer and developer are in the same
organization.
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:
- 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, and
for telecommunication equipment.
There are various types of development, such as:
- Contract work where you develop a product for a specific
customer. You have more stakeholders to manage and negotiate with hen you
perform contract work. There is often a need for more formal-external
artifacts (see Guidelines: Classifying Artifacts)
because the customer, or representatives, want to monitor progress and be
kept informed. Make sure that the artifacts the customer reviews are easy to
understand. Sometimes, there's a need to have a milestone where the project
can offer a fixed-price on the rest of the project. In that case, you may
need to add a new milestone or adjust the existing milestones. In other
cases, you may have to adjust to the lifecycle model the customer is using
with other milestones and phases.
- Speculative development where you develop a product for a
mass-market. In speculative development, a marketing (product) manager,
within the organization itself, acts as the customer. Time-to-market is
often more important than the functionality in speculative development and
there is less need for formal reviews.
- Internal development where you develop a product that is
delivered to another department within the company. You may have to adjust
to another lifecycle model if you deliver to another project that does not
use the RUP. It may be acceptable to be more technical
when describing artifacts because most artifacts will be reviewed by peers.
- Pre-studies where you do not normally develop a product.
The purpose of a pre-study project is to find out whether it's possible to
build a product. A pre-study project doesn't have the same milestones as a
regular one.
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. See Concepts: Implementing
a Process in a Project. 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:
- Inability to manage scope—the organization routinely tries to do more
than they actually do in the end.
- Inability to capture requirements—they have difficulty specifying
requirements.
- Inability to manage changing 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 to deliver on schedule.
- Design deficiency—they are good at meeting requirements, yet 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, and so on?
- Inability to produce quality products—the product has too many defects
which may be due to lack of testing, but usually is also related to an
inability to capture and manage requirements, as well as design deficiency.
- Unacceptable software performance.
- Low usability.
- Colliding developers—there is a lack of control over ownership and
configuration management, so that developers make conflicting changes and
work is lost.
- Late discovery of problems.
- Trouble going from use cases to design.
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:
- Insufficient requirements management
- Ambiguous and imprecise communications
- Brittle architectures
- Overwhelming complexity
- Undetected inconsistencies among requirements, designs, and
implementations
- Insufficient testing
- Subjective project status assessment
- Delayed risk reduction due to waterfall development
- Uncontrolled change propagation
- Insufficient automation
- No systematic way to build user interfaces
- No way to go from use cases to a design
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. See Concepts:
Implementing a Process in an Organization for more details.
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:
- What benefits do you see with the new technology? Will the new technology
solve any of today's problems? What problems do you see with the new
technology?
- What benefits do you see with the new process? Will the new process solve
any of today's problems? What problems do you see with the new process?
- What benefits do you see with the new tools? Will the new tools solve any
of today's problems? What problems do you see with the new tools?
To assess people's motivation, find answers to questions like:
- Does everybody in the organization see why change is needed?
- Is everybody aware of what their competition is doing and how that affects
the business?
- Is everybody aware of technology changes in the industry and how they
affect the business?
Signs of a negative attitude may include statements like these:
- "Process doesn't help, it hinders."
- "Process means producing a lot of documents."
- "The process is overwhelming."
Some ways to handle negative attitudes are:
- Motivate people by pointing at today's problems.
- Explain that a process doesn't dictate what you should do. The process
must primarily be looked upon as a "help system", where you look
for guidance, definitions, and so on.
- Explain that you only use small sections of the process. Nobody can master
the entire process, and that is not the purpose. Compare the process to a
bookshelf of books you read as you need their information.
- Run a successful pilot project where you show that the new process and
tools work. Include one or two skeptics in the pilot project.
Signs of over-enthusiasm include these:
- People rely completely on the process and think it will solve all of their
problems.
- Process is the silver bullet or magic formula that, if followed,
will guarantee success.
- The project team wants to spend a lot of time and effort tailoring the
process without first assessing the process-related problems that need
resolution.
Some ways to handle over-enthusiasm are:
- Set expectations. The process will help, but it will not solve the
problems. People solve problems.
- Talk people out of spending a lot of time tailoring the process.
- Focus people on developing the software products.
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:
- Increased managerial complexity that leads to more ceremony, including
more formal reviews and milestones, and more artifacts.
- Increased technical complexity that leads to the introduction of specific
techniques, roles and tools, and, therefore, more activities.
Systems are classified in terms of technical complexity
and managerial complexity
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|
Artifacts >
Environment Artifact Set >
Development Case >
Guidelines >
