A tradition waterfall, or V-cycle, development project proceeds stage by stage through a series of activities with this fundamental assumption: the work in each stage can be completed with no more than a few minor defects. This is the theory, at least.
Figure 1. Typical V-cycle process
However, based on project evidence, this is simply not true. If it were true, system V&V tests would pass the very first time, most of the time. Only occasionally would the system require any defect removals. And, very rarely would this require any serious work or cost overruns. That is not what we see with over 1/3 of projects being over cost and over time. A significant number of projects are so over budget that they are cancelled prior to completion.
Verification-at-the-end identifies problem defects at the end of the project. At the end of the project is when you expect to be finished. The cost is high for two reasons. Partly to identify and isolate the defect in the fully constructed system, but mostly to the large cost of throwing away significant portions of work products (requirements, architecture, design, code, test cases, etc) and redeveloping them. The cost of rework is the real killer of projects.
I believe that it is better to avoid defects in the first place rather than insert them early and fix them late. The question of how to avoid defects is the real issue. There are a number of practices that help you to do that:
- Test-driven development with high-fidelity modeling (TDD-HFM)
- Continuous integration
- Incremental V&V
- Continuous QA
- Continuous dependability assessment
Of these, I'll focus on TDD-HFM. All are important and remove defects before they become embedded in the system design. But I've found TDD-HFM of particular value. Test-driven development was developed in the context of agile software development as a means to avoid defects. The idea is to develop, and apply, test cases at the same time as you develop source code. This happens in very small cycles (which Harmony calls nanocycles) of 20-60 minutes. The goal is to never go more than this short period of time before you verify that what you have created (so far) is actually correct. This means that you take verification from the end of the process and make it a part of your normal hourly workflow.
Testing only at the end makes no more sense than only brushing your teeth on December 31 because "it's that time of the year." You can avoid dental problems with the application of continuous (or at least daily) hygiene. TDD is no more or less than hygiene for your system engineering work products. Hygiene is defined by Merriam Webster as "conditions or practices conducive to maintaining health and preventing disease, esp. through cleanliness." I think this definition is particularly appropriate to the development of engineering work product.
As systems engineer you must make work products that lend themselves to verification. See Tip #7 Requirements models avoid expensive defects for more information on this topic. This applies to most system engineering work products. If you want to have a good (complete, consistent, accurate and correct) set of requirements, build a verifiable requirements model. If you want to construct a good (optimal) architecture, build a verifiable architecture model.
While a big part of the answer, by itself it is insufficient. It is not enough to be verifiable; it must also be verified. The best way to construct a verified work product is to verify it continuously as it is developed. This test-driven development approach removes the vast majority of defects that otherwise remain dormant. They usually show up as a surprise to the development or testing team, or – in the worst case – the customer.
Consider the problem of constructing a defect free set of requirements. The workflow in Figure 2 shows how this can be done. The key to effectively executing this workflow is to keep the cycles short and focused.A cycle usually ranges from 20 minutes to an hour. For the inner requirements modeling loop this means that a small set of requirements from the use case:
- Update the execution context
- Manifest the requirements in the scenarios and functional flow
- Incrementally update the state machine
- Verify this update
If you have questions to ask the customer, or features you wish to demonstrate, you can expose the model (as a simulation) to the customer for evaluation and consideration.
Figure 2: Test-driven development-high-fidelity modeling workflow for requirements analysis
This leads us to the #1 hint for developing systems, stay tuned.
- Browse the Rational DOORS developerWorks page for links to technical articles and many related resources, and check the Rational DOORS Next Generation page on Jazz.net. For detailed instructions, explore the Rational DOORS Information Center.
- To learn more about the tool for collaborative, model-driven development for embedded systems, start with the Rational Rhapsody product line overview and the Rational Rhapsody page on IBM developerWorks. Also see the Rational Rhapsody 7.6 information center and the Changing the location of help content to get a local copy of the documentation.
- Explore the various versions, too: IBM Rational Rhapsody Architect for Software, a visual development environment for embedded systems and software
- IBM Rational Rhapsody Architect for Systems Engineers
- IBM Rational Rhapsody Designer for Systems Engineers
- IBM Rational Rhapsody Developer for collaborative, model-driven development of embedded systems. This edition is required for Eclipse users, and editions are available to create specialized projects in C, C++, Java, and Ada languages.
- To learn more about Rational Rhapsody design management capabilities, check out the IBM Rational Rhapsody Design Manager to see how to collaborate, share, review, and manage designs and models with the entire engineering team. Also see the Design Management page on Jazz.net.
- Explore the Rational software area on developerWorks for technical resources, best practices, and information about Rational collaborative and integrated solutions for software and systems delivery.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, anytime, and many of the Getting Started ones are free.
Get products and technologies
- Get the free trial download for Rational DOORS Web Access.
- Take an online tour of Rational Rhapsody with an online trial or download Rational Rhapsody or special editions to Evaluate, free of charge, for 30 days.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, or use it in a cloud environment.
- Join the Rational DOORS forum to ask questions and participate in discussions.
- Participate in the Enterprise Architecture and Business Architecture forum, where you can share information about methods, frameworks, and tool implementations. Discussions include tool-specific technical discussions about Rational System Architect.
- Join the discussion in the Rational Rhapsody forum.
- Get connected with your peers and keep up on the latest information in the Rational community.
- Rate or review Rational software. It's quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.