Which gate in the RUP methodology includes building and developing the project

1 Develop software iteratively

RUP follows the phases of the generic object-oriented life cycle (inception, elaboration, construction and transition) described earlier in this chapter. It is built on the central concept of iterative development (as shown in Figure 1.3) and each of its phases defines a series of activities that may be performed once or a number of times. Each iteration is defined as a complete development loop resulting in the release of an executable product that is a subset of the final system. In this way RUP supports incremental development – the frequent release of small packages of software that gradually build up to become the final system. Iteration and incremental development encourage involvement and feedback from clients and users; they make it easier to cope with changes, and reduce the risk factors associated with any development project.

2 Manage requirements

RUP offers sound support for eliciting, organizing and recording requirements. Precise documentation of requirements facilitates traceability through the development process, which enhances the quality of the final system. The emphasis on the activities that take place early on in the life cycle provides a sound foundation for the later stages and results in systems that are robust, reliable and meet the needs of their users.

3 Use component-based architectures

RUP prescribes the early identification and development of a system structure that is at the same time robust enough to ensure system reliability, and flexible enough to accommodate changes. This is achieved through the use of components – subsystems that each have a single, well-defined function. RUP describes how to construct an architecture combining both new and previously existing components, thus encouraging the reuse of software as part of the development process.

4 Visually model software

RUP is based around the Unified Modelling Language (UML) as a vehicle for development. UML has become an industry standard, and incorporates a wide range of techniques and tools to support developers. The techniques offered by UML bring with them all the advantages of visual modelling. For example, UML diagrams facilitate communication between developers and users and between members of the development team, they offer a number of different views of the system which combine to give a complete picture, they help developers to decompose the problem into smaller, more manageable chunks, and they provide a means of abstraction, concentrating on important information while hiding details that are currently irrelevant.

5 Verify software quality

RUP provides the techniques to support quality assessment of functionality, reliability and performance throughout the development process. The RUP approach to quality is based on objective measures and criteria for success; it involves all members of the development team and applies to all the activities that are carried out as part of the system development.

6 Control changes to software

Changes are the norm in a software development project, so an effective development process must be able to monitor and control them. RUP provides tools to do this, and also supports the work of developers by offering protection in one area of development from changes that occur in another.

RUP is an increasingly popular approach to developing software systems, and is already laying claim to be the industry standard. However, it would be overkill to work through all the details of RUP in this book, since the book is based around the development of a small, simple information system. We therefore describe the development of the Wheels bike hire system within a simplified object-oriented framework.

Proving Out Architectures Using a “Steel Thread”

RUP practitioners advocate a further technique that agile EDW teams will find very helpful during the elaboration phase of their projects. Given a typical EDW project’s complex mix of functional, architectural, and nonfunctional requirements, how can a team know that the programming architecture, tool set, and platforms chosen for the project represent a workable combination? Agile EDW teams can answer this by constructing a “steel thread”—that is, by programming a single small line of information services all the way from the landing area to a front-end dashboard.

As explained to me by RUP practitioners, the name of this technique derives from the construction of suspension bridges, such as the Golden Gate Bridge in San Francisco. The roadbed of these bridges hangs from massive cables that stretch between piers set in bedrock, often miles apart. Those massive cables were not delivered ready-made and then lifted to the appropriate height but, instead, had to be assembled, in place, one strand of steel at a time. Once the first small thread of steel was situated along the correct arc, the construction crews used a special winding device that would travel along the partially completed cable, back and forth between the piers, laying down one wire after another until the full cable was complete.

This anecdote immediately brings one question to mind: Where did the original steel thread that the winding machine began following come from? Someone had to start at the top of the first pier, attach the starter strand, and then climb down, travel by boat to the next pier, and climb the second tower to put the first steel thread in place. Once the first steel thread was situated, the rest of the work of building the full cables could proceed at pace.

To prove out the project’s architecture, then, the agile EDW developers need to identify a small slice of functionality that will travel from source extract to business intelligence dashboard. They need to think through their design and pick the path of this steel thread carefully so that it touches on as many of the doubtable components in the architecture as possible without involving too large a set of developer stories. If possible, the team should strive to select developer stories that not only prove viability of the project architecture but also add up to a valuable business service so that the product owner can appreciate from a business perspective the deliverables of the elaboration phase when reviewing them during the project’s first few user demos.

For some projects, the steel thread will involve a majority of technical issues so that the team may need the product owner to allow it an “architectural sprint” that everyone understands will provide very little for an end user to appreciate. Such architectural sprints should be kept to a minimum, however, because they violate the central agile tenet of constantly delivering value to the customer. By definition, a steel thread for EDW projects brings at least a few data elements to the end-user dashboard, so with a little imagination, project leaders should be able to include in this work multiple end-user features.

