J. Software Engi neeri n g & Applications, 2010, 3, 933-938
doi:10.4236/jsea.2010.310110 Published Online October 2010 (http://www.SciRP.org/journal/jsea)
933
Software Architecture and Methodology as a Tool
for Efficient Software Engineering Process:
A Critical Appraisal
Achimugu Philip1, Babajide Afolabi2, Oluw aranti Adeniran2, Gambo Ishaya2,
Oluwagbemi Oluwatolani1
1Computer Science Department, Lead City University, Ibadan, Nigeria; 2Department of Computer Science and Engineering, Obafemi
Awolowo University, Ile-Ife, Nigeria.
Received July 10th, 2010; revised August 14th, 2010; accepted August 18th, 2010.
ABSTRACT
The foundation for any software system is its architecture. Software architecture is a view of the system that includes
the system’s major compon ents, the behaviour of those componen ts as visible to the rest of the system, and the ways in
which the components interact and coordinate to achieve the overall system’s goal. Every efficient software system
arises as a result of sound architectural basement. This requires the use of good architecture engineering practices and
methods. This paper recognizes software architecture practice as a discipline pervading all phases of software devel-
opment and also presents an enhanced model for software engineering process which provides an avenue for speedy,
efficient and timely delivery of software products to their intended users. The integration of software architecture into
the phases of software development process in a generic software life cycle is also contained in this research report.
This is to enable software engin eers and system analysts to use effective software architectu re practices and to employ
appropriate methodology during the software engineering process.
Keywords: Software Systems, Architecture, Soft ware Engineering, System Life Cycle, Software Com p onents
1. Introduction
Many people limit the term software engineering to just
computer program. In the real sense of it, it is not just the
program but also the associated documentation and de-
sign principles required to make these programs operate
correctly. Software products may be developed for a par-
ticular customer or for general market, so they undergo
series of thoughts and ideas that account for their initial
inception, development, production, operation, upkeep
and usability from one generation to another [1].
Software engineering process or activities therefore
can be considered as sets of activities and associated re-
sults which produce a software product. They include
software specification, development, validation and evolu-
tion. Software process model represents a networked se-
quence of activities, objects, transformations and events
that embodies strategies for accomplishing software evo-
lution. Different process models organize these activities
in different ways, in different level of details and they are
best suited for different project complexities.
Software architecture and methodology practice has
emerged as a crucial part of the design process and is the
main focus of this paper. Software architecture encom-
passes the structures of large software systems. The ar-
chitectural view of a system is abstract, distilling away
details of implementation, algorithm, and data represen-
tation and concen trating on the behaviour and interaction
of “black box” elements. Software architecture is devel-
oped as the first step toward designing a system that has
a collection of desired properties [2,3] put it very nicely
in this formula (Software architecture = {Elements,
Forms, Rationale/Constraints}).
Software methodology on the other hand, is a pre-defined
sequence of events that must be executed, followed or
carried out in order to produce a well structured and ro-
bust software product that meets user’s requirement and
produce good scalable tendencies.
Therefore, this paper argues that software engineers
who have sound knowledge of software architecture and

Software Architecture and Methodology as a Tool for Ef fi ci ent Software Engineering Process: 934 A Critical Appraisal
appropriate methodology to be employed in software
engineering process will be better informed and hence
produce good quality software and deliver same at the
appropriate time, thus avoiding breach of contract which
is common amongst software engineers.
2. Software Architecture Practice
Today, software architecture practice is one sub-discipline
within software engineering that is concerned with the
high-level (abstract) design of the software of one or
more systems. Software architecture are created, evolved,
and maintained in a complex environment. The architec-
ture business cycle [1] of Figure 1 illustrates this. On the
left hand side, the figure presents different factors that
influence a software architecture through an architect. It
is the responsibility of the architect to manage these fac-
tors and take care of the architecture of the system. An
important factor is formed by requirements, which come
from stakeholders and the developing organization. The
architect also has the capacity of influencing opinions of
stakeholders, refine user’s requirement in a way that it
captures all the activities of an organization as well as
determine the technicalities of the proposed software in
terms of development techniques, architectural consid-
erations, programming language (s) to be used and the
extent of scalability of th e database.
2.1. What is Architectural during Software
Engineering Process?
During software development, what is architectural can
be determined based on what architecture is use for. The
criterion for something to be architectural is this: It must
be a component, or a relationship between components,
or a property (of components or relationships) that needs
to be externally visible in order to reason about the abil-
ity of the system to meet its quality requirements or to
support decomposition of the system into independently
implementable pieces. The following are some corollar-
ies of this principle:
1) Architecture describes what is in your system.
When you have determined your context, you have de-
termined a boundary that describes wh at is in and what is
out of your system (which might be someone else's sub-
system). Architecture describes the part that is in.
2) Architecture is an abstract depiction of your system.
The information in an architecture is the most abstract
and yet meaningful depiction of that aspect of the system.
Given the architectural specification, there should not be
a need for a more abstract description. That is not to say
that all aspects of architecture are abstract, nor is it to say
that there is an abstraction threshold that needs to be ex-
ceeded before a piece of design information can be con-
sidered architectural.
3) What’s architectural should be critical for reason-
ing about critical requirements. The architecture bridges
the gap between requirements and the rest of the design.
If you feel that some information is critical for reasoning
about how your system will meet its requ irements then it
is architectural. You, as the architect, are the best judge.
On the other hand, if you can eliminate some details and
still compose a forceful argument through models, simu-
lation, walk-throughs, and so on about how your archi-
tecture will satisfy key requirements then those details do
not belong. However, if you put too much detail into

