The Typical Software Development Lifecycle

Chapter 6 - Documenting the Project
byAndrew Filevet al.?
Wrox Press ©2002
Team FLY

Regardless of what kind of software you are building or what industry you may be working in, there exists a common set of steps or stages that most development projects follow. Of course project size and scope, the style of project leaders and developers, and other environmental and cultural factors have a significant impact on the structure of a development project. In quite a few software development organizations, proprietary methodologies exist, but you'll probably find that the UML still applies to those methodologies as well. At some level of detail, your experiences will certainly vary in some way from the basic steps we'll discuss here. For the most part, however, software development projects do indeed share the same general progression of figuring out what the software has to do, how it will do it, how the software will be tested and rolled out, and some kind of post-rollout production support phase. We'll get into more details of each these general stages as we discuss the role of UML and Visio throughout the project.

The diagram opposite contains the order and general process flow of common, major software development stages. We'll organize our discussion of the UML and Visio around these major steps as the rest of the chapter unfolds.

click to expand

The diagram illustrates the following nature of most common development methodologies. That is, one major project step depends on the output from an immediately preceding stage. In practice, however, it is possible and not uncommon to see project stages repeat, particularly early requirements, and architecture stages. Projects are also organized to repeat groups of stages in order to design, develop, and test portions of the entire project. That approach generally minimizes risk and helps get applications into users' hands faster.

Requirements Development

After an initial approval process that varies by organization, one of the most difficult stages of any development project begins - determining what exactly is to be developed, how it will be used and why. More times than not the stage is called requirements analysis or requirements development. At this stage, the project team has to decide what the software will do. Most of the input for requirements is from application users and others directly familiar with the problem or task the software will address. The output of this stage is some kind of description, a requirements document of how the software should work, who the users are, and some characteristics of each user group.

Architecture or High-Level Design

At this stage, requirements are translated into high-level designs - designs without much constraining technical detail, designs that work out high-level issues including integration with other applications, supported computing platforms, and so on. Many decisions made at this stage of a development project are critical to the success of an application and the issues that must be addresses are numerous. At this stage we are beginning to define how the software will deliver on requirements we've already developed. Input into this stage comes mainly from gathered requirements and other details from sources that include applications with which the new software will interface, environmental constraints, etc.

Detailed Design

Once a broad architecture is developed, the task of detailing much of the application's design begins. Often a difficult process, fundamental requirements and architecture issues haven't been entirely worked out; this stage is where we first see flaws with a technical approach to our applications. The final 'how' of a software project is worked out in this stage. 'How' in terms of how we will meet the technical and business requirements we've already identified. Inputs into this stage are requirements documents and architecture documents and the individuals who prepared them. Expected output from this project stage is typically documents and diagrams detailed enough to hand to a developer familiar with the project to produce code.

Coding/Implementation

This stage is where the rubber meets the road, so to speak. All of the work of defining requirements and architecting designs has to come together into database structures, code and components, and other physical stuff. The first true test of a design comes here. Developers will begin implementing a design and its ability to ultimately deliver will be proven. We often see hurriedly organized staff meetings to figure out code workarounds or solve problems that weren't anticipated in earlier architecture or detail design stages. I know because I've organizing those meetings many times! Coders will be working directly from design documents produced in earlier stages of the project. Of course initial requirements and architecture documents play a role by providing background and high-level descriptions of the application being developed.

Testing/Quality Assurance

The testing stages of a software development project shouldn't have a formally defined start and a defined end. Testing and other QA activities should permeate the entire project. That's not always the case, of course, but it's a good habit to start from the beginning of any new project. One theme you'll see explored in more detail later on in this chapter is the idea that early technical documentation (UML or something else), if done well and shared, has a direct impact on the effectiveness of any subsequent testing work. The biggest input into a testing stage is code, of course, but we also find testing and QA groups relying heavily on requirements documents and other design documents, particular for complicated processes. It's here where we first encounter the issue of ensuring a software process behaves exactly as designed and also testing that the design behaves exactly as the requirements state. More than once a developer has coded a piece of the application beautifully, then finds that the details they were using to build their code were faulty when testing against initial requirements.

Rollout

If you've ever written an installation script for a moderately complicated application, you'll understand the importance of good rollout planning and documentation. The success of a software rollout is often proportional to the amount of effort expended early in the architecture and design stages.

Support/Maintenance

Software designed and built with the "end in mind" generally has a better chance at succeeding in the marketplace than designs that didn't consider support and maintenance issues. These issues can include ease of updates, extensibility, and adaptation to new environmental conditions, customization by users, etc.

Interestingly these same steps are generally present in the smallest and the largest of development projects. Whether you're building a small utility for which the requirements are in the head of one developer and the testing and rollout stages are performed by that same person or you're working as one of dozens of developers on a larger application that might take years to implement, the basic process is similar. What we need to do know is identify how Visio and the UML can play a role in the development of software regardless of scope or project size. That's what the rest of this chapter will focus on.

Team FLY


Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects
Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects
ISBN: 1440490856
EAN: N/A
Year: 2001
Pages: 85

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