|
|
|
|
|
|
|
|
|
| Home | Company | Services | Experience | Process | Articles | FAQs | Contact Us |
Development a software system is still a
crafting work - a combination of art and engineering. Based on our observation,
the top three reasons that software projects have failed are lack of
understanding of the requirements, improper architecture and ineffective teamwork.
The most complaints about requirements are
"we don't have any requirements?" and "requirements keep
changing and how can we shoot a moving target?" Unfortunately, that is the
nature of life, if you are a software developer. The main point people miss
here is software is not built against the requirements; it is built against
software vision, the abstraction of requirements. Also see the next question
for our unique way of capturing requirements.
Defining the architecture is definitely the
art part of software development. It is particularly hard to do because it is
usually contradictory with common engineering wisdoms. For example, even though
we can never overstate the importance of teamwork, architecture is better
defined by one person, the architect (or chief architect for large scale
system). That does not mean the architect can dictate the architecture, or work
on the architecture behind the closed door. On the contrary, architect shall
listen to people, and unite the whole team around the architecture. In short
words, architect must be an effective leader.
The ultimate factor that determines the fate of
a software project is the people – who they are and who they work with each
other. The same technology, the same architecture, the same strategy and even
the same process can end up with totally different results. The determining
factor is the people on team.
The three-circle strategy is to deal with the
changing dynamics of software system requirements. It is proved to be very
effective through our years of software development. People usually like to
compare the changing requirements to moving targets; if so, the basic idea of
three-circle strategy is not to shoot the targets, but to cover them. The outermost
circle defines the hard boundary of system capability. Anything outside the
circle won't be supported, either now or in the future. The innermost circle
defines the core capability of the system. Everything inside the circle must be
supported from day one. Usually it is buried in the foggy background and can
expand and shift, and that is why people feel that requirements are so hard to
capture and impossible to cast in stone. The third circle (the middle one) is
bounded by the out circle but fully cover the inner circle. It contains the
features that are absolutely required at now, and likely needed in the future.
The outcome of requirement analysis is to define the middle circle, which then
becomes the basis of building the final system. The middle circle must cover
the inner circle, no matter how the inner circle shifts and reforms. Obviously
the bigger the middle circle, the higher the development cost and system
complexity. Our goal and also our strength are to define the smallest possible
middle circle. So we will ask you not only the features you need, but also the
features you absolutely don't want, or too expensive to build.
We have been working with our customers and
partners on the subject ways of evaluating the quality of software consulting
and developing firms. We are aware of the development and progress of CMM.
However, at this moment, we are not convinced that CMM has solved the
fundamental problem of quality evaluation and can bring the compelling values
to our customers. We are also concerned with the high-cost and overhead
associated with implementing CMM. At the result, we have no intention of
adopting CMM or recommending CMM to our customers.
Copyright © 2002-2004 WISETEL Consulting Inc. All Rights Reserved.