Which of the following project types would be most likely to utilize the iterative methodology?

2.2.1.1 Development Process

Unified Process is based on the enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation. The system is developed incrementally over time, iteration by iteration, and thus this approach is also known as iterative and incremental software development. The iterations are spread over four phases where each phase consists of one or more iterations [4]:

Inception—the first and the shortest phase in the project. It is used to prepare basis for the project, including preparation of business case, establishing project scope and setting boundaries, outlining key requirements, and possible architecture solution together with design tradeoffs, identifying risks, and development of initial project plan—schedule with main milestones and cost estimates. If the inception phase lasts for too long, it is like an indicator stating that the project vision and goals are not clear to the stakeholders. With no clear goals and vision the project most likely is doomed to fail. At this scenario it is better to take a pause at the very beginning of the project to refine the vision and goals. Otherwise it could lead to unnecessary make-overs and schedule delays in further phases.

Elaboration—during this phase the project team is expected to capture a majority of system’s requirements (e.g., in the form of use cases), to perform identified risk analysis and make a plan of risk management to reduce or eliminate their impact on final schedule and product, to establish design and architecture (e.g., using basic class diagrams, package diagrams, and deployment diagrams), to create a plan (schedule, cost estimates, and achievable milestones) for the next (construction) phase.

Construction—the longest and largest phase within Unified Process. During this phase, the design of the system is finalized and refined and the system is built using the basis created during elaboration phase. The construction phase is divided into multiple iterations, for each iteration to result in an executable release of the system. The final iteration of construction phase releases fully completed system which is to be deployed during transition phase, and

Transition—the final project phase which delivers the new system to its end-users. Transition phase includes also data migration from legacy systems and user trainings.

Each phase and its iteration consists of a set of predefined activities. The Unified Process describes work activities as disciplines—a discipline is a set of activities and related artifacts in one subject area (e.g., the activities within requirements analysis). The disciplines described by Unified Process are as follows [107]:

Business modeling—domain object modeling and dynamic modeling of the business processes,

Requirements—requirements analysis of system under consideration. Includes activities like writing use cases and identifying nonfunctional requirements,

Analysis and design—covers aspects of design, including the overall architecture,

Implementation—programming and building the system (except the deployment),

Test—involves testing activities such as test planning, development of test scenarios, alpha and beta testing, regression testing, acceptance testing, and

Deployment—the deployment activities of developed system.

The disciplines and phases of Unified Process are given in Fig. 2.1 where the phases are columns and the disciplines are rows. It clearly shows that the relative effort across disciplines changes over time from iteration to iteration, e.g., initial iterations apply greater relative effort on requirements and design while the latter—more on testing and deployment.

There exist a number of extensions and adaptions of Unified Process, e.g., Agile Unified Process (AUP) [2] and Rational Unified Process (RUP) [56].

Towards a Unified Approach to C&A

As previously mentioned, the JTFTI, led by NIST, with participating members from the Civilian, Defense, and Intelligence Communities, is a joint partnership focused on transforming the federal government’s C&A processes. One of the primary goals is to establish a “unified information security framework that harmonizes security standards and guidelines for NSSs and non-NSSs” [13]. This harmonization effort not only eliminates the duplication among the various federal C&A processes, but also aims at reducing the cost associated with managing and operating multiple overlapping C&A processes.

In addition, the unified process enables the government to more effectively share information when responding to the growing number of advanced cyber threats.

Note

The DoD Cloud Computing Strategy, published by the DoD CIO,25 directed leveraging efforts such as FedRAMP, which prescribes the use of the NIST standards and guidelines as a standardized and streamlined C&A process for commercial and federal cloud providers [17].

These cyber threats have led to challenges within the federal government’s ability to seamlessly share information and authorizations through reciprocity, effectively limiting the reuse of evidence when verifying the implementation of security controls between interconnected systems. As depicted in Fig. 7.1, the unification of C&A processes establishes a bridge across the various federal communities by harmonizing policies and guidance. This harmonization process focuses on using the NIST standards and guidelines currently applied to non-NSSs, leaving the DoD and IC to shift their focus to addressing the unique security requirements through community-specific26 policies and guidance.

