Phase 2 of Unified Process Life cycle - Elaboration

Unified process is one of the outstanding processes that follow an iterative and incremental approach for the software development. The whole process of the unified process is constituted of the 4 stages or phases namely:

1. Inception
2. Elaboration
3. Construction and
4. Transition

This article is dedicated to the second phase of the unified process i.e., the elaboration phase. So let us see what all processes are involved in this phase. 

There exists a short phase between the inception phase and the elaboration commonly knwn as the “elicitation” phase. It is sometimes regarded as apart of the elaboration phase only but to keep the elaboration phase short and simple it is often treated separately.

First let us know what is this elicitation phase? 

Elicitation addresses the below mentioned three main problems of the software development process:

1. Problem of volatility
2. Problem of scope
3. Problem of understanding

What is an Elaboration Phase?

- During this whole elaboration phase, it is required that the project team captures quite a large number of the requirements of the software system or the application. 

- But this is not to be confused with the primary goal of the elaboration phase. It is quite different. 

- The primary goal involves the addressing of the involved and known risk factors. 

- Another aspect of the primary goal is to validate the architecture model being used in the system. 

- This is done with the help of various processes like those mentioned below:

1. Creation of use case diagrams
2. Creation of class diagrams
3. Creation of class with basic notation only and
4. Creation of architectural or the package diagrams.

- All these above mentioned processes fulfil only the first aspect of the primary goal that is to identify the risk factors. 

- The second aspect is fulfilled through the implementation of an EAB or an executable architectural baseline.

- It helps greatly in validation of the system architecture. 

- This is just a partial implementation rather than being a full implementation. 

- The partial implementation is of the components that are architecturally significant like the system including the core.

- The executable architecture baseline is built out of a series of small iterations that have been time boxed so that there is the stabilization of the architecture of the system by the end of the elaboration phase. 

- The executable architectural baseline provides a means to demonstrate that the key system functionality are supported by the architecture and also exhibit proper expected behaviour when it comes to the terms like the scalability, performance and cost. 

- The outcome of the elaboration phase i.e., the elaboration phase deliverable actually serves as a plan for the construction phase that also lays down the cost estimate and the schedule estimates.

- The plan at this point needs to be credible and quite accurate since the elaboration phase experience is what on which it is dependent and also because all the significant risk factors have been addressed during this phase. 

- The ultimate purpose of this phase is to provide the software with a baseline for the architecture of the software system that serves as a foundation for the further efforts. 

Goals of Elaboration Phase

- The following are the goals of the elaboration phase:

1. To have a detailed understanding of the key requirements.
2. To mitigate significant risks.
3. To produce accurate schedule and cost estimates.
4. To design, validate and implement the architecture baseline

- The number of iterations in the elaboration phase is not fixed; it varies depending up on the factors such as the maintenance cycle and the green field development. 

Requirement Model - Obtained during Elaboration phase

During elaboration, the information that is obtained from inception and elicitation are refined and expanded to produce two models:
- Requirements Model
- Analysis Model

The requirement model provides a model of the system or problem domain. It consists of three things:

Use Case Model
Use case model describes what the system does. It serves as a contract between the customers, end users and developers. The Use CaseModel consists of two parts, namely, the use case diagrams and use case specifications.
The use case diagram shows the functionality that the system provides and which users will communicate with the system. It consists of actors and use cases.
The use case specifications are textual documents that specify properties of the use cases.

Supplementary Specifications
Requirements that do not map to a specific use case are part of supplementary specifications. These requirements may be non functional or system constraints. Non functional requirements includes maintainability of the source codes, usability, reliability, performance, and supportability. System constraints restricts our choices for constructing a solution.

Glossary
It defines a common terminology for all models. This is used by the developers to establish a common dialect with customers and end-users.

What are different tasks of requirement engineering - Elaboration,Negotiation,Specification,Validation,Management

Elaboration involves the information that is obtained from team during inception and elicitation is expanded and refined. It focuses on defining, redefining and refining of models. It tries to model the "WHAT" rather than the "HOW".
- Requirement is created using methods that capitalize on user scenarios.It describes how the end-users and actors interact with the system.
- The analysis model is derived from the requirements model where each scenario is analyzed to get the analysis classes.
- The requirements model and the analysis model are the main workproduct of this task.

