Journal of Computer and Communications, 2018, 6, 171-189
ISSN Online: 2327-5227
ISSN Print: 2327-5219
10.4236/jcc.2018.61018 Dec. 29, 2017 171 Journal of Computer and Communications
Software Architectural Design in
Mehdi Mekni, Gayathri Buddhavarapu, Sandeep Chinthapatla, Mounika Gangula
Department of Computer Science and Information Technology, St. Cloud State University, St. Cloud, Minnesota, USA
In this paper, we propose a novel methodology to guide and assist practitio
ers supporting software architecture and design activities in agile enviro
ments. Software architecture and design is the skeleton of a system. It defines
how the system has to behave in terms of different functional and non-func
tional requirements. Currently, a clear specification of software architectural
design activities and processes in agile environments does not exist. Our m
thodology describes in detail the phases in the agile software design process
and proposes techniques and tools to implement these phases.
Agile Methodology, Software Development Life-Cycle,
Software Architectural Design
Software development projects seeking rapid, sustainable delivery are combining
agile and architecture practices to manage competing goals of speed in the short
term and stability over the long term   . A software development life-
cycle is essentially a series of steps, or phases including requirement specifica-
tion; software design; software construction; software verification and validation;
and software deployment. These phases provide a model for the development
and management of software .
Software architectural design is the process of applying various techniques
and principle for the purpose of defining a module, a process, or a system in suf-
ficient detail to permit its physical coding. The conventional approach to the
software design process focuses on partitioning a problem and its solution into
detailed pieces up front before proceeding to the construction phase. These up
How to cite this paper:
Mekni, M., Budd-
., Chinthapatla, S. and Gangu-
, M. (2018)
Software Architectural Design
in Agile Environments
Journal of Co
September 12, 2017
December 26, 2017
December 29, 2017
M. Mekni et al.
10.4236/jcc.2018.61018 172 Journal of Computer and Communications
front software architecture efforts are critical and leave no room to accommo-
date changing requirements later in the development cycle. Some of the issues
faced by organizations involved in up front software design efforts are , :
Requirements evolve over time due to changes in customer and user needs,
technological advancement and schedule constraints.
Changes to requirements systematically involves modifying the software de-
sign, and in turn, the code.
Accommodating changing software design is an expensive critical activity in
the face of rapidly changing requirements.
Clear specification of activities in the agile software design process is missing
and there is a lack of a set of techniques for practitioners to choose from .
There is an obvious need for a software architectural design approach in agile
environments. To the best of our knowledge, no well-established software design
methodology has been proposed in any literature. These are issues of software
architecture while fully supporting the fundamentals of agile software develop-
ment methods. The rest of the paper is organized as follows: Section 2 provides
an overview of existing agile methods. Section 3 details the software architecture
design phase as a key part of the software development life-cycle. Section 4
presents the proposed software architectural design methodology in agile envi-
ronments. Section 5 discusses the outcomes and limits of the proposed metho-
dology. Finally, Section 6 concludes and presents the future perspectives of this
2. Agile Development Methods
The goal of agile methods is to allow an organization to be agile, but what does it
mean to be Agile. Agile means being able to “Deliver quickly”; “Change quickly
and often” .
While agile techniques vary in practices and emphasis, they follow the same
principles behind the agile manifesto :
Working software is delivered frequently (weeks rather than months).
Working software is the principal measure of progress.
Customer satisfaction by rapid, continuous delivery of useful software.
Late changes in software requirements are accepted.
Close daily cooperation between business people and software developers.
Face-to-face conversation is the best form of communication.
Projects are built around motivated individuals who should be trusted.
Continuous attention to technical excellence and good design.
Agile development methods have been designed to solve the problem of deli-
vering high quality software on time under constantly and rapidly changing re-
quirements and business environments. Agile methods have a proven track
record in the software and IT industries. The main benefit of agile development
software is allowing for an adaptive process—in which the team and develop-
ment react to and handle changes in requirements and specifications, even late
M. Mekni et al.
10.4236/jcc.2018.61018 173 Journal of Computer and Communications
in the development process. Figure 1 illustrates an abstract view of the evolu-
tionary map of main agile development methods.
Through the use of multiple working iterations, the implementation of agile
methods allows the creation of quality, functional software with small teams and
The proponents of the traditional development methods criticize the agile
methods for the lightweight documentation and inability to cooperate within the
The main limitations of agile development are: agile works well for small to
medium sized teams; also agile development methods do not scale,
due to the
number of iterations involved it would be difficult to understand the current
project status; in addition, an agile approach requires highly motivated and
skilled individuals which would not always be available; lastly, not enough writ-
ten documentation in agile methods leads to information loss when the code is
actually implemented. However, with proper implementation agile methods can
complement and benefit traditional development methods. Furthermore, it
should be noted that traditional development methods in non-iterative fashions
are susceptible to late stage design breakage, while agile methodologies effec-
tively solve this problem by frequent incremental builds which encourage
changing requirements. We will now describe some common agile methods
from a requirements engineering perspective.
Figure 1. Evolutionary map of agile development methods (adapted from ).
M. Mekni et al.
10.4236/jcc.2018.61018 174 Journal of Computer and Communications
2.1. Agile Modeling (AM)
Agile Modeling is a new approach for performing modeling activities . It
gives developers a guideline of how to build models-using an agile philosophy as
its backbone-that resolve design problems and support documentation purposes
but not “over-build” these models (Figure 2). The aim is to keep the amount of
models and documentation.
2.2. Feature-Driven Development (FDD)
Feature-Driven Development consists of a minimalist, five-step process that fo-
cuses on building and design phases  each defined with entry and exit crite-
ria, building a features list, and then planning-by-feature followed by iterative
design-by-feature and build-by-feature steps. In the first phase, the overall do-
main model is developed by domain experts and developers. The overall model
consists of class diagrams with classes, relationships, methods, and attributes.
The methods express functionality and are the base for building a feature list
(Figure 3). A feature in FDD is a client-valued function. The feature lists is pri-
oritized by the team. The feature list is reviewed by domain members . FDD
proposes a weekly 30-minute meeting in which the status of the features is dis-
cussed and a report about the meeting is written.
Figure 2. Agile modeling .
Figure 3. Feature-driven development .
M. Mekni et al.
10.4236/jcc.2018.61018 175 Journal of Computer and Communications
2.3. Dynamic Systems Development Method (DSDM)
Dynamic Systems Development Method was developed in the U.K. in the
mid-1990s . It is an outgrowth of, and extension to, Rapid Application De-
velopment (RAD) practices . The first two phases of DSDM are the feasibili-
ty study and the business study. During these two phases the base requirements
are elicited (Figure 4). DSDM has nine principles include active user involve-
ment, frequent delivery, team decision making, integrated testing throughout the
project life cycle, and reversible changes in development.
2.4. Extreme Programming (XP)
Extreme Programming is based on values of simplicity, communication, feed-
back, and courage . XP aims at enabling successful software development
despite vague or constantly changing software requirements (Figure 5). XP re-
lies on methods the individual practices are collected and lined up to function
with each other. Some of the main practices of XP are short iterations with small
releases and rapid feedback, close customer participation, constant communica-
tion and coordination, continuous refactoring, continuous integration and test-
ing, and pair programming .
Figure 4. Dynamic systems development method .
Figure 5. Extreme programming .
M. Mekni et al.
10.4236/jcc.2018.61018 176 Journal of Computer and Communications
Scrum is an empirical approach based on flexibility, adaptability and productiv-
ity . Scrum allows developers to choose the specific software development
techniques, methods, and practices for the implementation process. Scrum pro-
vides a project management framework that focuses development into 30-day
sprint cycles in which a specified set of backlog features are delivered. The core
practice in Scrum is the use of daily 15-minute team meetings for coordination
and integration. Scrum has been in use for nearly ten years and has been used to
successfully deliver a wide range of products. Figure 6 details the work-flow of
the Scrum agile software development.
2.6. Crystal Methodology
Crystal Methodology is a family of different approaches from which the appro-
priate methodologies can be chosen for each project . Different members of
the family can be tailored to fit varying circumstances. The members are indexed
by different colors to indicate the “heaviness”: Clear, Yellow, Orange, Red, Ma-
genta, Blue, Violet . Three Crystal methodologies have been used. These are
Clear, Orange, and Orange Web. The difference between Orange and Orange
Web is that Orange Web does not deal with a single project . Crystal in-
cludes different agile methods fitting the needs of teams with different sizes
Figure 6. Scrum agile software development.
Table 1. Crystal family.
Team (number of people)
2 - 6
6 - 20
20 - 40
40 - 80
M. Mekni et al.
10.4236/jcc.2018.61018 177 Journal of Computer and Communications
2.7. Adaptive Software Development (ASD)
Adaptive software development attempts to bring about a new way of seeing
software development in an organization, promoting an adaptive paradigm .
It offers solutions for the development of large and complex systems. The me-
thod encourages incremental and iterative development, with constant proto-
typing. One ancestor of ASD is “RADical Software Development” . ASD
claims to provide a framework with enough guidance to prevent projects from
falling into chaos, while not suppressing emergence and creativity.
2.8. Internet Speed Development (ISD)
Internet-speed development is arguably the least known approach to agile soft-
ware development. ISD refers to a situation where software needs to be released
fast, thereby requiring short development cycles . ISD puts forth a descrip-
tive, management-oriented framework for addressing the problem of handling
fast releases. This framework consists of time drivers, quality dependencies and
3. Software Architecture
Software architecture is a way of thinking about computing systems, for exam-
ple, their configuration and design. By computing systems, we mean the hard-
ware, the software and the communication components . A set of compo-
nents gathered together does not provide us with a problem solution . We
must impose a topology for interaction and communication upon them and en-
sure the components both integrate (physically communicate) as well as intero-
perate (logically communicate) .
3.2. Software Architecture Views
The process of software design and architecture is usually separated into four
views: conceptual, module, execution, and code. This separation is based on our
study of the software architectures of large systems, and on our experience de-
signing and reviewing software architectures . The different views address
different engineering concerns, and separation of such concerns helps the archi-
tect make sound decisions about design trade-offs. The notion of this kind of
separation is not unique: most of the work in software architecture to date either
recognizes different architecture views or focuses on one particular view in order
to explore its distinct characteristics and distinguish it from the others .
The 4 + 1 approach separates architecture into multiple views  . The
work focuses on the conceptual view . Over the years there has
been a great deal of work on the module view . Moreover, other works focus
on the execution view, and in particular explores the dynamic aspects of a sys-
tem . The code view has been explored in the context of configuration man-
agement and system building.
M. Mekni et al.
10.4236/jcc.2018.61018 178 Journal of Computer and Communications
The conceptual view describes the architecture in terms of domain elements.
Here the architect designs the functional features of the system. For example,
one common goal is to organize the architecture so that functional features can
be added, removed, or modified. This is important for evolution, for supporting
a product line, and for reuse across generations of a product.
The module view describes the decomposition of the software and its organi-
zation into layers. An important consideration here is limiting the impact of a
change in external software or hardware. Another consideration is the focusing
of software engineers’ expertise, in order to increase implementation efficiency.
The execution view is the run-time view of the system: it is the mapping of
modules to run-time images, defining the communication among them, and as-
signing them to physical resources. Resource usage and performance are key
concerns in the execution view. Decisions such as whether to use a link library
or a shared library, or whether to use threads or processes are made here, al-
though these decisions may feed back to the module view and require changes
The code view captures how modules and interfaces in the module view are
mapped to source files, and run-time images in the execution view are mapped
to executable files. Some of the views also have a configuration, which constrains
the elements by defining what roles they can play in a particular system. In the
configuration, the architect may want to describe additional attributes or beha-
vior associated with the elements, or to describe the behavior of the configura-
tion as a whole.
3.3. Software Architecture Activities
Software architecture is comprised of a number of specific architecting activities
(covering the entire architectural lifecycle) and a number of general architecting
activities (supporting the specific activities). In the following sections, we pro-
vide a short overview on software architecture activities and processes. The spe-
cific software architecture activities are composed of five items:
Architectural Analysis (AA) defines the problems an architecture must solve.
The outcome of this activity is a set of architecturally significant require-
ments (ASRs) .
Architectural Synthesis (AS) proposes candidate architecture solutions to
address the ASRs collected in AA, thus this activity moves from the problem
to the solution space .
Architectural Evaluation (AE) ensures that the architectural design decisions
made are the right ones, and the candidate architectural solutions proposed
in AS are measured against the ASRs collected in AA .
Architectural Implementation (AI) realizes the architecture by creating a de-
tailed design .
Architectural Maintenance and Evolution (AME) is to change an architecture
for the purpose of fixing faults and architectural evolution is to respond to
new requirements at the architectural level   .
M. Mekni et al.
10.4236/jcc.2018.61018 179 Journal of Computer and Communications
3.4. Software Architecture Processes
An architecture process is composed of the six specific items  :
Architectural Recovery (AR) is used to extract the current architecture of a
system from the system’s implementation .
Architectural Description (ADp) is used to describe the architecture with a
set of architectural elements (e.g., architecture views). This activity can help
stakeholders (e.g., architects) understand the system, and improve the com-
munication and cooperation among stakeholders .
Architectural Understanding (AU) is used to comprehend the architectural
elements (e.g., architectural decisions) and their relationships in an architec-
ture design .
Architectural Impact Analysis (AIA) is used to identify the architectural ele-
ments, which are affected by a change scenario . The analysis results in-
clude the components in architecture that are affected directly, as well as the
indirect effects of changes to the architecture .
Architectural Reuse (ARu) aims at reusing existing architectural design ele-
ments, such as architecture frameworks, decisions, and patterns in the archi-
tecture of a new system .
Architectural Refactoring (ARf) aims at improving the architectural structure
of a system without changing its external behavior  .
4. Software Architectural Design in Agile Environments
The proposed methodology for software architectural design in agile environ-
ments is detailed in Figure 7.
Figure 7. Software design methodology in agile environment.
M. Mekni et al.
10.4236/jcc.2018.61018 180 Journal of Computer and Communications
4.1. Step 1: Definition of Architectural Requirements
Establishing the driving architectural requirements: Driving architectural re-
quirements are obtained by analyzing the business drivers and system context as
well as the issues deemed critical to system success by the product stakeholders.
The goal is a specification for the architecture directing the architects to create a
structure for the system that is sufficient to ensure success in the eyes of the
stakeholders. These requirements prevent creation of an architecture that is
overly complex or that strives for unnecessary elegance at the expense of critical
system properties. The definition of architectural requirements aims to meet the
Describe a necessary change to components in an architecture. This might
mean adding new components, removing outdated ones, replacing or im-
proving components, or changing the way in which they are organized and
how they work together. What is going to change?
Include the reasoning or motivations behind the change. Why does it need to
change? It should explain why the existing components are inadequate, li-
miting or constraining. What problems, issues or concerns are caused by the
Outline the available options for future architectures that address all con-
cerns. How do alternate target architectures eliminate the problems of the
Explain the benefits, value, risks, costs, opportunities, constraints, and future
options associated with each alternative. How do we decide between one al-
ternative and another?
Outline any alternative routes to close the gaps and get from the current to
the target architecture. How do we make the transition or transformation
from what we have got now to what we need in the future?
4.2. Step 2: Identification of Software Architecture Styles
Architectural structures and coordination strategies are developed to satisfy the
driving architectural requirements. Alternative architecture solutions may be
proposed and analyzed to identify an optimal solution for the product or prod-
uct line being developed. When product lines are involved, adaptation of the
product line architecture to specific product requirements or fully develop the
architecture for an individual product. The identification of software architec-
ture styles aims to precise the associated elements, forms, and rationales:
Elements: There are three classes of software elements, namely processing
elements, data elements, and connecting elements. The processing elements
are those components that take some data and apply transformations on
them, and may generate updated or new data. The data elements are those
that contain the information to be used, transformed and manipulated. The
connecting elements bind the architectural description together by providing
communication links between other components. The connecting elements
M. Mekni et al.
10.4236/jcc.2018.61018 181 Journal of Computer and Communications
may themselves be processing or data elements, e.g., procedure calls, shared
data, or messages.
Forms: The architectural form consists of weighted properties and relation-
ships. The definition implies that each component of the architecture would
be characterized by some constraints, generally decided by the architect, and
some kind of relationship with one or more other components. Properties
define the constraints on the software elements to the degree desired by the
Rational: The rationale explains the different architectural decisions and
choices; for example, why a particular architectural style or element or form
was chosen. Rationale is tied to requirements, architectural views and stake-
holders. Probably all choices are governed by what the requirement is. There
are many different external components that have an interest in the system,
and expect different things from the same system. We therefore have to con-
sider the different external demands and expectations that affect and influ-
ence the architecture and its evolution.
4.3. Step 3: Evaluation of Software Architecture
Software architecture evaluation determines when and what methods of archi-
tecture evaluation are appropriate. The results of such evaluation are then ana-
lyzed and measures are determined and applied to improve the developing ar-
chitecture. A formal software architecture evaluation should be a standard part
of our software architecture methodology in agile environments. Software archi-
tecture evaluation is a cost-effective way of mitigating the substantial risks asso-
ciated with this highly important artifact. The achievement of a software sys-
tem’s quality attribute depends much more on the software architecture than on
code-related issues such as language choice, fine-grained design, algorithms, da-
ta structures, testing, and so forth. Most complex software systems are required
to be modifiable and have good performance. They may also need to be secure,
interoperable, portable, and reliable. Several software architecture evaluation
methods exist in literature; Architecture Tradeoff Analysis Method (ATAM)
, Software Architecture Analysis Method (SAAM), Active Reviews for In-
termediate Designs (ARID) .
4.4. Step 4: Determination of Architecture Scope
Before defining an architecture, the developers determine how many of the sys-
tem-design decisions should be established by the architecture of the system.
This scope delimits the activities of application developers, allowing them to
concentrate on what they do best. Software architecture scope is a reflection of
system requirements and trade-offs that made to satisfy them. Possible scope
determination factors include:
Compatibility with legacy software;
M. Mekni et al.
10.4236/jcc.2018.61018 182 Journal of Computer and Communications
Distribution profile (current and future);
Safety, security, fault tolerance, evolvability;
Changes to processing algorithms or data representation;
Modifications to the structure/functionality.
4.5. Step 5: Description of Software Architecture
An architecture must be described in sufficient detail and in an easily accessible
form for developers and other stakeholders. The architecture is one of the major
mechanisms that allow stakeholders to communicate about the properties of a
system. Architecture documentation determines what views of software are use-
ful for the stakeholders, the amount of detail required, and how to present the
information efficiently. Agile methods agree strongly on a central point: “If in-
formation is not needed, do not document it”. All documentation should have
an intended use and audience in mind, and be produced in a way that serves
both. One of the fundamental principles of technical documentation is “Write
for the reader”. Another central idea to remember is that documentation is not a
monolithic activity that holds up all other progress until it is complete. With that
in mind, the following is the suggested approach for describing software archi-
tecture using agile-like principles :
Create a skeleton document (document outline) for a comprehensive
view-based software architecture document using the standard organization
Decide which architectural views should be to produced, given the software
architecture scope (step 4) with respect to available resources;
Annotate each section of the outline with a list of the stakeholders who
should find the information it contains of benefit;
Prioritize the completion of the remaining sections. For example. If a sec-
tion’s constituency includes stakeholders for whom face-to-face conversation
is impractical or impossible (e.g., maintainers in an as-yet-unidentified or-
ganization), that section will need to be filled in. If it includes only such
stakeholders, its completion can be deferred until the conclusion of the soft-
ware architecture and design phase.
4.6. Step 6: Integration of Software Architecture
The software architecture integration process is a set of procedures used to com-
bine software architectural components into larger components, subsystems or
final software architecture . Software architecture integration enables the
organization to observe all important attributes that a software will have; func-
tionality, quality and performance. This is especially true for software systems as
the integration is the first occurrence where the full result of the software devel-
opment effort can be observed. Consequently, the integration activities represent
a highly critical part of the software development process in agile environments.
Usually, Architecture Analysis and Design Language (AADL) are used in order
M. Mekni et al.
10.4236/jcc.2018.61018 183 Journal of Computer and Communications
to build integrated software-reliant systems . The AADL is designed for the
specification, analysis, automated integration and code generation of real-time
performance-critical (timing, safety, fault tolerant, security, etc.) software. It al-
lows analysis of system designs (and system of systems) prior to development
and supports a model-based, model-driven development approach throughout
the software development life cycle. During software architecture integration,
the software architect, checks whether the models provided by the component
developers, system deplorers, and domain experts as well as his or her own
components assembly model are complete. If values are missing, the software
architect estimates them or communicates with the responsible role. The result
of this step (Integration of Software Architecture) is an overall quality-annotated
4.7. Step 7: Continuous Architectural Refinement
Architectural refinement aims to help provide the degree of architectural stabili-
ty required to support the next iterations of development. This stability is par-
ticularly important to the successful operation of multiple parallel Scrum teams.
Making architectural dependencies visible allows them to be managed and for
teams to be aligned with them. The architecture refinement supports the team
decoupling necessary to allow independent decision-making and reduce com-
munication and coordination overhead. During the preparation phase, agile
teams identify an architecture style of infrastructure sufficient to support the
development of features in the near future. Product development using an arc-
hitectural refinement most likely occurs in the preservation phase. Architectural
refinement is one of the key factors to successfully scale agile. Describing and
maintaining (through refinement) software architectural design enables a system
infrastructure sufficient to allow incorporation of near-term high-priority fea-
tures from the product backlog. The proposed software architecture methodol-
ogy in agile environments allows the software architecture and design to support
the features without potentially creating unanticipated rework by destabilizing
refactoring. Larger software systems (and teams) need longer architectural re-
finements. Building and re-architecting software takes longer than a single itera-
tion or release cycle. Delivery of planned functionality is more predictable when
the architecture for the new features is already in place. This requires looking
ahead in the planning process and investing in architecture by including design
work in the present iteration that will support future features and customer
needs. The architectural refinement is not complete. The refinement process in-
tentionally is not complete because of an uncertain future with changing tech-
nology orientations and requirement engineering. This requires continuously
extending the architectural refinement to support the development teams.
Different agile methods cover different phases of the software development
M. Mekni et al.
10.4236/jcc.2018.61018 184 Journal of Computer and Communications
life-cycle. However, none of them covers the software architectural design phase.
Moreover, the rationalization of phases covered was missing. The question
raised is whether an agile method is more profitable to cover more and to be
more extensive, or cover less and to be more precise and specific. On one hand,
some agile methods that cover too much ground,
all organizations, phases
and situations, are too general or shallow to be used. On the other hand, agile
methods that cover too little (e.g., one phase) may be too restricted or lack a
connection to other methods. Completeness, a notion introduced by Kumar and
Welke , requires a method to be complete as opposed to partial. In the final
analysis it was realized “completeness” is an element associated both with vertic-
, level of detail) and horizontal (
, life-cycle coverage) dimensions. None
of the existing agile methods were either extensive or precise. Practitioners and
experts are still struggling with partial solutions to problems that cover a wider
area than agile methods do.
In the following subsections, we discuss the limits and perspectives of the arc-
hitectural refinement process. Finally, we provide an overview on team organi-
zation in agile environment in support of software architecture and design activ-
ities and processes.
Relationship between Software Requirements and Architectural
Activities in Agile Environments
The important feature of agile methods is that they do not assume that there is a
sequential process, where each phase of the software development life-cycle is
expected to be completed before proceeding to the next one, as for example in a
classical waterfall process . Thus it is expected that requirements engineering
or software architecture phases are not happening just once, but they are rather
continuously distributed along the development process. Once there is a first,
usually incomplete, set of requirements available, an architect proceeds to the
architectural design. A tighter integration of requirements engineering and
software architectural activities is suggested in the twin peak process model .
While requirements engineering phases and architectural activities phases alter-
nate in traditional processes, the twin peak model emphasizes that these two ac-
tivities should be executed in parallel to support immediate continuous feedback
from one to another (Figure 8). The goal of this process is that requirement
analysts and software architects better understand problems by being aware of
requirements and their prioritization non one hand and architecture and in par-
ticular architectural constraints on the other hand. Additionally, being able to
quickly switch back and forth between the problem to solve (the requirements)
and its solution (the architecture) can help to more clearly distinguish the two
and to avoid mixing up problem and solution already in the requirements engi-
Team Organization in its simplest instantiation, an agile development envi-
ronment consists of a single collocated, cross-functional team with the skills,
M. Mekni et al.
10.4236/jcc.2018.61018 185 Journal of Computer and Communications
Figure 8. The twin peaks model  showing the interplay of requirements and archi-
authority, and knowledge required to specify requirements and architect, design,
code, and testing of the system. As software grows in size and complexity, the
single-team model may no longer meet development demands.
A number of different strategies can be used to scale up the overall software
development organization while maintaining an agile development approach.
One approach is replication, essentially creating multiple Scrum teams with the
same structure and responsibilities, sufficient to accomplish the required scope
of work. Some organizations scale Scrum through a hybrid approach. The hybrid
approach involves Scrum team replication but also supplements the cross-func-
tional teams with traditional functionally oriented teams.
An example would be using an integration-and-test team to merge and vali-
date code across multiple Scrum teams.
In general, we recognized two criteria used to organize the teams. First orga-
nizing the teams either horizontally or vertically and assigning different teams
the responsibility for either components (horizontal) or features (vertical). The
second is assigning the teams responsibilities according to development phases.
6. Conclusion and Future Works
In this paper, we provided an overview on software architectural design related
issues in agile environments and proposed a methodology to guide and assist
practitioners adopting agile software design in such environments. Our metho-
dology relies on seven processes namely: 1) Definition of architectural require-
ments; 2) Identification of software architectural styles; 3) Evaluation of software
architecture; 4) Determination of architecture scope; 5) Description of software
architecture; 6) Integration of software architecture; and 7) Architectural re-
Agile software development methods have evoked a substantial amount of li-
terature and debates. However, academic research on the subject is still scarce, as
most existing publications are written by practitioners or consultants. Yet, many
organizations are considering future use or have already applied practices that
M. Mekni et al.
10.4236/jcc.2018.61018 186 Journal of Computer and Communications
are claiming successes in performing and delivering software in a more agile
To conclude, we observed that agile methods, without rationalization only
cover certain phases of the life-cycle. A majority of them did not provide true
support for software architectural design for project management. While uni-
versal solutions have strong support in the respective literature, empirical evi-
dence on their adaptation and use in agile environments is currently very li-
This research project has been partially funded by the professional developmen-
tal fund provided by St. Cloud State University. The author would like to thank
faculty from Department of Computer Science and Information Technology for
their valuable comments and continuous support.
 Buchmann, F., Nord, R.L. and Ozakaya, I. (2012) Architectural Tactics to Support
