WIXLIB

Software Architecture design in industry. Our research is strongly motivated by a seminal [18] researchpaper. The authors in [18] proposed a general model for architecture design out of the analysis ofcommon practices from different software architecture design methods. Our research employs such ageneral model to evaluate the software architecture design methods embedded in four SDMs, from whichthree of them (i.e. MBASE, MSF and RUP-SOA) are not reported in [18]. Our study reveals insights (nopreviously reported) on how these three SDMs fit the SA design theoretical recommendations from thegeneral model for SA design. Hence, we consider that the main overall contribution of this research isthreefold: 1) our research helps to create awareness in academy on the relevance of SoftwareArchitecture design for producing high quality software, 2) it reports the degree to which current bestpractices for Software Architecture design are used in the four reviewed SDMs, and 3) we point outunsolved issues which are venues for future research in software architecture design.The remainder of this paper is organized as follows. In section 2, we report the research method used. Abrief description of the four SDMs is reported in Section 3. In Section 4, a review of fundamental conceptsin Software Architecture, and the general model of Software Architecture design are explained. In section5, we report the comparative and conformance review of the four SDMs versus the general model ofSoftware Architecture design. In Section 6, we present the theoretical and practical implications of thesecomparisons. Finally, in Section 7 we present a summary of findings, contributions, limitations, andrecommendations for further research.2. Research ApproachA descriptive and evaluative-interpretive research approach [55, p. 90] was used in this investigation. Thisresearch approach can be outlined with the following main steps [56]: i) to define research goals andquestions; ii) to collect official literature on target elements to be evaluated; iii) to conduct a selectiveliterature review on similar studies; iv) to select descriptive-interpretative lenses (schemes); v) to conducta descriptive and interpretative analysis; vi) to review the analysis; and vii) to generate a report.In i), we have defined as core research questions the following: RQ.1 What is the conformance status ofthe SA design methods used in the four selected SDMs against the general model of SoftwareArchitecture design? and RQ.2 What do theoretical and practical recommendations emerge from theconformance results? In ii), we have collected official documents of RUP, MSF, MBASE, RUP-SOA. In iii),we conducted a selective search for similar studies focused on SA design methods used in full SDMs butnone was found. Although comparative studies among SDMs are abundant [31, 32, 33, 34, 35, 57, 58],we did not find any studies focused on comparing the Software Architecture design methods included indifferent SDMs. In iv), we selected Hofmeister et al.’s [18] general model of Software Architecture designas the theoretical lenses for comparing the Software Architecture design methods used in the four SDMs.This general model of Software Architecture design was employed “to analyze other proposed SoftwareArchitecture design methods, or even to drive the development of new architecture design methods” [18,p. 121]. In v), the first two authors conducted the comparative analyses by doing a careful joint reading ofthe official documents and by using the grid evaluation suggested by Hofmeister et al. [18]. This task wasconducted with several iterations including discussions on discrepancies until the first two authorsachieved an agreement. In vi) the third author conducted a thorough evaluation of the review resultsproduced by authors one and two. The discrepancies found were finally reviewed again and the threeauthors agreed on a final solution. Finally, as part of this step, the rest of the authors conducted an overallreview of the comparative analysis. Only a few minor errors were found and solved jointly by the researchteam. In vi), we wrote this article.3. A General Review of RUP, MSF, MBASE and RUP-SOA SDMsSome software Development Methodologies (SDMs) have been extensively studied in the last fourdecades [59, 35]. According to Avison and Fitzgerald [59, p. 80] a methodology is a “recommended

