Section 5.3. Software Development Processes

   

5.3 Software Development Processes

Perhaps the best way to help keep your project from failing is to work with a process or a methodology. There are a number of stages to typical software development, many of which may be similar to how you currently design Web applications.

Object-oriented application design exists to improve the productivity of each of these stages and to help make the most reliable system. There are many different software design methodologies floating around. These include the waterfall model, the iterative process, the rational unified process, and extreme programming.

5.3.1 The Waterfall Methodology

The waterfall methodology is not used as frequently as it used to be. In this method, the development process had several stages, each one with very distinct boundaries. The stages might look familiar:

  1. Gather requirements

  2. Analyze requirements

  3. Design system

  4. Write system code

  5. Test system

  6. Maintain system

The output of each stage becomes the input for the next stage. So in the above process, writing the code produces the output of the code base, which serves as the input for the next stage, testing the code.

Like many things in computing, this model is inherited from the world of industry. The waterfall model has its origins in the world of building construction. With this model, the stages are all predefined. The customer must sign off at each stage to ensure that everything completed so far is acceptable. Nothing is worse than completing a loosely defined project and having the client reject it or simply say, "I just thought it was going to be I don't know different. "

This process works well in theory. It also works well for projects with more than a few developers, when it is hard to keep everybody informed of every aspect of the spec along the way. This approach encourages definition and makes sure that things are well documented. It also encourages communication with the client, which is a good thing.

In practice, this process can lead to serious problems if you are working on a project that has new requirements for you or poses challenges you may not have tackled many times before. The reason is this: The waterfall method necessitates a denial of certain fundamental psychological truths about people: We make mistakes. We change our minds. Things happen. We forget something. The "artist's rendering" may not be drawn precisely to scale. What's worse is that you don't find this out when gathering requirements. You might catch a couple of things in the analytic stage. How many more snags lurk ahead, only to be discovered when you've already written 2,000 lines of code?

Another serious problem with the waterfall method is that testing happens very late in the process. This means that testing is not so much testing as it is a rote exercise in hoping for the best. If your test fails, you've got to take a completed system and rework it. Depending on what your test turns up, this could be a terrible detriment to your project.

The shortcomings of the waterfall method begot the iterative process.

5.3.2 Iterative Process

Iterative is like recursive. It means that as you develop, you go through the entire process repeatedly. Instead of deciding up front how everything is going to work and then doing exactly that until you hit a brick wall, you define things as well as you can, then do a little work, then check to make sure your analysis still makes sense, revise it if you need to, go back and do a little more work, and so on.

The stagesand the sequence in which they occur in an iterative process are just the same as the stages in the waterfall method. But in an iterative process, you allow yourself to go back to a previous stage and modify your work there. The clear advantage here is that your work, analysis, and design are all always based on your most current knowledge of the most complete model of the systemnot an artist's sketch from a far-off hill.

This process, as you can imagine, takes time. It takes longer to do some things two or three times than to do them once. The idea is that if you don't follow an iterative process, you're going to end up doing things over again in some way, and in all likelihood after you've rolled out the product. Then you're still taking the time, but now you've got disappointed users and angry clients .

5.3.3 Rational Unified Process

5.3.3.1 HISTORY OF RATIONAL UNIFIED PROCESS

In the early 1990s, Jim Rumbaugh was head of a team at the research labs at General Electric. One of the products of its work was a 1991 book called Object-Oriented Modeling and Design . Meanwhile, Grady Booch had been working on Ada systems with Rational Software and published books of his own on object-oriented methodologies. In 1994, Rumbaugh left to join Grady Booch at Rational. The idea was to merge their methodologies, which were composed of many complementary ideas.

At the same time, Ivar Jacobson had broken ground in the world of object-oriented modeling approaches by introducing the concept of use cases. The books Object-Oriented Software Engineering (1992) and The Object Advantage (1995) are good examples of his work. By 1995, Jacobson had joined Rational, and began working with Booch and Rumbaugh. The three renamed their work UML (Unified Modeling Language) and soon came to be referred to as "the three amigos."