Rapid and Agile Stability. Technical Report, DTIC Document.
 Floyd, C. (1992) Software Development as Reality Construction. In:
velopment and Reality Construction
, Springer, 86-100.
 Nuseibeh, B. (2001) Weaving Together Requirements and Architectures.
34, 115-119. https://doi.org/10.1109/2.910904
 Edeki, C. (2015) Agile Software Development Methodology.
European Journal of
Mathematics and Computer Science
 Choudhary, B. and Rakesh, S.K. (2016) An Approach Using Agile Method for Soft-
ware Development. 2016
International Conference on Innovation and Challenges in
 Sommerville, I. (1996) Software Process Models.
ACM Computing Surveys
28, 269-271. https://doi.org/10.1145/234313.234420
 Babar, M.A., Brown, A.W. and Mistrík, I. (2013) Agile Software Architecture:
Aligning Agile Processes and Software Architectures. Newnes.
 Feiler, P. (2013) Architecture Analysis and Design Language (AADL) Annex Vo-
lume 3: Annex e: Error Model v2 Annex. Number SAE AS5506/3 (Draft) in SAE
Aerospace Standard. SAE International.
 Magee, J. and Kramer, J. (1996) Dynamic Structure in Software Architectures.
SIGSOFT Software Engineering Notes
, 21, 3-14.
 Awan, R., Muhammad, S., Fahiem, M. and Awan, S. (2016) A Hybrid Software Ar-
