The Unified Process

The Unified Process identifies four phases and five workflows for completing a software effort. An iteration consists of the following four phases:

  • Inception Determine objectives that the software should meet and the tasks the software should perform.

  • Elaboration Design the solution that will fulfill the objectives.

  • Construction Code, document, and configure the software.

  • Transition Roll the code to production or deliver it.

Workflows are subordinate to a phase. Each phase could contain all five possible workflows:

  • Requirement collection Perform investigation for determining the requirements and objectives.

  • Analysis Examine the data gathered for the purposes of creating a design.

  • Design Design the solution.

  • Implementation Roll or move to the desired environment within which the solution should be executed.

  • Test Make certain the solution meets the identified requirements and objectives.

An Adaptation of the Unified Process

Because the Unified Process describes a generalized methodology for software development of any sort, this chapter presents a specific variation based on the Unified Process that has been used to produce web portal software. This process is based on the author's personal experience and has no further basis for acceptance other than the fact that it is a variation of the Unified Process. This process may be modified or changed to accommodate the specific environment, based on the needs of the parties involved.

At the beginning of any project, a scope is defined that describes an overview or summary of the desired outcome. If all parties agree to pursue the scope, a requirements gathering exercise will ensue, which results in a functional design. On completing the requirements gathering, a technical design will be performed to determine how to build the solution, resulting in a technical specification. The functional design can be referred to as defining the 'what,' and the technical design can be referred to as defining the 'how' of the solution. Once a solution is described in such a way that a programmer can build the solution, it is assigned to development to build and test against the technical specification. After development is completed, the solution must be tested against the functional specification. After the software passes the tests, it will be rolled to production and the project is completed. Figure 18-1 shows the overall process for building a web site.

click to expand
Figure 18-1: Overall process for building a web site

Many new methodologies challenge or enhance the Unified Process, such as Extreme Programming or Agile. These alternative methodologies offer the development organization many opportunities to optimize the process for building a software product. For example, Extreme Programming proposes such techniques as eliminating documentation, reducing the time of a development cycle, and coding in pairs. Elements of Extreme Programming are presented in the methodology discussed in this chapter, since they have been demonstrated to be effective in the web development effort.

Each step has a deliverable or set of deliverables that provide a basis for the efforts that will take place later in the project. For a software effort, deliverables are generally documentation or code. The scope generally results in a document summarizing the owner's expectations and an estimate for delivering a solution that meets those expectations. The requirements gathering process will result in a functional specification that describes the way the product should work and look. The technical design step results in a technical specification document. Development and coding will result in a unit-tested group of files that meets the requirements of the technical specification and an install program for the solution. The test product step will result in a document that indicates that the code effort produced a solution that meets the needs described in the functional specification. Finally, the deployment step should result in an invoice, an announcement to the user base, and product instructions.

Note 

Samples of the documents described in this chapter are available on the author's web site as mentioned in the book's Introduction.

The passing of deliverables among steps and teams in the software project is often the cause of great strife among the collaborating parties. A project's success is often dependent on the effective collaboration of sales, marketing, business analysts, and software engineers. Given the diverse background of these types of professionals, collaboration is often difficult to obtain. An effective strategy for producing greater synergy among professionals is to challenge all involved to act as though they are always serving the needs of an owner in the course of producing the deliverables. The measure of their performance is based on the satisfaction of the owner they serve.

For the software project team, their teammates are their 'customers.' For example, if the functional specification does not make the desired outcome clear to the software engineer reading it, the business analyst should improve the document rather than suggest that the software engineer is not astute enough to understand the document. If the installation of the software cannot be performed properly after it is coded, the developer who wrote the installation program or script should improve it so that the systems personnel can install the software without failure. In this way, the developer is the business analyst's customer and the systems personnel are the developer's customer. The responsibility for the recipient effectively utilizing the deliverable should be the measure of a professional's effectiveness to the team. If their 'customers' love their product then they are performing effectively. If this culture is established immediately in a software project, success will be more likely regardless of the interpersonal skills of the members on the team.

Another source of strife among parties involved in a software production process is the length of time it takes to produce the product. Typically, the longer it takes to produce a project, the more functionality and software is produced. The original requirements will likely change over time, so reducing the time of delivery will tend to reduce the likelihood that the owner's requirements will change and increase owner satisfaction. It will also reduce the stress among a software development team, because the total burden in moving or managing a single given effort is much smaller.

One might argue, however, that the owner sets the requirements rather than the development team. Attempting to reduce the length of time needed to deliver a solution can be satisfied only by reducing scope or increasing the labor supporting the effort. Clearly, the owner must set the requirements, so choosing not to deliver required functionality does not please the owner. The best way to manage this problem is to reduce scope but not the overall scope of the solution-that is, the project should be broken up into smaller projects. You still may not be able to complete the project within the time frame the owner desires, but you will be able to provide the owner with a plan for everything they want. According to the Unified Process, these smaller projects are called iterations. When all of the iterations are completed, the final project is delivered. Producing a project with several iterations, rather than a few, is the preferred manner in which a project should be executed. One big effort to deliver a piece of software is always more difficult and poses more risk than a series of small efforts that result in the same piece of software.




IIS 6(c) The Complete Reference
IIS 6: The Complete Reference
ISBN: 0072224959
EAN: 2147483647
Year: 2005
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net