Viewing the previously discussed notions through the lens of requirements management, then, team leaders can anticipate that the steel thread will somewhat impact their project’s starting backlog. The risk mitigation analysis elevated the riskiest stories in the backlog. The steel thread analysis then rearranges the backlog further to ensure that the opening iterations not only address the technical concerns over risk but also add up to something of appreciable value for end users.

Source-to-Target Mappings as Supplemental Specifications

The RUP templates include a supplemental specification section in which a designer can express early design details specifying notions about how the application should be built. EDW teams use this section in particular for a standard data warehousing artifact called the source-to-target map (STM). STMs specify how one or more columns in source data tables will be merged into a single column on the target side. Some agile data warehousing teams do not employ STMs because their programmers prefer to work directly with a product owner who can explain the necessary business rules as they are coding a module. Just as frequently, however, teams include programmers who want only to code ETL and are not comfortable filling an analyst role. The teams would rather program from a specification rather than hashing out business rules with a subject matter expert. This preference is particularly common for teams involving subcontractors for module coding, or when a language barrier may prevent the subject matter experts and programmers from readily understanding each other. In such cases, the project leads can fill out a spreadsheet detailing transformation rules, such as the excerpt shown in Figure 10.20.

14.4 Commercial Process Models

This section discusses the integration of unit tests based on commercial process models. The proprietary Rational Unified Process (RUP) is one representative of incremental models. We will be using Extreme Programming as an example for evolutionary (and agile) processes next, because it represents the home of the testing approach discussed in this book.

Rational Unified Process

2500 pages of process description

The Rational Unified Process (RUP) is a commonly used incremental process [Kruchten99]. This process is available in two variants. One publicly available version in the form of a book [Jacobson99] is called Unified Software Development Process; it was defined by the OO gurus, Jacobson, Booch, and Rumbaugh in 1999. In contrast, the actual RUP is a commercial product of Rational Software Corporation. The process definition of RUP is a hypertext document describing the workflow details in an overwhelming volume of about 2500 pages; it includes templates and offers tools for integration into the development flows.

Two-dimensional process structure

Inception Elaboration

Construction Transition

The structure of RUP comprises two dimensions (Figure 14.6). The time dimension divides the project duration of RUP into various phases. Being an incremental model, RUP begins with a total planning phase, called inception in RUP lingo. This phase identifies all functional requirements and creates a coarse project plan. The next phase (elaboration) describes the most important requirements in detail; they form the basis to elaborate an architecture allowing us to realize all increments. The system is then incrementally created during the subsequent implementation phase (construction). Each increment uses a small sequential process—a mini waterfall. The transition phase begins when all increments have been integrated into the system and tested. Next, the system is validated within its production environment, and remaining errors are removed. Eventually, experiences are collected and process improvements are planned.

Figure 14.6. Structure of the Rational Unified Process.

The second dimension of the process description is the content dimension. This dimension describes core workflows, forming the mini-waterfall process used for each increment. The latter begins with the (optional) business modeling, where existing processes or systems are modeled and used as a basis for the new development. Based on the business requirements, the requirements workflow develops the requirements of the software. This basis is used for the analysis and design workflow to develop software models, where RUP is closely related to using the Unified Modeling Language (UML) [OMG-UML]. The subsequent workflows implement the increment based on the design, and then integrate it into the previous increments and test it.

Core workflows

Figure 14.6 also shows that the parts of each single workflow are not identical in each iteration. The first iterations strongly focus on gathering the requirements, while later iterations concentrate more and more on implementation and testing.

In addition to the workflows for the mini waterfall, RUP also describes supporting management workflows, such as configuration and change management, project management, and environment. Although quality assurance is missing in RUP, experience has shown that RUP can be easily combined with classic quality assurance procedures, at least when the quality staff is trained for the notations and workflows of RUP.

Supporting workflows

Testing strategy in RUP

The testing strategy in RUP consists of unit tests, integration tests, and system tests, similar to those described for other models. The universal systematics with regard to creating and documenting tests is of particular interest; it is based on the close relationship of RUP to UML and especially to use cases.4 The starting point for a test is the scenarios, which are either,

▪

use cases that describe step by step how a user operates the system; or

▪

interaction charts representing the scenarios selected from a use case in UML by gradually describing the interaction between objects in the system.

To test these scenarios, we need various elements:

▪