In 1996, the Object Modeling Group (OMG) was formed . The purpose of the OMG was to ensure methods standardization and keep the work non-proprietary. In 1997 Rational released version 1.0 of the UML documentation to the OMG. Other organizations released their methods as well, and the OMG went about the arduous task of merging the proposals into a standard.

The three amigos' recent thought on the Rational Unified Process (RUP) is explained in The Unified Software Development Process (1999).

5.3.3.2 THE RATIONAL UNIFIED PROCESS IN A NUTSHELL

The RUP defines a number of different terms, some of which we have been tossing around with abandon in this chapter. These are examined specifically in Table 5.1. Each of the terms is part of the picture wherein workers do things for customers. Each thing that is done is measurable in some wayeither in relation to other artifacts (deliverables) or its place in a workflow, or because of the value it represents to a customer.

Here are the basic guidelines for running a project following the RUP:

  1. Determine the members of the team.

  2. Determine the system to build.

  3. Create a use case model. Create the user interface in prototype.

  4. Create an analysis object model.

  5. Create diagrams to represent classes, states, sequences (conventional UML activities that we'll discuss below).

  6. Determine the best architecture for the system. Assign classes to packages, and packages to modules.

  7. Test your system against the model described in your use cases.

  8. Transition to the live system.

Table 5.1. Terms in the Rational Unified Process

RUP Term

General Term

Definition

Activity

Task

A unit of work, performed by a worker, that creates a deliverable artifact.

Activity step

Subtask

A measurable, distinct step that is part of an activity.

Artifact

Deliverable

An artifact is a deliverable that is of use to a customer.

Iteration

Iteration

A planned sequence of activities that results in a milestone (a tested release).

Phase

Stage

The duration of a workflow.

Worker

Role

An agent in the development process who performs activities.

Workflow

Activity

A sequence of activities, wherein each is generally dependent on the prior, that produces a result of value to an actor.

Note

As a ColdFusion developer, you might be familiar with the term "Workflows" from Macromedia Spectra. The concept there refers to a number of loosely coupled tasks , which can either be done in parallel or in a sequence of dependencies. Same basic idea here. In fact, it could be said that Spectra was a crucial step on the road to CFMX. Consider that Spectra was an "object-based development" platform consisting of ContentObjects, which have properties and methods and are concrete instances of ContentObject Types. Sounds like objects and classes to me. Spectra was, among other things, an attempt to bring to ColdFusion the advantages of flexibility and separation of logic/presentation inherent in object-oriented platforms such as Java.


Perhaps the main difference between RUP and the waterfall method is that RUP creates a set of deliverables all along the project, and these deliverables are foregrounded.

There are a number of advantages to following the RUP. First of all, it is architecture-driven . This may seem strange given that determining the architecture is the sixth step in an eight-step process. However, so much time is spent in analysis determining how classes will interact with each other and what their responsibilities are, the code practically writes itself by the time you're done.

A common disadvantage cited with respect to the RUP is that it is tied to only one supplier, and that makes people nervous. It means that you have to figure into your budget the cost of acquiring the many tools you'll use to do the project. Moreover, the specification is more than 1,700 pages long. Reading that much is a lot of work and makes the process of developing software sort of take the focus away from the "real" workcreating a product for your customer. RUP is very detailed and complex. Many developers find understanding it an overwhelming task. There is support available for a fee from Rational, and there is training.

Many developers cite the formality of the RUP as a stifler of communication. It is rather likely that a team's communication would be greatly enhanced if every member had a complete understanding of the RUP. However, this is very often not the case. People have different backgrounds, different jobs in a project, are different stakeholders, etc. Short of this, communication in RUP can be very difficult.

There is, however, a lot that we can take away from the RUP, and we will therefore discuss use cases, classes, state diagrams, and the like in this chapter.

5.3.4 Extreme Programming

This is a style of programming that has received increasing interest since it was put forth by Kent Beck in Extreme Programming Explained (2000). XP is really two things: It is a set of guidelines about how to program, and these guidelines are based in a unique philosophy of programming.

The two chief goals of XP, as with many programming methodologies, are to improve the reliability of the programs you create and to improve your productivity as you write code.

There are two assertions of XP that have probably garnered the most attention: Program in pairs, and write the test cases first.

Programming in pairs means that the code for a project is written in teams of two. One programmer drives (writes the code), while the other thinks about the larger picture. This means that your team can achieve a meaningful balance between focusing on the details of the implementation and the overall program, including how the current piece fits in. Other benefits of this approach include the ability to really talk through the current challenges you might be facing it doesn't allow you to sweep minor annoyances under the rug quite as easily. It also keeps the project moving, because you cannot so easily move into corners of the program in ways that others will later find arcane.

Writing the test cases first addresses a common problem in software projects. Many software projects fail in part because the testing phase is inadequately addressed. Testing is often an afterthought or is the last item on the list of priorities. When the deadline draws near, projects are often pressed right up until the last minute to get the product out the door. When this happens, the tests can be hastily administered. Lamentably, many flaws found at this stage are often time-consuming and expensive to fix. Writing the test cases first means that you are writing code to the test, knowing what you'll have to pass. It is harder to overlook things like this, and this can even promote a more user-centric design.

The obvious disadvantage to XP is that it is not as mature, understood , or widely accepted as its predecessors from the 1980s and 1990s. It is difficult enough to get a complex project in on time and on budget, especially if new technology is involved. If there is resistance to this particular methodology by any of the members, you could have real problems. Because it is frankly stranger than other, more traditional methodologies, it could take some effort to get such a project moving.

One can quickly see why managers might discourage this manner of working: it seems less productive to have two people doing one job. What is perhaps less obvious is that it requires very knowledgeable, experienced programmers to really be able to do it and take advantage of its features. XP was not really envisioned for teams of more than 10 or 12. For very large projects, this method is not really workable .

Finally, XP does not produce any documentation. There is little provision for it, and as corporations find documentation increasingly important as their turnover rates rise, it is important to have a solid documentation structure in place for a project of any complexity. With XP, you're on your own.

Other key aspects of XP include the following:

  • Refactoring. Refactoring means evaluating your code and rewriting it for readability, performance, and efficiency. It means reworking a system to make it simpler. By having a testing framework already in place, this makes code refactoring rather clear.

  • Simplicity. This is a key aspect of XP. Anything that is not immediately necessary to the system working is not implemented. Of course, the simpler your system is, the less bug-prone it is, the easier it is to change, and so on.

5.3.5 Do It Your Way

There are certainly a wide range of attitudes when it comes to programming methodologies and how seriously people take them. The 1980s boom of programming methodologies was partly a response to a perceived increase in project failures.

There are a number of good books on various methodologies, especially UML, each with a slightly different approach, focus, and degree of detail. I encourage you to check a few of these out, and yet start now using everything that you already know about project management, discovery, and development. I have found that what one OOP designer means by "use case" is not precisely what another means. That's okay; we're working with (literally) about 45 different methods or method fragments for object-oriented application design (OOAD). You may find, depending on the kinds of systems you're used to building, that you have a hybrid approach of your own that works rather well.

The main thing, of course, is to stay focused on your project and its goals. It could be that the project is simple enough that you don't need to do much planning and can sit down and start writing code. You could be dealing with a sufficiently complex project that you spend two months just doing requirements gathering. These are different kinds of projects. Don't think that you need to go through some painstaking process of writing numerous scenarios when the project is relatively familiar and well understood. So please take the remainder of this chapter at face value and assume that some projects require more, or less, or simply different kinds of planning. If OOAD starts to cramp your style and you never sit down to write any code, something is amiss. Take a step back, and come at the project from another angle.

That said, it is a good idea to start relatively small and familiar as we begin discussing these concepts; it will be easier to get a handle on them this way.


   
Top


Java for ColdFusion Developers
Java for ColdFusion Developers
ISBN: 0130461806
EAN: 2147483647
Year: 2005
Pages: 206
Authors: Eben Hewitt

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