chitecture Evaluation Method for Dynamic System Development Method.
 Postma, A., America, P. and Wijnstra, J.G. (2004) Component Replacement in a
Long-Living Architecture: The 3rdba Approach.
Proceedings. Fourth Working
IEEE/IFIP Conference on Software Architecture
, June 2004, 89-98.
M. Mekni et al.
10.4236/jcc.2018.61018 187 Journal of Computer and Communications
 Martini, A., Pareto, L. and Bosch, J. (2012) Enablers and Inhibitors for Speed with
. Proceedings of the
th International Software Product Line Conference
 Clements, P., Ivers, J., Little, R., Nord, R. and Stafford, J. (2003) Documenting Soft-
ware Architectures in an Agile World. Technical Report, DTIC Document.
 Babar, M.A., Zhu, L. and Jeffery, R. (2004) A Framework for Classifying and Com-
paring Software Architecture Evaluation Methods.
Proceedings of Australian Soft-
ware Engineering Conference
 Lata, P. (2016) Agile Software Development Methods.
International Journal of
 Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lipson, H. and Carriere, J. (1998)
The Architecture Tradeoff Analysis Method.
Fourth IEEE International Conference
on Engineering of Complex Computer Systems
 Ambler, S.W. (2001) Agile Requirements Modeling. The Official Agile Modeling
 Clements, P., Garlan, D., Bass, L., Stafford, J., Nord, R., Ivers, J. and Little, R. (2002)
