The Unified Process Elaboration Phase: Best Practices in Implementing the UP / Edition 1

Paperback (Print)
Buy New
Buy New from BN.com
$41.20
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (21) from $1.99   
  • New (6) from $46.22   
  • Used (15) from $1.99   

Overview

Is the Unified Process the be all and end all standard for developing object-oriented component-based software? Scott Ambler doesn't think so. This book is one in a four-volume series that presents a critical review of the Unified Process — designed to p

This first volume of a four-book series delivers a practical approach to defining, validating, and base-lining the architecture for a system. This series is designed to fill the gap between theory and practice with a software process that goes beyond the UP with details of development and production. Fill the gap between theory and practice! Implement a software process that goes beyond the UP with details of development and production. You get a master's collection of best practices from Software Development magazine experts. This volume delivers a practical approach to defining, validating, and base-lining the architecture for a system.

Read More Show Less

Product Details

  • ISBN-13: 9781929629053
  • Publisher: Taylor & Francis
  • Publication date: 1/4/2000
  • Edition number: 1
  • Pages: 277
  • Product dimensions: 7.50 (w) x 9.25 (h) x 0.64 (d)

Meet the Author

Scott W. Ambler started developing software in the early 80s, and has worked in object-oriented development for the past ten years in an array of roles. He is presently engaged as a software process mentor with AmbySoft Inc., a contributing editor

Read More Show Less

Read an Excerpt

Chapter 1: Introduction

What is a software process? A software process is a set of project phases, stages, methods, techniques, and practices that people employ to develop and maintain software and its associated artifacts (plans, documents, models, code, test cases, manuals, etc.). Consider the hunting process of Figure 1.1. Although I'm sure the X-Files will eventually provide an explanation as to why the Neanderthals became extinct, my theory is that the implementation of an inappropriate process such as the one presented is a likely candidate to explain their downfall. The point is that not only do you need a software process, you need one that is proven to work in practice, a software process tailored to meet your exact needs.

Why do you need a software process? An effective software process will enable your organization to increase its productivity when developing software. First, by understanding the fundamentals of how software is developed you can make intelligent decisions, such as knowing to stay away from SnakeOil v2.0 - the wonder tool that claims to automate fundamental portions of the software process. Second, it enables you to standardize your efforts, promoting reuse and consistency between project teams. Third, it provides an opportunity for you to introduce industry best practices such as code inspections, configuration management, change control, and architectural modeling to your software organization.

An effective software process will also improve your organization's maintenance and support efforts, also referred to as production efforts, in several ways. First, it should define how to manage change and appropriately allocate maintenancechanges to future releases of your software, streamlining your change process. Second, it should define, first, how to smoothly transition software into operations and support and then, how the operations and support efforts are actually performed. Without effective operations and support processes, your software will quickly become shelfware.

An effective software process considers the needs of both development and production.

Why adopt an existing software process, or improve your existing process using new techniques? The reality is that software is growing more and more complex, and without an effective way to develop and maintain that software, the chances of you succeeding will only get worse. Not only is software getting more complex, you're also being asked to create more software simultaneously. Most organizations have several software projects currently in development and have many more in production - projects that need to be managed effectively. Furthermore, our industry is in crisis; we're still reeling from the simple transition from using a two-digit year to a four-digit year, a "minor" problem with an estimated price tag of $600 billion worldwide. The nature of the software we're building is also changing from the simple batch systems of the 1970s for which structured techniques were geared, to the interactive, international, user-friendly, 24/7, high-transaction, high-availability online systems for which object-oriented and component-based techniques are aimed. And while you're doing that, you are asked to increase the quality of the systems that you're delivering, and to reuse as much as possible so that you can work faster and cheaper. A tall order, one that is nearly impossible to fill if you can't organize and manage your staff effectively. A software process provides the basis to help do just that.

Software is becoming more complex, not less.

1.1 The Unified Process

The Unified Process is the latest endeavor of Rational Corporation (Kruchten, 1999), the same people who introduced what has become the industry-standard modeling notation: the Unified Modeling Language (UML). The heart of the Unified Process is the Objectory Process, one of several products and services that Rational acquired when they merged with Ivar Jacobson's Objectory organization several years ago. Rational enhanced Objectory with their own processes (and those of other tool companies that they have either purchased or partnered with) to form the initial version (5.0) of the Unified Process officially released in December of 1998.

