alexa Software Architecture Methodology in Agile Environments | Open Access Journals
ISSN: 2165- 7866
Journal of Information Technology & Software Engineering
Make the best use of Scientific Research and information from our 700+ peer reviewed, Open Access Journals that operates with the help of 50,000+ Editorial Board Members and esteemed reviewers and 1000+ Scientific associations in Medical, Clinical, Pharmaceutical, Engineering, Technology and Management Fields.
Meet Inspiring Speakers and Experts at our 3000+ Global Conferenceseries Events with over 600+ Conferences, 1200+ Symposiums and 1200+ Workshops on
Medical, Pharma, Engineering, Science, Technology and Business

Software Architecture Methodology in Agile Environments

Mehdi Mekni*, Mounika G, Sandeep C and Gayathri B

Department of Computer Science and Information Technology, St. Cloud State University, St. Cloud, Minnesota, USA

*Corresponding Author:
Mehdi Mekni
Department of Computer Science and Information Technology
St. Cloud State University, St. Cloud
Minnesota, USA
Tel: 612-666-8767
E-mail: mmekni@stcloudstate.edu

Received Date: January 12, 2017; Accepted Date: January 17, 2017; Published Date: January 23, 2017

Citation: Mekni M, Mounika G, Sandeep C, Gayathri B (2017) Software Architecture Methodology in Agile Environments. J Inform Tech Softw Eng 7: 195. doi: 10.4172/2165-7866.1000195

Copyright: © 2017 Mekni M, et al. This is an open-access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.

Visit for more related articles at Journal of Information Technology & Software Engineering

Abstract

Lengthy requirements, design, integration, test, and assurance cycles delay software delivery, resulting in late discovery of mismatched assumptions and system level rework. In response, development methods that enable frequent iterations with small increments of functionality, such as agile practices, have become popular. However, since the business goals and context continuously evolve, the software architecture must also change. Currently, a clear specification in software architecture activities and processes in agile environments does not exist. In this paper, we provide an overview on agile development methodology along with the software architecture related issues in agile environments. Our main contribution is a novel methodology to guide and assist practitioners adopting software architectural design in agile environments.

Keywords

Agile methodology; Software development life-cycle; Software architectural design

Introduction

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 [1-3]. A software development lifecycle is essentially a series of steps, or phases including requirement specification; software design; software construction; software verification and validation; and software deployment. These phases provide a model for the development and management of software [4].

Software architectural design is the process of applying various techniques and principles for the purpose of defining a module, a process, or a system in sufficient 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 front software architecture efforts are critical and leave no room to accommodate changing requirements later in the development cycle. Some of the issues faced by organizations involved in up front software design efforts are [5,6]:

• 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 design, 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 [7].

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 development 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 environments. Section 5 discusses the outcomes and limits of the proposed methodology. Finally, Section 6 concludes and presents the future perspectives of this work.

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” [8]. While agile techniques vary in practices and emphasis, they follow the same principles behind the agile manifesto [9]:

• 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 delivering high quality software on time under constantly and rapidly changing requirements 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 development react to and handle changes in requirements and specifications, even late in the development process. Figure 1 illustrates an abstract view of the evolutionary map of main agile development methods.

information-technology-software-engineering-development

Figure 1: Evolutionary map of agile development methods (adapted from [18]).

Through the use of multiple working iterations, the implementation of agile methods allows the creation of quality, functional software with small teams and limited resources. The proponents of the traditional development methods criticize the agile methods for the lightweight documentation and inability to cooperate within the traditional workflow. The main limitations of agile development are: agile works well for small to medium sized teams; also agile development methods do not scale, i.e., 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 written 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 effectively solve this problem by frequent incremental builds which encourage changing requirements. We will now describe some common agile methods from a requirements engineering perspective.

Agile modeling (AM)

It is a new approach for performing modeling activities [10]. 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 as low as possible.

information-technology-software-engineering-modeling

Figure 2: Agile modeling [10].

Feature-driven development (FDD)

It consists of a minimalist, five step processes that focuses on building and design phases each defined with entry and exit criteria, building a features list, and then planning by feature followed by iterative design by feature and build by feature steps [11]. In the first phase, the overall domain 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 prioritized by the team. The feature lists are reviewed by domain members [12]. FDD proposes a weekly 30 minute meeting in which the status of the features are discussed and a report about the meeting is written.