Stakeholder
Developing
Countries
Technical
Environment
Requirements
Architect’s
Experience
Architecture
System

Figure 1. The architecture business cycle (Source: Bass et al., 2003).

Software Architecture and Methodology as a Tool for Ef fi ci ent Software Engineering Process: 935
A Critical Appraisal
your architecture then it might not satisfy the next prin-
ciple.
4) An architectu ra l sp ecificatio n n eeds to b e g raspab le.
The whole point of a gross-level system depiction is that
you can understand it and reason about it. Too much de-
tail will defeat this purpose.
5) Architecture is constraining. It imposes require-
ments on all lower-level design specifications. It’s good
to distinguish between when a decision is made and
when it is realized. For example, one can determine a
process prioritization strategy, a component redundancy
strategy, or a set of encapsulation rules when designing
architecture; but might not actually make priority as-
signments, determine the algorithm for a redundant cal-
culation, or specify the details of an interface until much
later.
Generally, what is architectural is the most abstract
depiction of the system that enables reasoning about
critical requirements and constrains all subsequent re-
finements.
2.2. Integrating Software Architecture Practice
into Software Development Process
Software architecture practice can be integrated into all
the phases of software development methodologies and
models [4]. This is used to distinguish it from particular
analysis and design methodologies. Since the architecture
determines the quality of the system, it then makes a lot
of sense to have architectural design built into the soft-
ware development process [5]. As shown in the Figure 2,
software architecture is integrated into all the phases in
development process. The role of software architecture in
each phase of the software development process is estab-
lished. The model shows that during the requirements
phase of development, an architecture may be used to
identify, prioritize, and record system concerns and de-
sires. During design and analysis, an architecture may be
used to model, visualize, and analyze design decisions
chosen to address the principal concerns and achieve the
desired qualities. Decisions may be guided by adopting
one or more architectural styles. During implementation
and testing, an architecture may be used to drive testing,
instantiate a product, support runtime dynamism, or en-
force security policies. Rather than throwing out an ar-
chitecture at this point as is often done, an architecture
remains part of the product. During maintenance, an ar-
chitecture may be used as a basis for incorporating new
features, or increasing modelling detail.
3. Methodology in Software Engineering
Process
Reference [6] defines software development methodol-
ogy as the framework that is used to structure, plan and
control the process of developing a software product or
information systems. A wide variety of such frameworks
has evolved over the years, each with its own recognized
Requirement A nal y sisArchitectural Design
identify, prioritize and
record system concerns and
qualities
Design, analysis
Implement ation, testing
Maintenance
Component1 Component2
Component1 Component2
Architectural Design
Component1 Component2
Architectural Design
Component1 Component2
Architectural Design
Use
Use
Use
Use
model, visualize and
analyze design decisions
drive testing, instantiate a
product, support runtime dynamism,
or enforce security policies
model, visualize and
analyze design decisions
Figure 2. A model integrating architecture into software development process.