collection of phases, procedures, rules, techniques, tools, documentation, management, and training usedto develop a system”. SDMs (like system development life cycles) provide an organized roadmap forcarrying activities required for elaborating high-quality software products. According to Kruchten [26, p. 42]without a well-structured software process (i.e. a SDM) a developer team “will develop in an ad hocmanner, with success relying on the heroic efforts of a few dedicated individual contributors”. An evolutionof SDMs has been reported in four major stages: pre-methodologies, rigor-oriented methodologies, agileoriented methodologies and emergent service-oriented methodologies [60, 61]. From the current availablevariety of SDMs [35], some of them are well-recognized in the software engineering literature and practicesuch as: i) Rational Unified Process (RUP) [26]; ii) Microsoft Solutions Framework (MSF) [27, 28]; and iii)Model-Based (System) Architecting and Software Engineering (MBASE) [29]; and RUP-SOA [30], which isconsidered a relevant emergent SMD. These four SDMs can be classified as rigor-oriented methodologies.Next, we describe the SDMs phases of the four SDMs (RUP, MSF, MBASE and RUP-SOA) related to theSA design activity.Description of RUP: Rational Unified Process (RUP) is a "comprehensive process framework thatprovides industry-tested practices for software and systems delivery and implementation and for effectiveproject management" [62, p. 1]. The RUP provides “a disciplined approach to assigning tasks andresponsibilities within a development organization. Its goal is to ensure the production of high-qualitysoftware that meets the needs of its end users within a predictable schedule and budget.” [26, p. 45].The RUP software development process or SDM can be depicted in two dimensions: phases and iterations(time-based axis), and disciplines and workflows (activity-based axis). Each phase and cycle of iterationsends with a milestone. A milestone is defined as: “a point in time at which certain critical decisions must bemade, and therefore key goals must have been achieved” [63, p. 3]. RUP proposes four phases: Inception,Elaboration, Construction and Transition. In each phase, one or more iterations on activity workflows canbe performed, until reaching the expected milestone. The extent of realization of each activity intoworkflows varies according to the type of the phase. There are two groups of workflows: a) core technicaland b) managerial supporting ones. The core technical disciplines and workflows are: 1) BusinessModeling, 2) Requirements, 3) Analysis and Design, 4) Implementation, 5) Test and Deployment.Managerial supporting workflows are: 1) Configuration and Change Management, 2) Project Management,and 3) Environment [63, 26].Here we focus only on describing the 2) Requirements workflow and the 3) Analysis and Design workflowas these workflows are more closely related to architecture design activities. The 2) Requirementsworkflow consists of the following main activities: 1) Analyze the Problem, 2) Understand StakeholderNeeds, 3) Define the System, 4) Manage the Scope of the System, 5) Refine the System Definition, and 6)Manage Changing Requirements. Its main roles are: system analyst, requirements specifier, softwarearchitect and requirements reviewer. The main artifacts generated by this workflow are: vision document,use-case model, supplementary specifications, and a project glossary. The 3) Analysis and Designworkflow consists of the following activities: 1) Define a Candidate Architecture, 2) Refine the Architecture,3) Perform Architectural Synthesis (reported as an optional activity), 4) Analyze Behavior, 5) DesignComponents, and 6) Design the Database. The main roles of this workflow are: software architect,designer, database designer, architecture reviewer and design reviewer. The main artifacts generated bythis workflow are: analysis model, design model, and Software Architecture document [63, 26].Regarding phases, we describe the Inception and the Elaboration phases as they are more closely relatedto architecture design activities. The Inception phase’s goal is “to achieve concurrence among allstakeholders on the lifecycle objectives for the project” [26, p. 95]. The milestone of the Inception phase isthe Lifecycle Objectives (LCO). The main artifacts are: a vision document, the use-case model survey, aninitial project glossary, an initial business case, an initial risk assessment and a project plan. The mainworkflows to be performed in the Inception phase are: project management, business modeling, andrequirements. The Elaboration phase’s goals are: “to analyze the problem domain, establish a sound