Note

There are several key differences between the information and system categorization steps and the control selection processes described between the CNSS policies and the NIST standards and guidelines. These differences [13] include:

System Categorization—different methodologies27 are used to categorize the impact associated with information that is stored, processed, or transmitted.

Security Control Selection—selection of control baselines or control profiles will be conducted differently within each of these communities.

Program Management Controls—program management controls required for nonnational information security programs will be optional for national security system information security programs.

4.1.4 PROCESSES FOR DEVELOPING COMPONENT-BASED SOFTWARE

The alarming reality is that about one-half of the estimated 300,000 software projects in the United States in 2001 will fail due to poor planning, inexperienced project managers, or inept project teams. This section discusses the project management, method and process for building software system especially based on object-oriented components. Our objective here is only to introduce this subject and demonstrate to what extent this aspect is fundamental. This section addresses principally the processes.

Project management faces the challenges of producing top-quality software on time and within budget. As with many industries, managers in software development must keep their staff motivated, cost-justify their strategies, beat deadlines and balance budgets. But this becomes all the more challenging in an industry where terms, technologies and processes shift rapidly. To plan and execute a successful software project, some managers rely on a method.

A notation/language and a specific process define a method. Accompanying the success of the object development, we can count more than 50 object methods and we cannot find one rule, which is very formal and relevant to the different business domains. The UML language opened the unification field in merging the notations and in defining thoroughly the concepts. However, many organisations use the UML as a common language for their project artefacts, but they will use the same UML diagram types in the context of different processes. As a matter a fact, the UML is intentionally process independent, and defining a standard process was not a goal of the UML. The UML language is presented in Section 4.1.5.2.

Therefore, the remaining challenge is to unify the software development process. To specify one universal process would be very perilous. Indeed, experience has shown that different organisations and problem domains require different processes. For example, the development process for shrink-wrapped software is vastly different from building hard-real-time avionics systems upon which lives depend. Even in a single domain such as CAPE, to build a complete environment for process simulation and to build a thermodynamic library for electrolytes require different processes. In fact, the UML authors do not really unify the process but rather collect best practices of object-oriented software (component or not) development. In the future, we should find a family of processes coming from this work, grouped under the term Unified Process.

4.1.4.1 The unified process

As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. The development for the World Wide Web, while making some things simpler, has exacerbated the problem. A well-defined process is a central element on the road of the success.

A process defines a set of partially ordered steps intended to reach a goal. In software engineering the goal is to build a software product or to enhance an existing one. A unified process (UP) [20] is a software development process that uses the UML language to represent models of the software system to be developed. It is iterative, architecture centric, use case driven and risk confronting. It derived primarily from the three market leading methods (Booch, Objectory and OMT) with ideas drawn from many other methods and input from many other parties. Ivar Jacobson, the principal developer of the UP, defines it as: “…a generic process framework that can be specialised for a very large class of software systems, for different application areas, different types of organisations, different competence levels, and different project sizes.” [20]

Figure 8 summarises the overall structure of the UP. The process has two dimensions:

Figure 8. Structure of the unified process

•

The horizontal dimension represents time and shows the lifecycle aspects of the process (phases) as it unfolds.

•

The vertical dimension represents core process disciplines (workflows), which logically group software engineering activities by their nature.

The four phases are:

•

Inception: defines the scope of the project and develop business case.

•

Elaboration: Plan project, specify features, and baseline the architecture.

•

Construction: Build the product.

•

Transition: Transition the product to its users.

The horizontal dimension represents the dynamic aspect of the process expressed in terms of cycles, phases, iterations, and milestones. A software product is designed and built in a succession of incremental iterations. This allows testing and validation of design ideas, as well as risk mitigation, to occur earlier in the lifecycle. The vertical dimension represents the static aspect of the process described in terms of process components: activities, disciplines, artefacts, and roles.

The UP is a process framework that can be adapted and extended to suit the needs of an adopting organisation which can modify, adjust, and expand the process to accommodate the specific needs, characteristics, constraints, and history of its organisation, culture, and domain.