Software Architecture and Methodology as a Tool for Ef fi ci ent Software Engineering Process: 936 A Critical Appraisal
strength and weaknesses. One system development
methodology is not necessarily suitable for use by all
projects. Each of the available methodologies is best
suited for specific kinds of projects, based on various
technical, organizational, project and team considerations.
The framework of a software development methodology
consists of:
1) A software development philosophy with the ap-
proach or approaches of the software development proc-
ess.
2) Multiple tools, models and methods, to assist in the
software development process.
These frameworks are often bound to some kind of
organization, which further develops, support the use,
and promotes the methodology. The methodology is of-
ten documented in some kind of formal documentation.
This section therefore presents recommendations of ap-
propriate methodology to be used in the software engi-
neering process. This work is based on the theoretical
study of some existing software process models. These
models were ranke d based on the following feat ures:
1) Ease of use and management
2) Support for small projects
3) Support for complex projects
4) Adequate test plan
5) Suppor t for dynamic user requireme nt
6) Risk analysis
7) Early delivery of project
8) Level of requirements gathered
9) Cost effectiveness
10) Meeting user’s need
11) Activity based
12) Delive rable based
Reference [7] asserts that ease of use and management
implies that each phase of the development process has a
specific deliverable and the documentation of this makes
it easy to manage. Support for project complexities
(small or complex) implies effectiveness of the model
when used for different projects. How and when testing
is done is of great significance in the development proc-
ess of software product. It implies whether it is done at
the beginning, end of development or at end of each
phase. In most cases, user’s requirements are dynamic, so
how well a model adjust to this dynamism is important.
Also [8] argued that the level of user’s requirements
gathered that is, detailed or scanty, at the beginning
phase, plays a great deal in whether the product will
adequately meet user’s needs. A model that adapts well
with changing user requirements tends to meet users
needs better. Cost effectiveness is a relative term when
used in software engineering because there is always a
trade-off between cash and kind implications, so this was
not used to rank the models considered but its importance
was not thrown away. It worth mentioning that these
rankings are based entirely on findings from books and
articles as referenced. The model with the best rank for
each feature considered was adopted to form this optimal
model.
The model that ranks highest is finally adopted for each
feature in our model. Activities that lead to the achieve-
ment of these desired features are identified and the pro-
posed model will emphasize them. This serves as the
bases of the adoption. However, Table 1 shows the
various types of models and when they are best at use.
Table 1. Re-ranking of the models with best rank.
features waterfall incrementalRapid
prototyping v-shape spiral JAD Object process
Ease of use and m anagement Best - - good - - Better
Support for small project Better - - Best - - -
Support for complex project - better good - Better better Best
Test plan - - better Best - good Better
Support for dynamic requirement - Better Better - - good Best
Risk analysis - - - - Best Better -
Early delivery of project - Better Best - - - Good
Level of requirement gathered Better - - good Better Better Best
Cost effective - - - - - - -
Meeting user need - Better Best - - good Better
Activity based Yes - - Yes Yes Yes -
Delivery based - Yes Yes - - - Yes

Software Architecture and Methodology as a Tool for Ef fi ci ent Software Engineering Process: 937
A Critical Appraisal
Interview with software
professionals
Problems
Review of prior
system
Interview with user
Software concept
Goals,
Characteristics
requirements
Risk anal ysis
Alternative
solution
Design
Implementation
Object
model
Test plan
System test
Dynamic
model
Functional
model
Prototype User
Feedback
Iteration
Solution
Bad solution
Figure 3. Enhanced model.