Testing procedures, which are derived from the scenarios. A testing procedure describes a sequence of steps undertaken during a test. These steps are the scenario as described in the use case or interaction chart. For this purpose, we describe input data and the expected results.

▪

Test cases in RUP describe the combined input and output data to be tested in the testing procedure rather than the steps of the testing itself, in contrast to the terminology used in the rest of this book. These realization steps are documented in a testing procedure. A testing procedure can be used to run various test cases.

▪

Test scripts automate testing procedures. These scripts can be developed by use of a testing tool or testing framework, as described in this book.

Testing vocabulary in RUP

Figure 14.7 shows how all these things interrelate. Uniform trackability from the use case to the testing procedure and the test script is particularly meaningful for requirement-driven system or acceptance tests, because it ensures that the requirements are properly tested.

Figure 14.7. Relations between the RUP's testing artifacts.

For unit tests, however, this redundant documentation represents the maximum step, which we would create only in very rare cases, and it is not necessary in RUP. For central classes (e.g., classes that implement a protocol), we could also derive the automated unit test from an interaction chart for that class. In RUP, running unit tests produces a test result (e.g., in the form of a test log), like the one created by xUnit. First, we want to improve halted tests (i.e., tests that stopped due to errors in the test script) until all tests terminate successfully. And finally, the test results are evaluated; the goal here is to have all tests functioning at 100% at the end of the iteration.

Regardless of the volume of additional documentation created, it is important to note that unit tests are an integral part of RUP and very well suited to its incremental development approach.

Unified Modeling Language

If you were doing object-oriented development in the early 1990s, your team would have had to initially decide on which design notation to use. Should it be the Booch clouds versus Rumbaugh’s more box-like notation or the domain object circles of Jacobson? What about use cases? Should they even be considered as part of an object-oriented approach?

Then suddenly, one company, Rational Software, ended up employing three of the big names in this field—Grady Booch, James Rumbaugh, and Ivar Jacobson. They became known as the three amigos, and UML was born. It was then adopted by the Object Management Group (OMG) as a standard in 1997.

Today a majority of developers and designers use UML notation when visually communicating design options and decisions.

Interestingly, agreeing on a common process was not that successful. The Rational Unified Process (RUP) originated at the same time from the same company but did not gain as much universal acceptance as UML. This is somewhat understandable because a common language makes peoples’ lives easier, but a common process can be considered stifling to creative software developers.

The value of a common process can be exemplified by the experience of one of the authors while acting as a consultant while using a precursor to Rational Unified Process. A consultant using the same process had been working for 1 year helping with the design of a major system for a U.S. entertainment organization. When it was decided that a new consultant would take over the role, the two consultants agreed to have a week’s handover with the viewpoint that transferring all the inherent knowledge on the project would take some time. To both of the consultants’ surprise, knowledge transfer was completed in half a day. All that they needed to communicate was the artifacts and the state they were in; the rest was self-explanatory. The new consultant was effective on his second day.

5.4.2.1 Phase one

Case Beta is split up in two phases that differed mainly in organization of the project. Phase one was facilitated by a very light RuP approach. The main goal of the project was to prove that case-based working, on an extendable technical solution, was applicable for the organization. There was a practical attitude towards documentation, and a focus on working software. Biweekly iterations were used to get the customer involved and to get feedback quickly. The results of this phase were a proof of technological validity of the solution and a first working version of the case management system. The customer was enthusiastic about the results and decided that a second phase should be initialized to complete the case management system for a specific department.

The Iterative Spiral

Iterative development methods have existed for years in large-scale software and manufacturing sectors. They carry many names: rapid application development, rational unified process, total quality management, joint application development, and the evolutionary life cycle, to name a few. Although the specific details of these methods vary quite a bit, they share the underlying idea of progressive refinement through cyclical data-driven development, and although they may describe the iteration with five or more steps, the core ideas behind them can be summarized in three basic stages (Figure 3.5).

Examination. This step attempts to define the problems and whom they affect. Questions are raised, needs are analyzed, information is collected, research is conducted, and potential solutions are evaluated. Strengths and weaknesses are enumerated and prioritized. Customers’ needs and their capabilities are studied, and existing products or prototypes are evaluated. For example, maybe the company extranet is bringing in new customers, but the support mailbox is always full of messages from people who can’t seem to find what they’re looking for. Maybe there’s a usability issue in the interface, but it could also be that a fundamental service is missing or that the user population isn’t the one that had been expected.

Definition. Solutions are specified. Maybe the extranet’s support mail is pointing to a fundamental feature that’s missing from the product. At this stage, changes in the product are mapped out with ever-greater detail as additional information about the real needs and capabilities of the target audience is uncovered.