As main examples of unified process, we can cite the Two Tracks Unified Process (2TUP) [30] and the Rational Unified Process (RUP) [22]. The RUP, which is a commercial product from Rational, is defined as a more specific instance, or specialisation, of the more general UP. As with UML, the UP was created and promoted by Rational, but entered the public domain, so that now Rational is just one of many organisations with competence in its use.

It is worth noting that although there is nothing unique in the UP that cannot be found in other modern development processes, it organises high-impact best-practices in a cohesive, thorough, and well-documented presentation. Nevertheless we should notice the critical review of the UP [2] that presents a survey of the alternate software processes, and synthesises a “more” robust process that addresses the complete breadth of real-world development and production needs.

11.9 Health delivery system, core knowledge, and care system interactions

The health-care system is a unified process. It has, however, three manifestations representing three aspects of the same thing: generation and dissemination of health-care knowledge, design of health-care products, and practice of health care. Correspondingly, the architecture provides three interrelated platforms to make sure these three aspects are considered prime functions requiring equal attention. To safeguard the integrity of the health-care process, it is therefore critical that the integrative agent of these seemingly different functions be clearly identified (see Figure 11.7).

The integrity of the process of health-care delivery, more than anything else, will be the property on which the system will ultimately stand or fall. This will require that the three activities of generation and dissemination of health-care knowledge, design of health-care products, and practice of health care, while receiving equal attention, be integrated. The importance of the three activities is such that the proposed systems architecture assigned each one of these activities to a different platform under a separate manager.

On the other hand, these three activities are so interrelated that their integration will be a prime concern. This seems contradictory to the above statement that explicitly assigns the three activities to three separate platforms. The question, therefore, is how the integration of the three platforms is supposed to happen. This brings us back to the core idea of the architecture. A key assumption of this design is that the only way to ensure the integration of the system would be for the knowledge worker to become the integrator.

This means that the integration of the three activities of learning, designing, and practicing health care will be realized by the fact that the designer, the educator, and the practitioner would be one and the same. To preserve the wholeness of the process of providing care, each professional contributor, whether a doctor, nurse, or technician, will be engaged in the three distinct and yet interrelated roles that will feed on and contribute to each other's strength. When in core knowledge, the same provider will help generate and disseminate knowledge by participating in learning cells as a learner/researcher/educator. When in care systems, the same provider will help operationalize his/her knowledge by participating in design cells as a designer/evaluator. When in HDS, the same provider will help utilize new knowledge by participating in practice cells as an implementer/practitioner.

Engagement and ownership of each one of the three complementary and mutually reinforcing roles will prepare, empower, and motivate the provider to succeed in dealing with the other two. Thus a designer/evaluator and at the same time the practitioner of particular products and services will always be most qualified and ready to teach them; a learner/researcher/educator and at the same time the practitioner of particular products and services will always be most qualified and ready to design them; and, finally, a designer/evaluator and at the same time the learner/researcher/educator of particular products and services will always be most qualified and ready to administer them.

In all three contexts, the integrative agent is the doer who has first-hand experience with the problems. Thus the system will become self-correcting, self-educating, and self-integrating. The design will allow the professionals to manage upward and create a “low-archical” approach intimately suited to the idiosyncrasies of a multi-minded and professionally driven organization. Thus, the success of the system will depend on the ability and willingness of the professionals in acting out, depending on the context, all the different roles of learner, educator, designer, and practitioner interchangeably. Although this seems to be against the implicit assumptions of health care, it is perfectly compatible with human nature. In real life, individuals perform many different roles. For example, one plays, quite naturally and almost simultaneously, the roles of parent, professional, friend, boss, and subordinate in different contexts without difficulty. As a matter of fact, this happens to be one of the characteristics that distinguishes humans from other species and constitutes the keystone of social existence.

The composite performance profile of each professional will therefore reflect the three aspects of his/her role as an educator, a designer, and a practitioner. The profile will show the value of the individual to the organization based on the quality and diversity of the roles he/she will be called upon to play in the different contexts of the value chain. The higher the competence, the greater the demand; the greater the demand, the higher the value. One point, however, needs to be underscored here: the design will not encourage, but it will certainly respect, the personal preference of those professionals who, for whatever reasons, might elect not to engage in multiple roles.

