The Software Product Life Cycle

Overview

We will categorize the various ways in which stakeholders perceive the software development process and product life

Management Software engineering Engineering design Architectural design

Each view of the development process is comprised of phases, activities, tasks, and steps. phase implies some interval of time and is externally distinguishable from another phase. product planning phase. activity is a particular type of work performed by an individual or a group. For example object-oriented analysis is an activity. It may be performed within a single phase or across multiple phases. A task refers to a specific schedulable item. A task can appear in a project plan and be assigned resources. An example of a task is to design and implement a specific business object. A sequence of steps comprises a task or an activity. A step cannot be scheduled or tracked in a project plan very easily but refers to a fundamental action performed by a designer or programmer. An example step of the analysis activity is to identify all candidate domain objects that appear directly or indirectly in the customer requirements.

Management View

The inception or vision phase) begins when one or more persons identify a real or perceived need (the problem) and envision a system that can satisfy the need. The exit criteria for the inception phase are a product vision and a business case for the product.

The stakeholders who desire the system are called the acquirers
The software engineering organization that implements the system is sometimes referred to as the builder. The elaboration phase begins once the acquirers approve the project and the exit criteria are a specification of requirements and an architectural concept. The architectural concept describes a high-level design approach that addresses the requirements. The builders must sign off on the architectural approach before the elaboration phase is complete. The acquirers at this point can make a build/no-build decision based on the feasibility and initial cost and schedule estimates. The architecture is by no means frozen at this point, but the majority of architecturally significant quality attribute requirements, such as performance and maintainability, must be specified and the architectural approach must be established, as well as the technology to be used.

Management View

The construction phase begins with a specification of requirements, architectural concept, and project plan. It is during construction that the product is implemented, unit tested, and system tested. The architecture, requirements, and development plan are adjusted as necessary, but there should be relatively few surprises at this point. If there are a lot of unexpected surprises, then the quality of the artifacts needed as input to this phase becomes suspect. The output of the construction phase is a complete version of the product. The transition phase is where the product is transitioned to its users. This includes any manufacturing, delivering, training, and supporting. In in-house development, a product is said to be "in production." For commercial software, the product is "shipped." The released version of a product, called a product generation, may enter into a maintenance and support subphase where bug fixes are made and small enhancements may be introduced.

Software Engineering View

The engineering view of software development is nearly orthogonal (or perpendicular), to the management view. The engineering view represents a software development project as multiple chains of activities running concurrently and overlapping. This classic waterfall methodborrowed from the hardware design disciplineis composed of discrete engineering phases with the creation of a requirements specification to completion, followed by the creation of a design specification to completion, and finally a manufacturing phase. Input of each activity as a "what" and the output as a "how". The "how" of one activity becomes the "what" of the next activity in the chain. A customer requirement is a "what," and a functional specification of that requirement is a "how." A functional specification becomes the "what" of the design activity and the design description becomes the "how. In the RUP, the engineering view is concerned with the coordination of requirements analysis, design, implementation, and testing activitiesunlike the waterfall process. The engineering activities do not have to run in serial, one completing before the next. It is possible for them to execute in parallel. Each activity is activated in a sense when there is new input to process. In an iterative development model like RUP, each activity may be activated several times. In addition to executing in parallel, each activity may have a feedback loop to prior "upstream" activities, as in the discovery of an ambiguous requirement during design, or the discovery of a design flaw during implementation. In the RUP, these activities run in parallel, some starting earlier in the development cycle, and some ending earlier than others. The emphasis and effort involved in each activity vary over time.

Software Engineering View

Each software engineering activity maps to many phases of the management view.

During the inception phase there is requirements gathering and analysis and relatively little or no design, implementation, or testing. During elaboration there is an increased focus on requirements gathering, analysis, and architectural design. There may also be some prototyping development efforts as part of the design activity and this involves some testing as well.

During the construction phase the requirements gathering, analysis, and architectural design activities begin to taper off. The design, implementation, and testing phases are at their peak effort with design eventually tapering off and implementation and testing staying steady partway through the transition phase.