Figure 1.2 presents the initial lifecycle of the Unified Process made up of four serial phases and nine core workflows. Along the bottom of the diagram, you see that any given development cycle through the Unified Process should be organized into iterations. The basic concept is that your team works through appropriate workflows in an iterative manner so at the end of each iteration, you produce an internal executable that can be worked with by your user community. This reduces the risk of your project by improving communication between you and your customers. Another risk reduction technique built into the Unified Process is the concept that you should make a "go/no-go" decision at the end of each phase. If a project is going to fail, then you want to stop it as early as possible in its lifecycle - an important concept in an industry with upwards toward an 80-90% failure rate on large-scale, mission-critical projects (Jones, 1996).

The Inception phase is where you define the project scope and define the business case for the system. The initial use cases for your software are identified and the key ones are described briefly. Use cases are the industry standard technique for defining the functional requirements for systems, providing significant productivity improvements over traditional requirement documents because they focus on what adds value to users as opposed to product features. Basic project management documents are started during the Inception phase, including the initial risk assessment, the estimate, and the project schedule. As you would expect, key tasks during this phase include business modeling and requirements engineering, as well as the initial definition of your environment including tool selection and process tailoring.

You define the project scope and the business case during the Inception phase.

The Elaboration phase, the topic of this volume, focuses on detailed analysis of the problem domain and the definition of an architectural foundation for your project. Because use cases aren't sufficient for defining all requirements, as you'll see in Chapter 4 (which describes the Requirements workflow), a deliverable called a supplementary specification is defined which describes all non-functional requirements for your system. A detailed project plan for the Construction phase is also developed during this phase based on the initial management documents started in the Inception phase.

You define the architectural foundation for your system during the Elaboration phase.

The Construction phase, often the heart of software projects (typically to their detriment), is where the detailed design for your application is developed as well as the corresponding source code. I say that projects focus on this phase to their detriment because organizations often do not invest sufficient resources in the previous two phases and therefore lack the foundation from which to successfully develop software that meets the needs of their users. The goal of this phase is to produce the software and supporting documentation to be transitioned to your user base.

You finalize the system to be deployed during the Construction phase.

The purpose of the Transition phase is to deliver the system to your user community. There is often a beta release of the software to your users, typically called a pilot release within most businesses, in which a small group of users work with the system before it is released to the general community. Major defects are identified and potentially acted upon during this phase. Finally, an assessment is made regarding the success of your efforts to determine whether another development cycle/increment is needed to further enhance the system.

You deliver the system during the Transition phase.

The Unified Process has several strengths. First, it is based on sound software engineering principles such as taking an iterative, requirement-driven, architecture-based approach to development in which software is released incrementally. Second, it provides several mechanisms, such as a working prototype at the end of each iteration and the "go/no-go" decision point at the end of each phase, which provides management visibility into the development process. Third, Rational has made, and continues to make, a significant investment in their Rational Unified Process product (http://www.rational.com/products/rup), an HTML-based description of the Unified Process that your organization can tailor to meet its exact needs.

The Unified Process also suffers from several weaknesses. First, it is only a development process. The initial version of the Unified Process does not cover the entire software process; as you can see in Figure 1.2, it is very obviously missing the concept of operating and supporting your software once it has been released into production. Second, the Unified Process does not explicitly support multi-project infrastructure development efforts such as organization/enterprise-wide architectural modeling, discussed in Chapter 5 (which describes the proposed Infrastructure Management Workflow), missing opportunities for large-scale reuse within your organization. Third, the iterative nature of the lifecycle is foreign to many experienced developers, making acceptance of it more difficult, and the rendering of the lifecycle in Figure 1.2 certainly doesn't help this issue...

Read More Show Less

Table of Contents

Preface
Chapter 1: Introduction
Chapter 2: Best Practices for the Project Management Workflow
Chapter 3: Best Practices for the Business Modeling Workflow
Chapter 4: Best Practices for the Requirements Workflow
Chapter 5: Best Practices for the Infrastructure Management Workflow
Chapter 6: Best practices for the Analysis and Design Workflow
Chapter 7: Best Practices for the Test Workflow
Chapter 8: Parting Words
Appendix A: References and Recommended Reading
Appendix B: The Article Authors
Index
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Anonymous

    Posted July 21, 2000

    Practical Information

    So many process-oriented books, and so little practical advice. Fortunately, Mr. Ambler has consistently provided information that can be used. The articles in this book plus his excellent insight and commentaries continue that tradition. And if there is a subject that needs practical insight, it is the Unified Process; so if you can't have an experienced consultant around all the time, consider getting this book. [And the other UP phase books when they come out.]

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted June 29, 2000

    Great Resource Book

    Ambler's book really helps me to provide other's with references. I often find that I need help expressing a concept in some new way for someone who just doesn't get it. The essays and articles in this book are a great source of 'perspectives' that help me get the point across.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)