|
 It
is essential to plan well before initiating the development process.
Dr R Srinivasan explains why 20 percent of an engineer’s
time should be devoted to planning
In
any branch of engineering design and development, it is absolutely
essential to have a well-laid plan before the actual development
starts. Many experts have insisted that 20 percent of an engineer’s
time should be devoted to planning. Good planning will always lead
to increase in efficiency and hence towards better productivity.
Time management experts teach that a key element in reducing the
stress of a person is through proper planning of activities. Planning
is all the more important in software development.
I
have explained in one of the earlier articles that as soon as the
scope of the project is understood by the software development group,
they should do a thorough analysis of the project, followed by a
good planning on how to execute it. The most important aspect of
the planning stage is to decide the system architecture, which has
been explained in the last article. Unfortunately, in many organisations
least importance is given to software architecture, thereby ending
up with either a system of weak architecture or the absence of documented
specifications. William Brown, et al, mention that it may be due
to the reason that either the manager or the project leader are
over confident that they can decide the architecture and implement
it without any proper documentation. This practice of deciding the
architecture by implementation leads to code writing that will not
commensurate with the architecture and is a typical example of another
antipattern called, ‘Architecture by Implementation’.
 The
manager and members of a software development team should take note
of the architectural aspects in the course of development, such
as, the hardware, communications, handling database, security aspects
in incorporating applications, elements and tools needed as part
of programming and coding, and finally in system management. To
explain this in little more detail, the development team should
take cognisance of the following so that they do not get into the
problem of this antipattern. The software architecture should include
usage of the appropriate language and library, choice of correct
coding standard, module interfaces, test plan, etc.
Under
the communication architecture decision of proper networking protocols,
architectural persistence to include databases and file handling
systems are important points to note. Inadequate and insufficient
details on the above are normally the symptoms leading to Architecture
by Implementation Antipattern. The other factors that lead to this
situation will be detected in the course of project execution. These
risks are hidden due to lack of domain knowledge in the team, absence
of technical backup and contingency plans, misunderstood requirements
and unnecessary complexity introduced in the planning stage. According
to statistics, 30% of projects in software development meet with
problems during development and operations stage due to unresolved
architecture issues and lack of risk management.
The
refactored solution for this antipattern is to adopt a structured
approach to look into the architecture and this is where well-written
documentation is essential, through which it will be possible to
extract the decisions taken on architecture. It is needless to say
that such a document must be easily understood by everybody in the
team. Hillard et al, in their paper, ‘Experiences Applying
a Practical Architectural Method’, bring out nine steps to
define system architecture using viewpoints from the perspective
of every stakeholder in the project.
They
are: 1) Clear definition of the architecture goals explaining what
would be achieved by this architecture, who are the stakeholders.
2) He specifies questions that would answer and satisfy the stakeholders.
3) Decide the views that would represent the blueprint of the architecture
4) Finalise the architecture from each viewpoint. 5) Integrate them
to arrive at the final decision. 6) Validate the architecture with
formal requirements. 7) Review and refine the views if necessary
8) Communicate the finalised architecture to every system stakeholder.
9) Bring out a good documentation of the architecture and upgrade
it, if necessary, after bridging possible gaps between the blueprints
and implementation scheme.
Hillard,
et al, name this as the Goal-Question Architecture (GQA), because
the views of every stakeholder are taken into account in arriving
at the final architecture. While Stovepipe System Antipattern exemplifies
inadequacy of computational architecture, Architecture by Implementation
Antipattern deals with the problem of occurrence of gaps due to
multiple viewpoints in deciding the architecture at the planning
stage of the software project.
(To
be continued) (The author is Chief Technology Officer, iCMG, Bangalore.
He can be contacted at r.srinivasan@icmg.nu)
|