architectural foundation, develop the project plan, and eliminate the project's highest-risk elements” [26, p.95]. The milestone of the Elaboration phase is the Lifecycle Architecture (LCA). The main outcomes are: ause-case model, supplementary requirements, a Software Architecture description, an executablearchitectural prototype, a revised risk list, a revised business case, a development plan for the overallproject, an updated development case, and a preliminary user manual (optional). The main workflows to beperformed in elaboration phase are: 1) Project Management, 2) Configuration and Change Management,and 3) Analysis and Design.Description of MSF: Microsoft Solutions Framework (MSF) [27, p. 4] is defined as “a deliberate anddisciplined approach to technology projects based on a defined set of principles, models, disciplines,concepts, guidelines, and proven practices from Microsoft”. MSF is a popular alternative SDM to RUP. MSFis organized in seven tracks (five technical and two managerial ones) and seven team groups. Tracks aregroups of workstreams and activities. Tracks can be executed simultaneously, and each track can haveseveral iterations (cycles) addressing different levels (check-in, daily build, accepted build, iteration, project,and as needed). Technical tracks in MSF are: Envision, Planning, Build (Development), Stabilize andDeploy. Managerial tracks are: Governance, and Operational Management. MSF is based on both phases(tracks) and milestones controls [27]. Phases are “periods of time with an emphasis on certain activitiesaimed at producing the relevant deliverables for that phase” [27, p. 18]. Milestones are “review andsynchronization points for determining whether the objectives of the phase have been met” [27, p. 18]. MSFuses seven types of teams: Program Management, Architecture, Development, Test, ReleaseManagement, User Experience, and Product Management. These team groups participate with differentintensive levels in the seven tracks. Similarly to the RUP analysis, we focus on describing the tracks relatedto the Software Architecture design activity: Envision, Planning and Build tracks.In the Envision track, there are two workstreams: 1) Capture Product Vision and Scope, and 2) EstablishProject Process. In 1) Capture Product Vision and Scope, the following activities are conducted: 1) Write aVision Document, 2) Define Personas, 3) Develop a Lifestyle Snapshot and a Review Product Vision. In 2)Establish Project Process, the following activities are conducted: 1) Select a Project Process Template, 2)Tailor to a Project Process, 3) Review the Project Process, 4) Establish a Measurement Plan, 5) Establisha Project Data Management Plan, and 6) Monitor Measurements and Process Assets. The maindeliverables are: vision/scope document, risk assessment document, and project structure document.Envision track ends with the vision-scope approved milestone. In the Planning track several activities areconducted for producing the master project plan, the risk management plan, and the system’s functionalspecifications. In particular, system’s functional specifications are defined in MSF as detailed descriptionson: “how each feature is to look and behave. It also describes the architecture and the design for all thefeatures” [27, p. 26]. Among the main activities are: 1) Define a Plan for the Project, 2) Create QoSRequirements (e.g. a non-functional requirement), 3) Create Scenarios, 4) Create Product Requirements,and 5) Create a Solution Architecture. The planning track ends with the project plans approved milestone.In the Build track, the following deliverables are produced: source code and executables, installation scriptsand configuration settings for deployment, frozen functional specification, performance support elementsand test specifications and test cases. The main activities conducted are: 1) Plan an Iteration, 2) ManageChange requests, 3) Perform an Analysis, 4) Build a Product, and 5) Test a Customer Requirement. TheBuild track ends when the planned scope milestone is reached.Description of MBASE: Model-Based (System) Architecting and Software Engineering (MBASE) is basedon the "Win-Win Spiral" [29]. MBASE [29, p. 1] "is an approach that integrates process, products, propertiesand success models, for the development of a software system”. MBASE is an iterative (with refinement)development approach with the following workflows (or phases): 1) Operational Concept Description(OCD), 2) System and Software Requirements Definition (SSRD), 3) System and Software ArchitectureDescription (SSAD), 4) Life Cycle Plan (LCP), 5) Feasibility Rationale Description (FRD), 6) Construction,Transition, and Support (CTS) Plans and Reports, and 7) Risk-driven prototypes (RDP). These workflowscan be grouped in Inception-Elaboration phases (OCD, SSRD, SSAD, LCP, and FRD), and ConstructionTransition-Support phases (CTS, RDP). Similarly to the previous analysis of RUP and MSF, we only