information-technology-software-engineering-driven

Figure 3: Feature-driven development [12].

Dynamic systems development method (DSDM)

It was developed in the U.K. in the mid-1990s [13]. It is an outgrowth of, and extension to, Rapid Application Development (RAD) practices [14]. The first two phases of DSDM are the feasibility study and the business study. During these two phases the base requirements are elicited (Figure 4). DSDM has nine principles include active user involvement, frequent delivery, team decision making, integrated testing throughout the project life cycle, and reversible changes in development.

information-technology-software-engineering-method

Figure 4: Dynamic systems development method [14].

Extreme programming (XP)

It is based on values of simplicity, communication, feedback, and courage [15]. XP aims at enabling successful software development despite vague or constantly changing software requirements (Figure 5). XP relies 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 communication and coordination, continuous refactoring, continuous integration and testing, and pair programming [16].

information-technology-software-engineering-programming

Figure 5: Extreme programming [16].

Scrum

Scrum is an empirical approach based on flexibility, adaptability and productivity [17]. Scrum allows developers to choose the specific software development techniques, methods, and practices for the implementation process. Scrum provides 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 workflow of the Scrum agile software development.

information-technology-software-engineering-software

Figure 6: Scrum agile software development.

Crystal methodology

It is a family of different approaches from which the appropriate methodologies can be chosen for each project [18]. 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, Magenta, Blue and Violet [19]. 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 [18]. Crystal includes different agile methods fitting the needs of teams with different sizes (Figure 7).

information-technology-software-engineering-family

Figure 7: Crystal family.

Adaptive software

This development attempts to bring about a new way of seeing software development in an organization, promoting an adaptive paradigm [20]. It offers solutions for the development of large and complex systems. The method encourages incremental and iterative development, with constant prototyping. One ancestor of ASD is “Radical Software Development” [21]. ASD claims to provide a framework with enough guidance to prevent projects from falling into chaos, while not suppressing emergence and creativity.

Internet-speed development (ISD)

It is arguably the least known approach to agile software development. ISD refers to a situation where software needs to be released fast, thereby requiring short development cycles [22]. ISD puts forth a descriptive, management oriented framework for addressing the problem of handling fast releases. This framework consists of time drivers, quality dependencies and process adjustments.

Software Architecture

Definition

Software architecture is a way of thinking about computing systems, for example, their configuration and design. By computing systems, we mean the hardware, the software and the communication components [6]. A set of components gathered together does not provide us with a problem solution [23]. We must impose a topology for interaction and communication upon them and ensure the components both integrate (physically communicate) as well as interoperate (logically communicate) [24].

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 designing and reviewing software architectures [25]. The different views address different engineering concerns, and separation of such concerns helps the architect make sound decisions about design tradeoffs. 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 [23]. The 4+1 approach separates architecture into multiple views [26,27]. The Garlen et al. work focuses on the conceptual view [28]. Over the years there has been a great deal of work on the module view [29].

Moreover, other works focus on the execution view, and in particular explores the dynamic aspects of a system [30]. The code view has been explored in the context of configuration management and system building.

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 organization 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 assigning 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, although these decisions may feed back to the module view and require changes there. 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 behavior associated with the elements, or to describe the behavior of the configuration as a whole.

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) [31]. In the following sections, we provide a short overview on software architecture activities and processes.

The specific 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 requirements (ASRs) [32].

• 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 [32].

• 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 [32].

• Architectural Implementation (AI) realizes the architecture by creating a detailed design [33].

• 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 [34-36].

Software architecture processes

An architecture process is composed of the six specific items [32,33]:

• Architectural Recovery (AR) is used to extract the current architecture of a system from the system’s implementation [37].

• 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 communication and cooperation among stakeholders [35].

• Architectural Understanding (AU) is used to comprehend the architectural elements (e.g., architectural decisions) and their relationships in an architecture design [38].

• Architectural Impact Analysis (AIA) is used to identify the architectural elements, which are affected by a change scenario [39]. The analysis results include the components in architecture that are affected directly, as well as the indirect effects of changes to the architecture [39].

