|LATEST DEVELOPMENTS AT SITARA|
Risks Involved for a High Maturity Organization to work with a Low Maturity Organization
This paper highlights some of the practical scenarios encountered in having to deal with differing process maturity in interplay. Requirements originated from the lower maturity organization and were often either dictated by the marketing department or were not very stable. Requirements management within the context of the lower maturity organization was always non existent. It was left to the higher maturity organization to document such changes and accordingly set the implementation goals. In such a scenario, the following appears to be the risks involved.
Maturity Model, Configuration Management, Cost Performance Index, Process,
For a high maturity organization to conduct business with a lower maturity organization, the risks involved are enormous. The image of the high maturity organization will be the first at risk for being damaged. Apart from the standards getting diluted in order to accommodate the requirements of the lower maturity organization, quality of the end product will suffer immensely due to time constraints within which the product will have to be developed while accommodating the process overheads. In the paper Software Process Improvement at Hughes Aircraft , Humphrey, Snyder and Willis discuss that productivity and quality increase with reduced risk levels as the maturity level increases from 1 to 5. This assessment however, is highly dependent upon the maturity of clients with whom the organization will interact. Given the fact that, of the 284 assessments performed in 1994, 75% of the assessments indicate level 1 capability, 16% of the assessments indicate level 2 capability and about 8% of the assessments indicate level 3 capability, a good 99% of the assessed software industry is below level 3 maturity . This situation has not changed drastically at the time of this writing in 1999. Even though organizational processes have matured, the operational processes addressing the business needs of an organization are most definitely at a lower maturity because of the scenarios identified in this paper. Process management and adherence to it in this context is not only a matter of a tremendous overhead for a high maturity company but may also be a tremendous risk when it comes to relating its processes with other lower maturity processes. A few scenarios are discussed in what follows.
Changing requirements from the lower maturity organization.
requirements and frequent changes to requirements without a modified
delivery schedule is a very common feature.
Even if this means a lot of extra work for the higher maturity
organization to cope up with, such as, modifying the end of phase
deliverables from all the phases and then having to modify the code, it
might not meet the schedule deadlines.
This is especially so, if the lower maturity organization cannot
make up its mind on whether the change is required or can be postponed for
a future release. Most of
this uncertainty is due to the fact that requirements originate from the
marketing department that has to face a very competitive end user market.
The concept in such a work environment is “if the technology or
the software is late, it need not be there in the first place”.
What is often targeted for is the look and feel of the software in
order to gain a market penetration. So,
a quick and dirty prototype is developed to fulfill this goal and then
software is built using this prototype as reference.
In a mature software development organization where the emphasis is
on end of phase deliverables and making sure that reviews and previews are
effectively conducted, a software development effort involving a quick and
dirty prototype is a potential challenge and a big risk.
Though prototype code is considered to be a throwaway code, if the
prototype is received well by the customer, it becomes the basis for
This risk is further compounded if the lower maturity organization does not keep track of all the changes to requirements it requested. This situation can be alleviated to an extent by the higher maturity organization by periodically updating the lower maturity organization of its changes to the requirements. This is a major overhead for the higher maturity organization because it will have to dedicate personnel to monitor the changes and keep the customer appraised about them. Firstly, it is difficult to find software specialists or software configuration managers who are willing to do such a job and secondly, it requires a software specialist to make these changes to the requirements because the end of phase deliverables from the analysis and design phases require such skills. So, this is the second risk for such projects.
situation can go out of control, if the customer is geographically
separated and does not acknowledge changes to requirements in a timely
fashion. In spite of having a
common development environment and configuration control mechanism, the
situation is bound to deteriorate over time.
This is because code development will require the discipline to
communicate changes on a daily basis for both teams to synchronize.
This might mean that code releases to either side happens on a
daily basis. Finding the
resources to do it effectively is a third risk.
Some of the resources, which are likely to be unavailable on a
consistently reliable basis, are -
With so many changes happening to the hardware and software platforms and vendor support for operating systems changing, there is an organization need to move to newer environments calling for a tremendous amount of latent learning curves. To cite an example, Domain Software Engineering Environment (DSEE) is a configuration management system in the Domain Operating System. With a change in focus of the software industry from this OS, a new configuration management system will have to be instituted which comes with a lot of added learning and idiosyncrasies that requires time to understand.
legacy systems from the lower maturity organization for feature updates
and for future maintenance.
This is by
far the most serious by way of “degree of risk”.
Such legacy systems may not have a great deal of documentation to
support the process that was adopted to develop the code.
It requires highly skilled software specialists from the higher
maturity organization to read the code and understand what is going on.
Often, such an understanding comes after a lot of time is expended.
For the higher maturity organization to get an understanding of how
the feature changes will be handled, it must first do an impact analysis
. This requires a schedule
to be determined after an assessment of the existing legacy system.
The legacy system may have the following risks.
documentation except code.
that is cryptic and is not governed by any coding standards.
enhancements are to be based on software tools that have not stood the
test of time.
In such a
situation, the onus and the consequent risks on the higher maturity
organization are tremendous. The
amount of time expended for creating the deliverables, which will help to
design the enhancements, may be a challenge.
If the design of the older legacy system is arbitrary and defective
with a guiding principle quite different from the best solution, then the
feature enhancements to the software will also be handicapped.
This is a risk that will have to be accepted if the legacy system
has to be reused.
As for point
4, technology transfer and tool induction is very poor in lower maturity
organizations. Tools are
introduced and experimented on live projects based on no evaluation but
purely on individual opinion. Further,
these decisions may become binding on the higher maturity organization to
use on the feature enhancements. If
tool evaluation is not on the higher maturity organization’s project
schedule, it could become a major risk for schedule slippage and
associated costs. Usually,
the capabilities of the tool are superficially understood when they are
recommended and this could be a major risk. In depth understanding of the tool comes with experience with
the tool and not by merely experimenting.
With a lack of tool evaluation capabilities and its subsequent
induction into the organization, a lower maturity organization often
passes the buck to the higher maturity organization to determine its
applicability. This is cause
for a major software risk if the higher maturity organization does not
have the resources at the moment or is pre-occupied with meeting customer
expectations for valid business reasons.
requirements specification due to an uncertain customer.
has begun in the author’s experience wherein the requirements were all
specified which could be said to be correct, complete and consistent. So, to expect a software solution that would have the above
three characteristics besides being testable, verified and validated is a
major target for being prone to risk.
If the cause-effect analysis has to be conducted by the higher
maturity organization to determine whether the incompleteness of the
requirement can be resolved; given the limited resources at the hands of
the higher maturity organization, it could soon turn into a major
technical risk. Often the risk abatement procedure is to ask the customer for
a solution, which could get into a loop.
Management wisdom and technical expertise is always at a premium
and is seldom available when needed.
If this situation has to be mended, a separate group within the two
organizations must evolve alternative solutions in a proactive manner. If the resources to commit to such an activity are not
available, then this lack of resources could be a major risk.
seriousness of this risk can be mellowed to an extent by having a domain
expert or a systems engineer who will be the sole customer point of
contact. The domain expert
from the higher maturity organization must identify a counterpart in the
lower maturity organization and resolve ambiguities and incomplete
requirements. When about 75% of these requirements are stable, it is then
appropriate to begin with the analysis.
Partitioning the unstable requirements and the stable requirements
is a very important first step toward managing the system requirements.
To cite an example, the user interface code in the windowing
environment can be developed independent of the application code if the
user interface specifications are unclear.
It is then, only a matter of designing the application code
“interfaces” with the user interface code.
Testing these two independently before integrating them has the
potential advantage of increasing the quality of the software.
Customer who cares less for the process but is interested only in the final product.
is often interested only in his product.
The customer cares less as to what process the higher maturity
organization is going to adopt as long as it meets the schedules and
customer expectations of the software product.
In such a situation, involving the customer in the reviews and
previews of the end of phase deliverables is a potential problem that
could grow to become a risk if differences of opinion begin to surface in
the coding phase. There is
very little time left to amend the solution and trace these changes back
to the end of phase deliverables of the prior phases.
This situation can soon turn into a chaotic situation.
adherence to the process may be a matter of prime importance to the higher
maturity organization, it must not overlook the importance of creating
defect free software. If a
mature software production process cannot ensure defect free software with
deliverables on schedule, then it is like saying, “the operation was
successful, but the patient died”.
Micro management of the process and the product development effort
by the management is a very useful step to reduce the magnitude of the
believes that a process is applicable only in a stable environment such as
an automobile or a chemical industry but is seldom applicable to software.
It is not
very difficult to relate to this scenario!
The common feeling is that software soon becomes a legacy system,
whether inherited or created by an organization. And the analogous reasoning, which gets a good amount of
consideration, is, “if the input to an automobile manufacturing process
is a totally beaten up machine, then the tinkered product is going to be
as defective as defective software”.
Giving this reasoning some thought, it is quite obvious that, the
creation of software processes just because an automobile manufacturing
industry or a chemical industry has a process, may not be appropriate.
A process in the context of software is to bring or apply a few
controls in an otherwise chaotic situation.
But, the challenges and the risks are an unavoidable outcome of the
very nature of software development activity, it being a creative science
goaded to action by the principle of - “to create a technology which
is new and ahead of its time and every one else”.
This is further complicated by the lack of experienced software
testing capability in the industry. Though
testing is a recognized activity even in a level 2 process, there is a
lack of effective CASE support in this area.
addition from the use of a process comes about only if there is an effort
toward automating the transitions across the more formal phases of the
software development life cycle .
If the use of a process model does not reduce cycle time and
improve quality, then there must be an effort in evaluating the process
transitions with a view to automate as many of these transitions as
possible . To cite an
example, “code standardization” is a very formal transition after
transition can be easily automated in order to improve the virtues of the
baseline code. It introduces
uniformity of appearance to the baseline code with consistency and a
reported cycle time reduction of about 1303X .
solution available for a high maturity organization when faced with the
scenarios discussed in this paper, is to not do business with lower
maturity organization. This
is seldom the best choice considering the very high percentage of the
assessed software projects to be at levels 1 and 2 on the CMM.
There are also valid business reasons to work on projects from
highly time critical, market driven software projects of a low maturity
organization. Most market
driven software development activities will require the organization to
make intelligent initial guesses and informed decisions in the face of
uncertainty. If the initial guesses are quite different from what is
expected, it will also require a lot of rework.
The cost to rework in such a situation cannot be computed before
hand and often the cost-performance index that is defined as the ratio of
budgeted cost of work performed to the actual cost of work performed is
far from the ideal measure of 1.
even if the assessed capability is at a level 5 maturity on the CMM, given
the fabric of the current maturity levels in the software industry, a
level 5 organizations will have operational processes much below a level 5
because of its interactions with lower process maturity levels. The major risk for the higher maturity organization is to
stake its image and its processes in order to stay in business.
organizations that reach higher mature levels have a very important
responsibility to perform. After
reaching say a maturity of level 5 (Optimizing) on the CMM, software
automation along with reuse and external process education should become a
very important organization focus. Hence, these may need to be added as
KPAs to the existing Defect Prevention, Process Change Management and
Technology Change Management Key Process Areas at Level 5.
discusses first hand experience of the author with projects having the
characteristics described in the various scenarios.
The author has intentionally concealed the project details to
maintain confidentiality and proprietary nature of the information and to
focus only on the real issues that can be categorized as risks.
 Watts S.
Humphrey, Terry R. Snyder and Ronald R. Willis, “Software Process
Improvement at Hughes Aircraft”. IEEE Software July 1991.
J., et al., “Results of software process improvement efforts : Work in
progress.”, Proceedings of the 1994 SEPG National Meeting.
Pittsburgh : Software Engineering Institute, Carnegie Mellon
R.S. Nandyal, “An Approach to Rework Projects”, Software
Engineering Symposium, Motorola. Phoenix, Arizona. 1993.
R.S. Nandyal, “Cycle Time Reduction:A Survey of Solutions”,
Software Engineering Symposium, Motorola, Chicago, Illinois.
R.S. Nandyal, “Automation of the product Life Cycle - A Solution
to Cycle Time Reduction”, Software Engineering Symposium, Motorola,
Chicago, Illinois. 1994.
R.S. Nandyal, “Integrated Software Engineering Tool:ISET, Process
Automation Software”, Motorola Tools Fair, Software Engineering
Symposium, Motorola, Chicago, Illinois.
Raghav S. Nandyal is a General Manager
heading Methods, Tools and Products Division for Intelligroup Asia Pvt.
For ease of navigation, use the selection box below ...