Documenting Software Architectures: Views and Beyond. Pearson Education.
 Singh, S., Chaurasia, M. and Gaikwad, M.H. (2016) Importance of 4 + 1 Views
Model in Soft-Ware Architecture.
Imperial Journal of Interdisciplinary Research
 Jaafar, N.H., Rahman, M.A. and Mokhtar, R. (2016) Adapting the Extreme Pro-
gramming Approach in Developing E-Corrective and Preventive Actions: An Expe-
Regional Conference on Science, Technology and Social Sciences
 Hofmeister, C., Kruchten, P., Nord, R.L., Obbink, H., Ran, A. and America, P.
(2007) A General Model of Software Architecture Design Derived from Five Indus-
Journal of Systems and Software
, 80, 106-126.
 Bellomo, S., Nord, R.L. and Ozkaya, I. (2013) A Study of Enabling Factors for Rapid
Fielding Combined Practices to Balance Speed and Stability. 3
Conference on Software Engineering
 Bengtsson, P., Lassing, N., Bosch, J. and van Vliet, H. (2004) Architecture-Level
Modifiability Analysis (ALMA).
Journal of Systems and Software
 Kruchten, P. (1995) The 4 + 1 View Model of Architecture.
 Herzog, J. (2015) Software Architecture in Practice Third Edition Written by Len