• Architectural Reuse (ARu) aims at reusing existing architectural design elements, such as architecture frameworks, decisions, and patterns in the architecture of a new system [40].

• Architectural Refactoring (ARf) aims at improving the architectural structure of a system without changing its external behavior [38,41].

Software Design in Agile Environment

The proposed methodology for software architectural design in agile environments is detailed in Figure 8.

information-technology-software-engineering-design

Figure 8: Software design methodology in agile environment.

Step 1: definition of architectural requirements

Establishing the driving architectural requirements: Driving architectural requirements 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 following goals:

• Describe a necessary change to components in an architecture. This might mean adding new components, removing outdated ones, replacing or improving 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, limiting or constraining. What problems, issues or concerns are caused by the current architecture?

• Outline the available options for future architectures that address all concerns. How do alternate target architectures eliminate the problems of the current architecture?

• Explain the benefits, value, risks, costs, opportunities, constraints, and future options associated with each alternative. How do we decide between one alternative 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?

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 product line being developed. When product lines are involved, SEI architects also help customer staff adapt the product line architecture to specific product requirements and fully develop the architecture for an individual product. The identification of software architecture 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 may themselves be processing or data elements, e.g., procedure calls, shared data, or messages.

Forms: The architectural form consists of weighted properties and relationships. 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 architect.

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 stakeholders. 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 consider the different external demands and expectations that affect and influence the architecture and its evolution.

Step 3: evaluation of software architecture

Software architecture evaluation determines when and what methods of architecture evaluation are appropriate. The results of such evaluation are then analyzed and measures are determined and applied to improve the developing architecture.

A formal software architecture evaluation should be a standard part of our software architecture methodology in agile environments. Software architecture evaluation is a cost effective way of mitigating the substantial risks associated with this highly important artifact. The achievement of a software system’s quality attributes depends much more on the software architecture than on code related issues such as language choice, fine grained design, algorithms, data 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) [42], Software Architecture Analysis Method (SAAM) [43], Active Reviews for Intermediate Designs (ARID) [44].

Step 4: determination of architecture scope

Before defining an architecture, the developers determine how many of the system 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 tradeoffs that made to satisfy them. Possible scope determination factors include:

• Performance

• Compatibility with legacy software

• Software reuse

• Distribution profile (current and future)

• Safety, security, fault tolerance, evolvability

• Changes to processing algorithms or data representation

• Modifications to the structure/functionality

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 stake holders to communicate about the properties of a system. Architecture documentation determines what views of software are useful for the stakeholders, the amount of detail required, and how to present the information efficiently.

Agile methods agree strongly on a central point: “If information 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 architecture using agile like principles [45]:

• Create a skeleton document (document outline) for a comprehensive view based software architecture document using the standard organization schemes;

• 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 stake holders who should find the information it contains of benefit.

• Prioritize the completion of the remaining sections. For example: if a section’s constituency includes stakeholders for whom face-toface conversation is impractical or impossible (e.g., maintainers in an as yet unidentified organization), that section will need to be filled in. If it includes only such stakeholders, its completion can be deferred until the conclusion of the software architecture and design phase.

Step 6: integration of software architecture

The software architecture integration process is a set of procedures used to combine software architectural components into larger components, subsystems or final software architecture [46]. Software architecture integration enables the organization to observe all important attributes that a software will have; functionality, quality and performance. This is especially true for software systems as the integration is the first occurrence where the full result of the software development 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 to build integrated software reliant systems [47]. 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 allows 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 deployers, 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 model.

Step 7: continuous architectural refinement

Architectural refinement aims to help provide the degree of architectural stability required to support the next iterations of development. This stability is particularly 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 communication 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 architectural 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 features from the product backlog. The proposed software architecture methodology 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 refinements. Building and rearchitecting software takes longer than a single iteration 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 intentionally is not complete because of an uncertain future with changing technology orientations and requirements engineering. This requires continuously extending the architectural refinement to support the development teams.

Discussion