Creation. Solution plans are carried out. Since it’s the most expensive and time-consuming phase (taking as much as half of the development time), if the work done in the creation stage is not backed by data collected during the examination phase and by careful planning in the definition phase, much of it could be wasted.

So far, this resembles the waterfall method, but what makes iterative development different from that assembly line is that creation is immediately followed by another cycle, beginning with examination. Each cycle—and there may be many cycles between initial examination and launch—isn’t expected to produce a complete product, but add to the quality of understanding and to flesh out the feature set. Thus, the project adapts with every iteration, making the process thorough and responsive to new information and to changes in the business environment. This, in theory, minimizes unnecessary development while making products that are more in tune with what people need.

These ideas are indebted to Barry Boehm’s “Spiral Development” method, which he introduced in the May 1988 issue of Computer magazine.

7.4 Related Work

Since the inception of the software architecture [26], a number of methods have been proposed for architecture design. Most prominent of these methods are Attribute Driven Design method [28], Siemens Four Views method, Rational Unified Process [6], Business Architecture Process and Organization and Architectural Separation of Concerns method [18]. All these methods have three common activities: architecture analysis, architecture synthesis and architecture evaluation [18]. Architecture analysis and synthesis activities include identifying architecturally significant requirements, developing architecture scenarios, designing architecture elements using architecture patterns and representing architecture using multiple views [6]. Generic architecture evaluation methods include Architecture Trade-off Analysis Method (ATAM) [21], Software Architecture Analysis Method (SAAM) [22] and Quality-driven Architecture Design and Analysis (QADA) method [23]. These methods focus on evaluating software architectures with respect to specific quality attributes by evaluating architecture strengths and weaknesses, sensitivity and tradeoff points, and completeness of a given architecture.

Other than generic architecture design methods, the methods for designing and evaluating specific technology paradigms have also been proposed. The methods for Service Oriented Architectures (SOA) focus on transforming system elements in to software services, communication among the services, and exception handling and fault recovery strategies [29–31]. The methods for cloud-based systems focus on satisfying Quality of Service (QoS) requirements (e.g., availability, security and safety), incorporating cloud specific quality requirements (e.g., multi-tenancy and cloud-interoperability) and selecting appropriate cloud resources or cloud-hosted services that satisfy Service Level Agreements (SLAs) [4,32].

The increase in the complexity of the software systems has raised the need to have methods for reusable architecture solutions. Hence, the RAs design and analysis methods are devised [5]. A RA focuses on capturing generic business and architecture requirements and corresponding architectural representations. For example, a RA for cloud-based tools focuses on tools selection, tools provisioning, providing semantic integration among the tools and raising awareness of the operations that are performed using the integrated suite of tools [25]. However, using a RAs to design concrete architectures and evolving the RAs as the domain for which the RA is designed evolves, is a challenging undertaking [27]. The research presented in this chapter has attempted to bridge this gap by proposing an analysis and design approach on top of the existing approached.

The related work on architectures for WoT focus on discovery, selection, provisioning, integration, interoperability and management of the things and services in a WoT system. Guinard et al. [33] have proposed a Service Oriented Architecture (SOA) to support integration of services in an Internet of Things (IoT) system. The proposed architecture consists of two tiers: one tier can be deployed on the local premise and other tier can be deployed on a cloud-based infrastructure. The local tier facilitates integration with the devices with help of the local proxies. The data received from the devices is sent to the cloud-based infrastructure. The cloud infrastructure monitors all the incoming requests and delegates the requests to the services assigned to handle the requests after analysis of the nature and type of the requests. Akribopoulos et al. [34] have proposed an architecture to support integration of things in a WoT System with the help of small programmable objects. The data from the IoT devices is delegated to the programmable objects using a centralized controller. The controller provides proxies for integration with the client devices and authenticate all the incoming requests. The controller also uses web services to expose the interfaces for accessing the devices and the programmable objects. Mrissa et al. [35] have proposed an avatar-based infrastructure for the WoT. The infrastructure maintains package repositories for end user applications, functionality services and appliance drivers, and facilitate a WoT system's composition for varying user requirements.