Negotiation involves customers, stakeholders and software development team reconcile conflicts. The purpose of negotiation is to develop a project plan that meets the requirements of the user while reflecting real-world constraints such as time,people and budget. Negotiation includes:
- always remember negotiation is not completion.
- always have a strategy.
- always listen effectively.
- always focus on other party's interest.
- never make it personal.
- always be creative.
- be ready to commit.

Specification is the final artifact or work product produced by the software engineer during requirements engineering. It serves as the foundation for design and construction of software.

In Validation,the work products produced as a consequence of requirements engineering are assessed for quality. It checks whether inconsistencies, omissions, and errors have been detected and corrected. The
review team that validates the requirements look for errors in content or interpretation,areas where clarification is required, missing information, inconsistencies,conflicting and unrealistic requirements.

Management is a set of activities that help the project team identify, control, and track requirements and their changes at any time as the project progresses.

Introduction to Unified Process - Different stages in Unified Process

The Unified Process is a use-case driven, architecture-centric, iterative and incremental software process designed as a framework for UML methods and tools. The Unified Process is an incremental model in which five phases are identified:

- Inception Phase
It encompasses both customer communication and planning activities and emphasizes the development and refinement of use cases as a primary model. Incremental nature of the ensuing project is developed. In general, a use-case describes a sequence of actions that are performed by an actor as the actor interacts with software.

- Elaboration Phase
It encompasses the customer communication and modeling activities focusing on the creation of analysis and design models with an emphasis on class definitions and architectural representations. Elaboration refines and expands the preliminary use cases that were developed as part of inception phase and expands the architectural representation to include five different views of software - use case model, analysis model, design model, implementation model and deployment model.

- Construction Phase
It refines and then translates the design model into implemented software components. To accomplish this, analysis and design models started during elaboration phase are completed to reflect the final version of software increment.

- Transition Phase
It transfers the software from the developer to the end user for beta testing and acceptance. The software team creates the necessary support information that is required for release. At the end of this phase, the software increment becomes a reusable software release.

- Production Phase
In this, it is an on-going monitoring and support are conducted. This phase coincides with the deployment activity of generic process.

It is possible that work may have already begun on next software increment at the same time when the construction, transition, and production phases are conducted.

What are different steps while conducting component level designing?

The following steps represent a typical task set for component level design, when it is applied for an object oriented system. If you are working in a non object oriented environment, the first three steps focus on the refinement of data objects and processing functions identified as part of analysis model.

STEP 1: Identify all design classes that correspond to the problem domain.
STEP 2: Identify all design classes that correspond to the infrastructure domain.
STEP 3: Elaborate all design classes that are not acquired as reusable components.
In addition to all interfaces, attributes, operations, design heuristics i.e cohesion and coupling should be considered during elaboration.
- Specify message details when classes or components collaborate.
Structure of messages that are passed between objects within a system are shown as component level design proceeds.
- Identify appropriate interfaces for each component.
Interface is an abstract class that provides a controlled connection between design classes. So interfaces should be identified appropriately.
- Elaborate attributes and define data types and data structures required to implement them.
The programming language that is to be used in the project typically is a factor in the definition of the data structure and types used to describe attributes. When the component level design process is started, the name of attributes is used; as the design proceeds the UML attribute format is increasingly used.
- Describe processing flow within each operation in detail.
There are two ways to do this; through a UML activity diagram or a programming language based pseudocode. The elaboration of each software component is by doing a number of iterations and in each iteration a step-wise refinement concept is used.
STEP 4: Describe persistent data sources and identify the classes required to manage them.
As the design elaboration proceeds, an additional data should be provided about the structure and organization of these data sources which are initially specified as part of architectural design.
STEP 5: Develop and elaborate behavioral representations for a class or component.
In order to depict the externally observable behavior of the system as well as that of individual analysis classes, UML state diagrams are used. As a part of component level design, modeling the behavior of a design class may be sometimes required. The instantiation of a design class a s program executes is also known as the dynamic behavior of the object. This behavior is impacted by the current state of object as well as external events.
STEP 6: Elaborate deployment diagrams to provide additional implementation detail.
When component level design is being done, in order to make deployment diagrams simple to read and comprehend, the location of components(individual components) are generally not depicted.
STEP 7: Factor every component level design representation and always consider alternatives.
The first component level model that is created will not be consistent, complete and accurate as compared to the nth iteration that is applied to the model. It is necessary to re-factor as design work is conducted.