Different agile methods cover different phases of the software development lifecycle. However, none of them cover 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, i.e., 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 [48], requires a method to be complete as opposed to partial. In the final analysis it was realized “completeness” is an element associated both with vertical (i.e., level of detail) and horizontal (i.e., lifecycle coverage) dimensions. None of the existing agile methods were either extensive nor 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 architectural refinement process. Finally, we provide an overview on team organization in agile environment in support of software architecture and design activities 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 lifecycle is expected to be completed before proceeding to the next one, as for example in a classical water fall process [49]. 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 [50]. While requirements engineering phases and architectural activities phases alternate in traditional processes, the twin peak model emphasizes that these two activities should be executed in parallel to support immediate continuous feedback from one to another (Figure 9). 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 particular 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 engineering phase.

information-technology-software-engineering-requirements

Figure 9: The twin peaks model showing the inter-play of requirements and architecture [50].

Team organization

In its simplest instantiation, an agile development environment consists of a single colocated, cross functional team with the skills, 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 functional teams with traditional functionally oriented teams. An example would be using an integration and test team to merge and validate code across multiple Scrum teams.

In general, we recognized two criteria used to organize the teams. First organizing 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.

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 methodology relies on seven processes namely; (1) definition of architectural requirements; (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 refinement. Agile software development methods have evoked a substantial amount of literature 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 are claiming successes in performing and delivering software in a more agile form. To conclude, we observed that agile methods, without rationalization only cover certain phases of the lifecycle. A majority of them did not provide true support for software architectural design for project management. While universal solutions have strong support in the respective literature, empirical evidence on their adaptation and use in agile environments is currently very limited.

References

Select your language of interest to view the total content in your interested language
Post your comment

Share This Article

Recommended Conferences

Article Usage

  • Total views: 1414
  • [From(publication date):
    January-2017 - Aug 21, 2017]
  • Breakdown by view type
  • HTML page views : 1306
  • PDF downloads :108
 
 

Post your comment

captcha   Reload  Can't read the image? click here to refresh

Peer Reviewed Journals
 
Make the best use of Scientific Research and information from our 700 + peer reviewed, Open Access Journals
International Conferences 2017-18
 
Meet Inspiring Speakers and Experts at our 3000+ Global Annual Meetings

Contact Us

Agri, Food, Aqua and Veterinary Science Journals

Dr. Krish

agrifoodaquavet@omicsonline.com

1-702-714-7001 Extn: 9040

Clinical and Biochemistry Journals

Datta A

clinical_biochem@omicsonline.com

1-702-714-7001Extn: 9037

Business & Management Journals

Ronald

business@omicsonline.com

1-702-714-7001Extn: 9042

Chemical Engineering and Chemistry Journals

Gabriel Shaw

chemicaleng_chemistry@omicsonline.com

1-702-714-7001 Extn: 9040

Earth & Environmental Sciences

Katie Wilson

environmentalsci@omicsonline.com

1-702-714-7001Extn: 9042

Engineering Journals

James Franklin

engineering@omicsonline.com

1-702-714-7001Extn: 9042

General Science and Health care Journals

Andrea Jason

generalsci_healthcare@omicsonline.com

1-702-714-7001Extn: 9043

Genetics and Molecular Biology Journals

Anna Melissa

genetics_molbio@omicsonline.com

1-702-714-7001 Extn: 9006

Immunology & Microbiology Journals

David Gorantl

immuno_microbio@omicsonline.com

1-702-714-7001Extn: 9014

Informatics Journals

Stephanie Skinner

omics@omicsonline.com

1-702-714-7001Extn: 9039

Material Sciences Journals

Rachle Green

materialsci@omicsonline.com

1-702-714-7001Extn: 9039

Mathematics and Physics Journals

Jim Willison

mathematics_physics@omicsonline.com

1-702-714-7001 Extn: 9042

Medical Journals

Nimmi Anna

medical@omicsonline.com

1-702-714-7001 Extn: 9038

Neuroscience & Psychology Journals

Nathan T

neuro_psychology@omicsonline.com

1-702-714-7001Extn: 9041

Pharmaceutical Sciences Journals

John Behannon

pharma@omicsonline.com

1-702-714-7001Extn: 9007

Social & Political Science Journals

Steve Harry

social_politicalsci@omicsonline.com

1-702-714-7001 Extn: 9042

 
© 2008-2017 OMICS International - Open Access Publisher. Best viewed in Mozilla Firefox | Google Chrome | Above IE 7.0 version