describe the workflows related to Software Architecture design activities: 1) Operational ConceptDescription (OCD), 2) System and Software Requirements Definition (SSRD), 3) System and SoftwareArchitecture Description (SSAD), and 5) Feasibility Rationale Description (FRD).These workflows are executed by stakeholders and for stakeholders (called performing agents andparticipating agents, respectively). Stakeholders in MBASE are also classified as operational stakeholders(general public, operators, maintainers, users, and customers) and development stakeholders (managers,analysts, architects, implementers (developers, testers, and marketers)). In the 1) OCD and 2) SSRDworkflows, the participating and performing stakeholders are the operational, manager and analyststakeholders (as a subset of development stakeholders). In the SSAD workflow, the main associatedparticipating and performing stakeholders are users (domain experts), managers, analysts, architects andimplementers. In the FRD activity, the manager, development and operational stakeholders are associated.In the 1) OCD workflow, how a planned system will operate in its organizational and technical environmentis described (e.g. statement of purpose, project goals and constraints, system capabilities, levels of servicegoals, changes and effects on the organization for the new system). This workflow also reports the reasonsfor developing the new system, as well as problems in the current system. Usual visual models (diagrams)employed are: block diagrams, and context diagrams. In 2) SSRD workflows, the fundamental services tobe provided by the new system are reported. Functional and non-functional requirements (level ofservices), as well as mandatory (shall, must, will) and optional (can, could, may) requirements aredescribed. All of these system requirements must be justified with a clear rationality by using Win-Winagreements or options. Usual visual models used are: requirements diagrams, and block (context)diagrams.In the 3) SSAD workflow, the results of analyzing the 1) OCD and 2) SSRD artifacts, designing a systemarchitecture, and designing a system implementation are documented. This workflow is a bridging activityamong the initial 1) OCD realized in the Inception phase, with the updated and final 1) OCD reported inConstruction phase. In 3) SSAD there are three activities realized: 1) System Analysis, 2) ArchitectureDesign and Analysis, and 3) Implementation Design. The 1) System Analysis activity filters the 1) OCD and2) SSRD artifacts, for refining the architecturally relevant requirements. This activity uses block (context),collaboration, use case, use case description, activity, and level of services artifacts. 2) Architecture Designand Analysis elaborates a high-level solution (architecture) independently from its final implementationtechnology. This solution (architecture) describes: components (work units), what these components do,how they are connected, and how they can communicate among them. Usual diagrams used are: classdiagram, component diagram, and static-structure package diagram. 3) Implementation Design elaboratesa specific technology-based implementation solution derived from the high-level architecture. A technologybased implementation defines types of hardware and operating systems, languages, database managers,utilities and libraries. The usual diagrams generated are: component-stereotyped diagrams andimplementation diagrams. A deployment model is also described through component and connectorconfigurations for a working version of the designed software system. For each configuration it must bedescribed the software and hardware component classes used in the configuration, the allocation ofsoftware components to the hardware components, and their specific instances. The architecture model isa standard deployment diagram used at this stage. Finally, the 5) FRD activity is carried out at the end of allInception-Elaboration phases (OCD, SSRD, SSAD, LCP). Its main purpose is to assure the logicalconsistency and feasibility (economic, technical, operational, legal and organizational) of the systemdefinition elements generated in the OCD, SSRD, SSAD and LCP activities.All of these activities in MBASE –grouped in Inception-Elaboration and Construction-Transition-Supportphases- are essentially driven by three completion criteria: Life Cycle Objectives (LCO), Life CycleArchitecture (LCA), and Initial Operational Capability (IOC). LCO refers to the verification of feasiblesystem objectives. LCA is about the verification of a feasible architecture design and plan. Finally, IOCrefers to the verification of a product ready for initial operation.

Description of RUP-SOA: RUP-SOA provides “a disciplined approach to assigning tasks andresponsibilities within a development organization. Its goal is to ensure the production of high-qualitysoftware that meets the needs of its users within a predictable schedule and budget” [30, p. 12]. RUP-SOAis an enhanced version of RUP for software systems built for service-oriented computing platforms. Thus,RUP-SOA has the same phase-discipline structure of RUP (i.e. four phases of Inception, Elaboration,Construction and Transition, with specific disciplines of activities to be conducted within them). The SOAextension is mainly achieved through the IBM Service-oriented Modeling and Architecture (SOMA)methodology [64] which is incorporated in RUP-SOA. The SOMA methodology is essentially used forproducing a service model artifact in the Elaboration phase through the identification, specification,realization and deployment of services [30, p. 27; 64, p. 383].SOA-based applications rely on the essential concept of service that is different from a component or aclass/object. A service can be defined as a well-defined, encapsulated, reusable, business-alignedcapability [64, p. 378] which is loosely coupled, highly reconfigurable (via orchestration and choreographyof services for the case of composite services) and highly platform-independent. Orchestration ofcomposite services refers to the selection of individual services for composing it and in its workflow there isa main service that coordinates the interaction of the remainder ones. Choreography of services refers tothe specific timing-based interaction and communication rules between the service consumers and serviceproviders under an autonomous approach (no service has control over the others) [65].Similarly to the RUP analysis, we focus on describing the phases directly related with the SoftwareArchitecture design: Inception and Elaboration. The RUP-SOA core activities in the Inception phase are: 1)Conceive New Project, 2) Prepare Project Environment, 3) Define Requirements, 4) Perform ArchitecturalProof-of-Concept (activity reported as optional but strongly suggested for any SOA project), and 5) PlanProject. The main role

Architecting and Software Engineering), and RUP-SOA (Rational Unified Process for Service-oriented Architecture) - adhere to the best practices of Software Architecture design. Our analysis points out some of the most important strengths and weakness regarding Software Architecture