RocReadaR : Technical Process

Software Development Methodology: Unified Process

Software Development Model: OpenUP (Open Unified Process)

OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.

In OpenUP there are four phases in a lifecycle. Each phase has its own set of iterations, but the iterations have different set of focus for the team. A phase ends only when predetermined phase milestones have been achieved, and until then iterations are continually executed. The phases for this project and their prospective milestones are:

Inception Phase:

The first phase of the project, this is the phase where developers and stakeholders agree on the scope of the project and an initial plan for achieving it. This phase also defines the vision for the project and creates a project plan.

Milestones:

1. Project Plan
2. Vision, Scope, and Requirements
3. Domain Model

Elaboration Phase:

Second phase of the project. More focus on specifying requirements via use cases. Architecture is also developed incrementally in this phase. Minor implementation/development takes place in this phase.

Milestones:

1. Architecture Notebook drafted
2. Use Case Document Finalized
3. Architecturally Significant Use Cases designed for

Construction Phase:

Third phase of the project. Major focus on development of the product itself, with some iterations dedicated towards updating project plan, architecture and specifying a deployment plan. Most of the iterations are dedicated towards implementation of prioritized use cases.

Milestones:

1. Feature Deadlines

Transition Phase:

The final phase of the project, there is major focus on final implementation of all remaining use cases while also preparing the product for deployment in parallel.

Milestones:

1. Feature Deadlines
2. Documentation Handoff
3. Product Deployment

Tasks:

• Plan and Manage Iteration
• Assess Results

Work Products:

• Project Plan
• Risk Management Plan
• Four-Up Chart

Software applications at present are too complex to allow us to sequentially define the requirements, come up with an architecture and design, do an implementation, carry out testing, and get it all right. Whether we use waterfall or iterative development approaches, our initial requirements, architecture, design, and code will be suboptimal. With waterfall development, we typically do not get meaningful feedback on what improvements can be made until it is so late in the project that it is too costly to make them. By contrast, dividing the project into a series of time-boxed iterations allows us to deliver capabilities that can be assessed by stakeholders at the end of each iteration. This approach provides rapid and timely feedback loops enabling issues to be addressed and improvements made at a lower cost while budget and time still allow, and before the project has gone so far ahead that major rework is required.

Tasks:

• Plan Project

Work Products:

• Project Plan

Release Planning improves the accuracy of project planning, the ability to predict resource usage, and the ability to meet established delivery dates. In adopting this practice, the project team can better manage scarce resources and focus on delivering scope with higher quality and value to the organization.

Following this practice, the team shall plan for the next few weeks in order to be more accurate than planning for the next few months. The goal of this practice is to balance the high-level and low-level planning such that detailed (low-level) planning occurs just-in-time to support the successful delivery of the software products.

Tasks:

• Envision the Architecture
• Refine the Architecture

Work Products:

• Architecture Notebook

In the Evolutionary Architecture practice, we analyze the major technical concerns that affect the solution and document architectural decisions to ensure that we have assessed and communicated those decisions.

The key principles of the Evolutionary Architecture practice are:

• Perform architecture work "just in time" for all other work. When planning our project, identify and discuss architectural issues with the team, and then prioritize architectural work with any other work. Base our priorities on mitigating technical risk rather than creating value. Deferring architectural issues to handle them "just in time" enables the architecture to evolve over time.
• Document key architectural decisions and outstanding issues. The Architecture Notebook a list of the architectural issues to make it easy to understand which architectural decisions we’ve made and which we’ve not yet addressed.
• Implement and test key capabilities as a way to address architectural issues. Resolving architectural issues typically requires not only architectural brainstorming, but also associated prototyping. In other words: implement enough code to validate the assumptions behind the architecture. The code becomes production code, except for anything thrown away because it proves the architecture invalid.

Tasks:

• Develop Technical Vision

Work Products:

• Vision and Scope Document

Establishing and maintaining a shared vision of the problem being solved (stakeholder needs) and the high-level properties of the proposed product (product features) reduces the risk associated with stakeholder and market acceptance by aligning expectations.

Unfortunately, misunderstandings and miscommunication about the product strategy often lead the development team to develop a system that fails to meet stakeholders' needs and vision.

It is essential that the development team and stakeholders share the same expectations. The product Vision, Scope and Requirements identifies the stakeholders, provides a common understanding of the problem being addressed, captures the high-level stakeholder needs and project constraints, and provides the background and context for requirements that will be detailed later. A shared vision serves as input for communicating the fundamental "what and why" for the project, and provides a strategy against which all future decisions must be validated.

Establishing and maintaining a shared vision is also essential for planning and monitoring the scope of the development effort.  The product Vision, Scope and Requirements establishes the long-term vision for the product, a vision that typically spans several releases, and provides the information required for cost-benefit analysis and prioritization of work.

Tasks:

• Identify and Outline Requirements
• Detail Use-Case Scenarios
• Detail System-Wide Resources

Work Products:

• Vision and Scope Document
• Use Case Document

This practice utilizes use cases and scenarios to capture functional requirements. That approach provides development scenarios that clearly express behavior (or the interaction between users and the system under development). Use cases categorize valuable and useful end-to-end, testable and collaborative behavior in which the system is involved. Non-functional requirements (such as performance, stability, usability, and so on) can still be captured using traditional techniques. This practice also explains how use cases and scenarios are best developed in conjunction with (and used to drive) other development activities, including design and testing.

Tasks:

• Create Tests
• Implement Tests
• Run Tests

Work Products:

• Test Case Document
• Test Log

This practice adopts testing throughout an iteration, concurrent with development. This prevents teams from compressing testing into a separate activity at the end of an iteration or release. Concurrent testing reinforces the concept of feature teammates working in parallel.

Tasks:

• Plan Deployment
• Develop Backout Plan
• Develop Release Communications
• Package the Release
• Execute and Verify Deployment Plan
• Execute Backout Plan (if necessary)

Work Products:

• Deployment Plan
• Backout Plan
• Release Communications

There are two components of the Production Release practice: 1) Release Preparation, and 2) Deployment. Release preparation establishes a release baseline and produces all the necessary supporting material necessary to deploy (and back out, if necessary) the release.