Some of the related work focus on providing solutions for addressing the challenges specific to IoT architectures. Guinard et al. [36] have proposed a resource oriented architecture to support integration among the devices using smart gateways and RESTful interfaces. The proposed architecture facilitates direct interaction among the web clients and the IoT devices by abstracting the communication protocols of the IoT devices. Gronli et al. [37] have proposed a layered architecture for managing the things in a WoT system. The architecture is consisted of interface, management, service and application layers. Mainetti et al. [38] have proposed an architecture for visual composition of the services in a WoT system. The proposed architecture abstracts the wireless sensor network using a proxy server (web socket) and provides interfaces for the visual designer. Xu et al. [39] have presented a SOA for IoT based upon the industries best practices. The SOA for IoT is consisted of sensing, network, service and interface layers. These layers correspond to different elements of a WoT system. Yashiro et al. [40] have presented an IoT architecture for embedded appliances. The architecture puts a Constrained Application Protocol (CoAP) in the middle of end user applications and IoT censor hardware. The CoAP provides concrete communication mechanisms for the constrained networks. Zhou et al. [41] have proposed a cloud-based IoT architecture for dynamic service composition. The architecture is consisted of hardware, infrastructure, platform, service composition middleware and application layers.

Whilst the related work on WoT architecture focus on describing detailed architectures to manage different aspect of a WoT system, the research presented in this chapter is focused on how elements from standardized reference architectures (which are designed using a number of concrete IoT or WoT architectures) can be used for designing a specific type of a WoT system.

13.4 Iterative development

An improvement on waterfall methods, and a precursor to agile methods, is iterative development. This practice is at the heart of many methods, including the Rational Unified Process (RUP), a representation of which is shown in Figure 13.1 [15].

This representation has two dimensions—content (the vertical axis, showing various disciplines) and time (the horizontal access, showing iterations and phases). Although an architecture discipline is shown, it is of course the time dimension that is of most interest when it comes to understanding the mechanics of iterative development and its influence on architecture. The key concepts of iterations and phases (explained below) underpin two key practices that result from this approach:

Iterative Development: As the project progresses, releases provide incremental improvements in capability until the final system is complete. An iterative development process is similar to “growing” software, where the end product matures over time. Each iteration results in a better understanding of the requirements, a more robust architecture, a more experienced development organization, and a more complete implementation.

Establish an iterative life-cycle process that confronts risk early. With today’s sophisticated software systems, it is not possible to define the entire problem, design the entire solution, build the software, then test the end product in sequence. Instead, an iterative process that refines the problem understanding, an effective solution, and an effective plan over several iterations encourages a balanced treatment of all stakeholder objectives. Major risks must be addressed early to increase predictability and avoid expensive downstream scrap and rework [16].

Risk-Value Lifecycle: There is more to an iterative development process than a stream of iterations; there must be an overall framework in which the iterations are performed, representing the strategic plan for the project and driving the goals and objectives of each of the iterations. Such a framework is provided in the RUP, whose phases are labeled inception, elaboration, construction, and transition. Each phase concludes with a major milestone and an assessment to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase.

Phases also answer the question “what should an iteration focus on?” RUP phases support a risk-value approach that results in risk being removed from the solution early in the lifecycle. This is particularly manifest in the elaboration phase, whose key measure is a stable architecture and which is focused on removing technical risk, ensuring that those elements of the solution that are costly to change are considered sooner rather than later. The change of emphasis over time is implied by the “humps” in Figure 13.1, where the relative emphasis of each discipline changes over the life of the project to meet the goals of each phase. A phase-based approach therefore supports the convergence of a number of elements as the project progresses. For example, risks reduce over the project lifecycle, and any cost and schedule estimates become more accurate.

Of course, such an iterative approach based on phases (and associated milestones) isn’t confined to RUP:

When reviewing projects using the risk-driven spiral model, I find that to keep from losing their way, such projects—particularly larger ones—need to have at least three major anchor-point milestones to serve as project progress indicators and stakeholder commitment points [17].

The RUP (and other iterative methods) introduce other practices that are also relevant to the work of the architect. Although these practices apply equally to plan-centric methods, they have been given a particular emphasis when applied in conjunction with an iterative approach and so are included here.

Shared Vision: This practice ensures that all stakeholders, both consumers and producers of the solution, share a common view of the problems being solved and the key characteristics of the solution (albeit at a high level). In essence, this practice is focused on aligning expectations and ensuring market acceptance. This practice ensures that there is an alignment between product strategy and the output from the development team.

Use Case-Driven Development: The practice of describing primarily functional requirements with use cases is well-documented. Aside from the technique itself, use cases (and flows through each use case) make natural units of implementation in an iterative development approach, because use cases influence planning, architecture, development, and testing.

Release Planning: This practice is focused on the just-in-time project planning needed to scope the release of executable software within an iteration. This iteration-specific planning complements any high-level planning that considers the project as a whole.

Which gate in the RUP methodology includes building and developing the product quizlet?

Which gate includes building and developing the product?

Which key in the RUP methodology is construction?

What are the 4 phases of RUP?