In the trio of core knowledge, care system, and delivery system, core knowledge will serve as the home base for the system's physicians, nurses, technicians, and other health-based professionals. This will make it possible for the knowledge worker to accept different roles with different durations in all three platforms. When at core knowledge, it will be the providers themselves who will help perform the stewardship function of the human assets. They will be engaged in learning from and teaching each other to make sure that the health-care competency of Butterworth represents the cutting edge of the health-care profession at all times. They will constantly monitor the direction and state of the science and practice of health care. They will make sure that the entire professional competence of the system is in a state of readiness to respond rapidly, effectively, and adequately to the changing and growing requirements of the market.

While care systems will be responsible for designing the process and packaging health-care products and services, as well as monitoring and ensuring the quality of their deployment, HDS will be where health care will actually happen. HDS will own the capital-intensive and health-related physical assets and will be responsible for their effective utilization in providing the care deliverables.

The three-dimensionality should not be mistaken for the conventional concept of the division of labor and the three-boss system. The three platforms manage the three different aspects of the system, each with a clear-cut accountability in the process. Their relationships will be governed by all three aspects of authority: legal, knowledge, and financial. Across the three contexts, knowledge is the common denominator and therefore will work as the integrative agent. The relationship of the members and their manager in the core knowledge group is boss–subordinate (legal), while in the context of the care system and delivery system the relationship is customer–provider. The successful operation of the three units will therefore require that the creation of a throughput and measurement system with variable budgeting be an integral part of this design.

The design uniquely matches the exceptional requirements of knowledge-driven organizations. It is based on the fact that role rather than individual is actually the building block of social systems. Owing to this, people can have multiple memberships in a variety of organizations in which they act out very different roles. By taking advantage of this phenomenon, the design will provide the individual contributor with unrestricted possibilities for the kind of continuous development and creativity that come with multirole, total involvement in the whole process of health care. Multirole involvement will safeguard the wholeness of the knowledge worker by saving him/her from compartmentalization. Uncoupling the professional from the trappings of narrowly defined jobs will de-bureaucratize the system and rescue both the people and the organization from insulation, unidimensionality, rigidity, petty turf wars, and inevitable obsolescence in a rapidly changing environment.

Freedom from fixed and permanent job descriptions will provide the care systems and HDS platforms with equal freedom from resistance to change, structural conflicts, and suboptimization. It will provide them with infinite flexibility and capacity for unprecedented experimentation and innovation.

Separation of the knowledge worker from a rigid job description is a means for institutionalizing creative freedom. Such freedom ensures professional excellence and organizational viability through continuous learning and total involvement. Freeing the system to constantly define and redefine its basis for competitive advantage will prevent strategic myopia and those organizational defaults that let the requirements of past success become the source of future failure. The design is intended to promote meritocracy and combat bureaucratic tendencies that, when left unchecked, would lead to mediocrity, promotion to incompetence, and eventual conversion of competence to a disqualification.

Project managers at care systems will be responsible for incorporating the inputs of the practitioners in the design of care products. They will make sure that the product development will reflect the emerging market needs. They will also make sure that the integrity of the design is not compromised. Project managers will provide the content and be responsible for the potency of the deliverables, as well as pay for the services of the practitioners/designers who participate in product development. The actual training and development of the practitioners/designers, however, will take place in core knowledge. Thus the development process will have a dual interface: the market and core knowledge.

The challenge is to realize the potentials of the design for responding to the individual's need for independence and the organization's need for interdependence at the same time. The design is a deliberate attempt to avoid sacrificing the good of the whole for the convenience of the part, and vice versa. Suboptimization is deliberately designed out to make it possible for the system to avoid imposition of win/lose solutions that would pit the members against each other in their attempts to win functional battles at the expense of the corporate war. An operation can hardly be qualified as a success if the patient ultimately dies.