Engineering View

In this model, the design process is subdivided into four phases: product planning, conceptual design, embodiment design, and detailed design. These phases are sequential, but the activities within each can overlap. Each of these phases focuses on a different level of abstraction and a different set of design objectives. The term working principle refers to a candidate design approach such as a design pattern, architectural pattern, or algorithm that addresses some subset of requirements. There is a logical flow of information between the phases with respect to time.

The product development cycle begins with product planning activities. The output of product planning feeds the conceptual design activities. Conceptual design investigates details; if the details are inaccurate or incomplete, another cycle of product planning may be necessary. The output of conceptual design, working principles - candidate design approach such as a design pattern, architectural pattern, or algorithm that addresses some subset of requirements, feeds the embodiment design phase. The output of embodiment design is sometimes referred to as detail design in some software development communities, but to be consistent I include writing source code in the definition of detail design. The output of embodiment design feeds detail design. Embodiment design may include a detailed class hierarchy design, Interface Definition Language (IDL) files, and possibly some source code such as C++ headers for classes, or Java interfaces to use as guidelines or as a framework for programmers to use when implementing the application or system. Issues discovered during detailed design may require another iteration of embodiment design (which may require another iteration of conceptual design or even product planning).

Architectural View

The architectural view provides a different but complementary perspective to the management, software, and engineering design views. The traditional architect's role is to help the acquirer understand his or her needs more fully and accurately and to create an architectural concept of a system that is feasible to build, given available technology, resources, and time. For that reason in software development, the software architect may be part of the product planning team as well as the engineering team

Pre-design Phase

Regardless, the software architect may need to participate in product planning and the analysis and formulation of requirements as well as the creation of broad budget and schedule objectives by establishing the scope and scale of the project. The architect must listen to the acquirer and study the entire enterprise context in which the application for all types and let him make value judgments such as what features are and are not important in the application.

The architecture of a business application may need to take into account the information architecture of the organization, not just the information model of the application itself In addition, the application architecture may need to take into account the underlying IT architecture (application/Web server, DB, OS, or MW) before application architecture begins

Architectural View
Domain Analysis Phase

During domain analysis the software architect strives to understand as completely and accurately as possible the needs of the acquirers and users and the application domain and to document this knowledge. Sources of domain knowledge include domain experts, domain-related literature, and existing requirements specifications from earlier or similar systems.

This phase corresponds closely to the requirements analysis and specification software engineering activities. With respect to the management view, the bulk of domain analysis would occur in elobration

Schematic Design Phase

During schematic design, the software architect prepares the architectural-level design, which is specified in an architectural description. This design is depicted in high-level models that represent the behavior of the system, the information captured in and processed by the system:

the user interface and user interaction design the modular structure of the solution the technology needed to implement the system along with the rationales for the various design and technology decisions.

This phase involves a lot of communication between the architect and various stakeholders and reviews and evaluations of the design variations represented in the architectural description.

Architectural View
Design Development Phase

The design development phase focuses on refining the architectural description and selecting among alternative designs. The architectural description is evolved to the point where accurate schedules can be created. The schematic design and design development phases are often iterated and the boundary between them tends to blur as the architecture converges to a final design that is detailed enough to assess risks and to make a decision to proceed with development.

Building Phases

In the project documents phase the architect focuses on development concerns such as how the system should be constructed and in what sequence the components should be developed. During the staffing and contracting phase the architect may help the acquirer identify a development contractor or help with the creation of a development team using internal resources. The construction phase mirrors the phase of the same name in the management view. From the architecture perspective, the architect oversees construction ensuring that what is built is valid with respect to the architectural description.

Architectural View
Building Phases (Cont)

The architect is involved in design reviews and in the analysis of design problems uncovered as well as the handling of change requests. Even though the bulk of architectural design is complete, there is still need for the architect to make changes to the design and to assess the impact of those changes on the architecture itself and on the cost and effort of development.

The post-construction phase corresponds to the transition phase in the management view. The architect may assist in the deployment of the system and in training users. The architect may also remain involved with maintenance efforts.
Synthesizing