Bass, Paul Clements, Rick Kazman.
ACM SIGSOFT Software Engineering Notes
40, 51-52. https://doi.org/10.1145/2693208.2693252
 Lange, B., Flynn, S., Proffitt, R., Chang, C.-Y.,
(2015) Development of an In-
teractive Game-Based Rehabilitation Tool for Dynamic Balance Training. Topics in
 Tang, A., Avgeriou, P., Jansen, A., Capilla, R. and Babar, M.A. (2010) A Compara-
tive Study of Architecture Knowledge Management Tools.
Journal of Systems and
, 83, 352-370. https://doi.org/10.1016/j.jss.2009.08.032
 Dingsøyr, T. and Lassenius, C. (2016) Emerging Themes in Agile Software Devel-
opment: Introduction to the Special Section on Continuous Value Delivery.
M. Mekni et al.
10.4236/jcc.2018.61018 188 Journal of Computer and Communications
mation and Software Technology
, 77, 56-60.
 Erickson, J., Lyytinen, K. and Siau, K. (2005) Agile Modeling, Agile Software De-
velopment, and Extreme Programming: The State of Research.
Journal of Database
, 16, 88. https://doi.org/10.4018/jdm.2005100105
 Malavolta, I., Lago, P., Muccini, H., Pelliccione, P. and Tang, A. (2013) What In-