Software Architecture and Methodology as a Tool for Ef fi ci ent Software Engineering Process:
A Critical Appraisal
938
Figure 3 gives a pictorial description of the model.
Basically the model is easy to use and manage because at
the end of each phase, there is a specific deliverable and
a review of the process involved. Also the phases cas-
cade like the waterfall model but to ensure that it is not
as rigid as waterfall model, the phases go back and for-
ward that is, if there is problem in one stage, it docu-
mented and kept for next iteration where the stage will be
revisited. Testing is done early before coding is done and
at the end of each phase, a test plan is created to ensure
quality delivery. It uses concept from object oriented
analysis, design and programming to ensure support for
different project complexities. Reference [9] reviewed
that deliverable at the end of analysis phase is considered
objects with attributes and methods; they also have con-
structors which are methods describing how to create the
deliverable and quality assurance methods. Naturally
user’s requirements are dynamic, the object oriented ap-
proach of this model allows for this to be defined in a
single deliverable called “task context” which can be
modified without affecting the entire production process.
After gathering the user requirement, a process is under-
taken to identify the risk and alternate solutions. A pro-
totype is produced at the end of this phase and this en-
sures that the product is delivered early to the user
though with red u ced fu n ctionalities. Feed back from users
is used to provide a better and user oriented software.
Cost effectiveness can be viewed as optimal cost for op-
timal solution, so this model can be said to be cost effec-
tive.
Clearly seen from the figure, requirements gathered
are expanded into three views; object view represents the
artefacts of the system, dynamic view represents the in-
teraction between objects, and functional view represents
methods of the system. This is the object oriented ap-
proach of the model. The phases cascade and iterate so;
problems found during testing are adequately taken care
of in the next iteration which corresponds to an improved
version of prototype. No throwaway prototype is devel-
oped in this model because of the risk analysis which
gives rise to alternate solutions.
4. Conclusions
System developers and acquirers can use effective soft-
ware architecture practices across the life cycle to ensure
predictable product qualities, cost, and schedule. We
establish in this paper that software architecture is the
bridge between mission/business goals and a software
system. Secondly, software architecture drives software
development throughout the life cycle, and finally the
paper identifies some methodologies that could be em-
ployed during the software engineering process using
some parameters. An enhanced model for software engi-
neering process was also proposed.
REFERENCES
[1] Bass et al., “Software Architecture in Practice,” Addison
Wesley, New York, 2003.
[2] P. Clements, “Predicting Software Quality by Architec-
ture-Level Evaluation,” Proceedings of the Fifth Interna-
tional Conference on Software Quality, Austin, Texas,
October 1995.
[3] D. L. Parnas, “Designing Software for Ease of Extension
and Contraction,” IEEE Transactions on Software Engi-
neering, Vol. 5, No. 2, 1979, pp. 128-138.
[4] B. A. Boehm, “Spiral Models of Software Development
and Enhancement,” Computer, Vol. 20, No. 9, 1987, pp.
61-72.
[5] D. Garlan, “Software Architecture: A Road Map,” Pro-
ceeding of the 16th International Conference on Software
Engineering, Sorrento, Italy, May 2000, pp. 71-80.
[6] M. M. Lehman, “Process Models, Process Programming,
Programming Support,” Proceedings of the 9th Interna-
tional Conference on Software Engineering IEEE Com-
puter Society, Amsterdam, 1987, pp. 14-16.
[7] R. Lewallen, “Software Development Life Cycle Mod-
els,” Net Development, Vol. 20, No. 9, 2006, pp. 61-72.
[8] W. W. Royce, “Managing the Development of Large
Software Systems,” Proceedings of the 9th International
Conference Software Engineering, IEEE Computer Soci-
ety, Amsterdam, 1987, pp. 328-338.
[9] W. Scacchi, “Process Models in Software Engineering,”
Encyclopaedia of Software Engineering, 2nd Edition,
John Wiley and Sons, Inc., New York, 2001.