7.1 The Usual Suspects

   

Any book or article that discusses the software life cycle always starts with a critique of the classic waterfall life cycle as shown in Figure 7.1.

Figure 7.1. Waterfall life cycle.

graphics/07fig01.gif

Life-cycle models are meant to show the progress of a basic project from inception to delivery and beyond. The waterfall was one of the first models documented. However, it did not take long for this model to prove unattainable. On the face of it everything looks fine, but it requires each stage to be complete before the next stage can start. Requirements change, design changes, implementation and unit testing can show problems that generate change, and risks are not catered to.

Let us now race ahead and look at that life cycle that is touted as the best alternative, the spiral life cycle that is shown in Figure 7.2.

Figure 7.2. Spiral Life cycle.

graphics/07fig02.gif

As you can see, the spiral life cycle is, well, spiral. The main difference is the adoption of risk analysis. If risk of any kind did not exist, then fairy tales would abound. Our problem with this model is that apart from making us dizzy, it is quite complicated. However, along the project's path of progress risks are there to trip us up.

The risks could be:

  • Market forces change the requirements.

  • It's a new product and the final design is not nailed down.

  • The project needs to adopt cutting edge technology that we have not used before.

  • New information only comes to light due to results gained in initial testing.

Does this mean we should forget all the traditional specifications writing and just concentrate on risks? No, it means we adapt and use what works for us. We, the authors, can only tell you, the reader, what we use and how it works. What we use is constantly evolving, but the fundamentals are watertight. You must develop the design and construct the software to absorb change. When change or risks rear their ugly heads, you have to evaluate the impact it is going to have, and if necessary, modify your design. You must be flexible.

What is it that enables us to design and construct code in LabVIEW that is able to embrace change? You have already heard this enough I'm sure, but it is cohesion, coupling, and information hiding implemented in a component oriented design. Drum roll . . . smoke . . . lights . . . trumpets . . . LCOD!

We stay away from the big bad wolf due to implementing everything we discussed previously. It is impossible to absorb risk if you have a poorly designed, shabby, rigid set of software. The only way to absorb change is to design your system using the much discussed rules: cohesion, coupling, and information hiding. If VIs A, B, and C are closely related , it is pretty obvious that any change to VI A, as a result of a change in requirements, may well have an effect on all the other VIs. Multiply this by hundreds of VIs and your project will not be flexible.

So, to make our project successful we are going to use LCOD. Perfect, great, we are off to work only on successful projects. Hang on though, that's still not enough.

Software engineering as a subject has evolved immensely through the decades, but the basics still apply. So what life cycle do we use? Our own, although we've borrowed from all the others. We will call it the LCOD Prototype Life Cycle. Actually, we don't have a name for it, I just made that up, but basically it looks like Figure 7.3.

Figure 7.3. Prototyping life cycle.

graphics/07fig03.gif

It looks quite complicated. However, it isn't. At every stage we build or reuse prototypes. Each stage can go on to the next stage or back to previous stages. What we want to end up with are prototypes that have been proved and validated , the sum total of which will make up our final application. Everything pivots around prototyping. LabVIEW as a language is perfect for this, and nothing will build more confidence in the system and your customers than seeing working prototypes that prove the goal can be reached. These will provide convenient milestones. Should you use this model? Maybe, but the main thing to grasp is to keep prototyping and refining.

Do we still write all those reports ? Yes, most of them, but they are always a work in progress. That doesn't mean that they are never finished, but that they document both what was understood at the start of a project and what was learned as the project progresses.

The process of continually documenting the project gives everyone the clarity that is needed to ensure that every person knows what stage he or she is at. The collective set of documentation provides the map to ensure that everyone arrives at the final destination. If everyone has a different map, or even worse no map at all, how will everyone know where the end is, never mind how to get there!

All the latest available information states that you should plan with changing requirements in mind. Requirements will evolve and we need to adapt to this fact.

So, armed with LCOD, how do we ensure that a project is successful? The basic starting point is project documentation, which most people hate writing or reading, but they should be embraced. Does that mean we need to write War and Peace? Hopefully not. Try and write the minimum that is required, not the maximum. Next we'll discuss what documents we use.


   
Top


A Software Engineering Approach to LabVIEW
A Software Engineering Approach to LabVIEW
ISBN: 0130093653
EAN: 2147483647
Year: 2003
Pages: 66

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