dustry Needs from Architectural Languages: A Survey.
IEEE Trans. Softw. Eng.
 Kaisler, S.H. (2005) Software Paradigms. John Wiley & Sons.
 Yang, C., Liang, P. and Avgeriou, P. (2016) A Systematic Mapping Study on the
Combination of Software Architecture and Agile Development.
Journal of Systems
, 111, 184. https://doi.org/10.1016/j.jss.2015.09.028
 IEEE Standard for Information Technology-System and Software Life Cycle
Processes-Reuse Processes (2010) IEEE Std 1517-2010 (Revision of IEEE Std
 Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J. (2002) Agile Software De-
velopment Methods: Review and Analysis.
 Ramesh, B., Cao, L. and Baskerville, R. (2010) Agile Requirements Engineering
Practices and Challenges: An Empirical Study.
Information Systems Journal
 Nierstrasz, O. and Kurš, J. (2015) Parsing for Agile Modeling.
Science of Computer
, 97, 150-156. https://doi.org/10.1016/j.scico.2013.11.011
 Li, Z., Liang, P. and Avgeriou, P. (2013) Application of Knowledge-Based Ap-
proaches in Soft-Ware Architecture: A Systematic Mapping Study
. Information and
, 55, 777-794. https://doi.org/10.1016/j.infsof.2012.11.005
 Mahdavi-Hezave, R. and Ramsin, R. (2015) Fdmd: Feature-Driven Methodology
International Conference on, Evaluation of Novel Approaches to
), 2015, 229-237.
 Cej, A. (2010) Agile Software Development with Scrum.
 Abrahamsson, P., Warsta, J., Siponen, M.T. and Ronkainen, J. (2003) New Direc-