The integration of the three platforms, although attractive, should not be considered easy. It will take the total cooperation of these platforms, the full attention of the HDS president, and a real cultural transformation (not to be mistaken with a climate survey) for its enormous potentials to be realized. In the process, the intensity of the resistance associated with the comfort level that comes with prolonged adaptation to single-role performance should never be underestimated.

13.3.2 Concept Models and UML

In its description, the concept model corresponds to the domain model of the Unified Process. Jacobson accurately speaks of a domain object model. He points out the risk of constructing such a domain object model solely on the basis of the developers' knowledge. Instead, he recommends elaborating a business model systematically.

Our model of the application domain with its different document types and aspects is definitely an interpretation of a business model. We place great importance on a systematic approach towards business modeling. The concept model is an important component of the application system model. In the sense of UML, we can therefore argue that our concept model can be thought of as a class diagram. Compared to the Unified Process, it corresponds to the domain object model.

DISCUSSION

The fact that the domain models of the current situation are given so little emphasis in UP can be interpreted to mean that these models are either not important enough or are elaborated by people who are outside the actual development project. We consider both interpretations to be dangerous: As we have stated, we find it important that developers acquire a detailed understanding of an application domain. This requires explicit models. However, these models also have to be elaborated in conjunction with the users. This is the only way to encourage the learning process in the author-critic cycles.

We have already explained the importance of application-oriented models. Another thing that distinguishes the T&M approach is the notion of constructive quality assurance. This is along the same line as what the authors of UP say in their books. However, in our view it also includes the intertwining of programming and testing. Section 12.4.2 describes different test types, which are closely linked to the design and construction activities.

4.3.5 Defining use case priority

One of the main techniques for reducing risk in a project is dealing first with the most complex use cases, especially if they are those that represent the most critical business processes, because with them the team may learn more about the system than with other use cases. Pattern use cases such as CRUD (medium complexity) and reports (smallest complexity) can be addressed later during Construction.

Planning indicates when each use case is going to be analyzed, designed, and implemented. The Unified Process, like most agile techniques, does not expect that the general project plan defines when each use case is to be implemented. However, they are placed in a dynamic priority list, and although it may be updated on the fly, it is possible to know when each use case is supposed to be completed. Planning an iteration begins by choosing which use cases, risks, or change requirements would be addressed on the next iteration. When planning an iteration, the following aspects must be considered when choosing which use cases to address:

Use case complexity: Use cases of higher risk and complexity should be addressed first in most cases, unless special conditions (for example, a relatively simple use case with high technological risk) justify choosing different use cases.

Dependencies among use cases: Use cases that have a strong dependence to the ones that were already accommodated in the iteration should be addressed together if possible, because it avoids fragmenting the work on the classes.

Team load capacity: The development work must be assigned to team members based on their TLC.

One suggestion for prioritizing use cases for the Livir example presented in Figure 3.11 is given in Table e4.7.

Table e4.7. Suggestion for Use Case Priorities for the Livir Example

The order of this list is most critical for the complex use cases, because a wrong choice in terms of their priorities could lead to otherwise unnecessary refactoring in subsequent iterations. We considered that the most important use cases for this business are those related to the process of selling books, because that is what generates profit for the company. However, the order of use cases with lower risk such as cruds and reports is not so critical.

6.1 INTRODUCTION

This chapter describes application development from a software-engineering view. We discuss how software development can be seen as a modeling process in the sense of the Unified Process. We distinguish the domain model from the application system model, and we discuss the actual state of the application domain and the design of the future system.

The message of this chapter is that you should have an explicit model of the application domain in its actual state. This model helps to understand the relevant tasks and the concepts behind them. In our application-oriented approach, understanding the tasks and concepts naturally leads to the design of the future system.

1.2.1 Software architecture process and architecture lifecycle

It is also important to have a good understanding of the SA design process and the so-called lifecycle of SA. It is usually assumed that architecture design is a creative activity without a well-defined process. It can be considered a correct assumption for a large many systems' architecture design. However, in a serious attempt to design and evaluate SA for a large-scale, complex system, it is important that there is a disciplined process that can support the creativity with a more controlled and reflective approach. Moreover, like any other artifact, SA also has a lifecycle that goes through different phases and activities. Each phase of the architecture lifecycle has its own prerequisites for use and applicability.