Designing Class based Components - Component Level Design Guidelines

As component level design proceeds, there are some guidelines other than basic design guidelines. These guidelines are applied to components and their interfaces, their dependencies and inheritance.

COMPONENTS
- Naming conventions should be established for components.
- These are specified as part of architectural model and then refined and elaborated as part of component level design.
- Architectural component names should be drawn from the problem domain.
- It should have meaning to all stakeholders.

INTERFACES
- Provides information about communication and collaboration.
- Lollipop approach to represent interface should be used in combination with UML box and dashed arrow.
- Interface should flow from left side of the component box for consistency.
- Only relevant interfaces to component should be shown.

DEPENDENCIES AND INHERITANCE
- Model dependencies from left to right.
- Model inheritance from bottom to top.
- Component interdependencies should be represented via interfaces.

Component Level Design - Important Views that describes what a component is?

An Object Oriented View of Component

- From an object oriented viewpoint, a component is a set of collaborating classes.
- Each class within a component consists of attributes and operations relevant.
- Interfaces enabling the classes to communicate with other design classes are defined.
- Designer accomplishes this from analysis model and elaborates analysis classes and infrastructure classes.
- Analysis and design modeling are both iterative actions. Elaborating original analysis class may require additional analysis step which are then followed with design analysis steps to represent elaborated design class.
- Elaboration activity is applied to every component.
- After this, elaboration is applied to each attribute, operation, and interface.
- Data structures are specified.
- Algorithms for implementing each logic is designed.

The Conventional View

- A component is functional element of a program, also called module.
- It incorporates processing logic, internal data structures, interface that enables the component to be invoked and data to be passed to it.
- It resides within software architecture.
- It serves one of the roles control component, problem domain component or an infrastructure component.
- Conventional components are also derived from analysis classes.
- Data flow oriented element of analysis model is the basis for derivation.
- Each module is elaborated.
- Module interface is defined.
- Data structures are defined.
- Algorithm is designed using stepwise refinement approach.
- Design elaboration continues until sufficient detail is provided.

Process Related View

- The above two approaches assume that component is designed from scratch.
- Emphasize is on building systems that make use of existing software.
- As software architecture is developed, components or design patterns are chosen from catalog and used to populate the architecture.

Requirements Engineering Tasks

Requirements Engineering :
* Provides a solid approach for addressing challenges in software project.
* Must be adapted to the needs of the: Process, project and product and the people doing the work.
* Begins during the communication activity and continues into the modeling activity.
* Helps software engineers to better understand the problem they will work to solve.

Requirements Engineering Tasks :
- Inception
* A task that defines the scope and nature of the problem to be solved.
* Software engineers ask context-free questions.
* Intent is to establish a basic understanding of the problem, the people who want a solution, nature of the solution that is desired and the effectiveness of preliminary communication and collaboration between the customer and the developer.

- Elicitation
Ask the customer, the users and others about the objectives of the system, what is to be accomplished, how the system of product fits into the needs of the business and finally, how the system or product is to be used on a day-to-day basis.
Why Elicitation is Difficult?
* Problems of scope.
* Problems of understanding.
* Problems of volatility.

- Elaboration
* Basic requirements (obtained from the customer during inception and elicitation) are refined and modified.
* Focuses on developing a refined technical model of software functions, features and constraints..
* Driven by the creation and refinement of user scenarios.
* End-result: analysis model that defines the informational, functional and behavioral domain of the problem.

- Negotiation
* There’s no winner and loser in an effective negotiation.
* Customers usually ask for more rather than what can be achieved.
* Some proposed conflicting requirements.
* The requirements engineer must reconcile these conflicts through a process of negotiation.

- Specification
* It can be written document, a set of graphical models, a formal mathematical model,a collection of usage scenarios,a prototype,or any combination of these.
* It is the final work product produced by the requirements engineer.
* It serves as the foundation for subsequent software engineering activities.
* It describes the function and performance of a computer-based system and the constraints that will govern its development.

- Validation
* Work products produced are assessed for quality in this step.
* A task which examines the specification to ensure that all software requirements have been stated unambiguously.
* That inconsistencies, omissions and errors have been detected and corrected.
* That work products conform to the standards established for the process, project and the product.