tions on Agile Methods: A Comparative Analysis.
th International Conference on
 Baskerville, R., Ramesh, B., Levine, L., Pries-Heje, J. and Slaughter, S. (2003) Is In-
ternet-Speed Software Development Different?
, 20, 70.
 Kumar, K. and Welke, R.J. (1992) Methodology Engineering R: A Proposal for Situ-
ation-Specific Methodology Construction. In:
Challenges and Strategies for Re-
search in Systems Development
, John Wiley & Sons, Inc., 257-269.
 Bass, L., Clements, P. and Kazman, R. (2012) Software Architecture in Practice. 3rd
Edition, Addison-Wesley Professional.
 Ducasse, S. and Pollet, D. (2009) Software Architecture Reconstruction: A Process-
IEEE Transactions on Software Engineering
, 35, 573-591.
 Highsmith, J. (2013) Adaptive Software Development: A Collaborative Approach to
Managing Complex Systems. Addison-Wesley.
M. Mekni et al.
10.4236/jcc.2018.61018 189 Journal of Computer and Communications
 Larsson, S. (2007) Key Elements of Software Product Integration Processes.
 Tekinerdogan, B. (2004) Asaam: Aspectual Software Architecture Analysis Method.
Fourth Working IEEE/IFIP Conference on Software Architecture
 Qian, K., Fu, X., Tao, L., Xu, C.-W. and Diaz-Herrera, J. (2009) Software Architec-
ture and Design Illuminated. Jones and Bartlett Publishers, Inc., USA.