Several process models and methods have been devised and promoted for supporting the SA process. Some of the well-known ones are the attribute-driven design (ADD) method [7], business architecture process and organization [25], the Rationale Unified Process's 4+1 Views [26], Siemens' 4 Views [27], and architectural separation of concerns [28]. In order to rationalize the options available to software project managers and architects, the developers of five well-known architecture design methods decided to develop a new general model of SA design by merging their respective SA design methods [29]. The original general model of architecture design consisted of three activities. This general model was extended by Tang and colleagues [30] to cover architectural materialization and evolution activities. For this chapter, we have slightly modified the names of the activities in the model. Each of the activities in the general model of architecture design has been briefly described below (see Figure 1.1):

Analyze problem domain: This activity consists of several sub-activities and tasks. This activity aims at defining the problems to be solved. Some of the main activities can be examining the architectural requirements (or even eliciting and clarifying architectural requirements), going through the stakeholders' concerns and context to separate and prioritize the architecturally significant requirements (ASRs) from those that are not architecturally significant.

Design and describe architectural decisions: This activity aims at making key architectural design decisions based on the ASRs. An architect may consider several available design options before selecting the ones that appear to be the most appropriate and optimal. An architect is also responsible for documenting the designed architecture using appropriate documentation notations and templates.

Architectural evaluation: This activity intends to ensure that the architectural solutions chosen during the previous process are the right ones. Hence, the proposed architectural solutions are evaluated against the ASRs.

Realize architecture: This is a phase wherein a designed architecture is deconstructed into a detailed design and implemented. During this phase, software developers make several dozen decisions which need to be aligned with the high-level architecture design decisions. That means software developers need to ensure that their decisions are in conformance with the architecture designed by an architect.

Maintenance of architecture: This involves making architectural changes as the architecture evolves because of enhancement and maintenance requirements, which place several new demands on the architecture underpinning a system. From the knowledge management perspective, prior design decisions are reassessed for the potential impact of the required changes and new decisions are made to accommodate the required changes without damaging the architectural integrity.

It should be noted that the abovementioned activities do not follow a sequential process like the waterfall model. Rather, these activities are undertaken in a quite iterative/evolutionary manner and tasks related to one particular activity can be performed and/or revisited while performing any other activity. In the following sub-sections, we briefly discuss different methods and techniques that are designed to support the SA process described in this section.

1 Introduction

In these days whole world heavily depends on fossil fuels. As more fossil fuels are burnt, carbon dioxide, a major greenhouse gas, is emitted into atmosphere. Increase of carbon dioxide amount in atmosphere is significantly effecting global warming of the earth.

Carbon dioxide capture and storage (CCS) system is a promising technology for accomplishing the desired green energy system. The system consists of CO2 capture, liquefaction, transport, storage and other CO2 application. A lot of researches and projects have been performed to study each process, and CCS projects are being operated in several regions such as United States and north Europe.

While technical demands for individual CCS processes are being satisfied successfully, a new technical challenge of integrating the whole chain of CCS processes into unified process in large scale has become the key for future of CCS technology. Dynamic modeling of individual CCS unit has made a remarkable progress such as developing a CO2 capture model and validating it with expreimental results. For example, Posch (2013) used a rate based approach for dynamic modeling of CO2 capture process and validated the result with experimental data from Durnrohr power station in Austria.

Meanwhile, in modeling an integrated CCS chain, a top-down approach for designing an steady-state IGCC plant with pre-combustion CO2 capture process was presented by Bhattacharyya (2011), and the study showed that the approach seem to be very useful and effective in process simulation environment for integrated CCS system. However, modeling a whole chain CCS process integrating the plant, capture, liquefaction and compression has not been presented before.

In this study, a bottom-up approach for design of integrated CCS model is shown. First, steam turbine for pulverized coal(PC) plant, CO2 capture and liquefaction process are presented. Then an integrated model for CCS system is shown by connecting those models. Important process variables which have significant impact on whole process are listed.