EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 142 of 197

The basic advantage of the spiral lifecycle is that the system is tested-early and often-so that fundamental flaws can be caught early when there is less rework to do. • Improve project predictabi li ty in terms of: • Effort • Calendar time • Communicate project information appropriate to different stakeholders If you have a process that doesn 't achieve these goals, then you have a bad process and should think about changing it for the be lte r. These goals can be ach ieved with a good process or they can be inhibited by a bad proces. So what's a process? In ROPES, we defin e a jJTOCeSS to be a seq uenced set of activities performed by a collaborat- ing set of workers resulting in a coher- e nt set of project artifacts, one of which is the desired system. A process consists of worker roles, the "hats" worn by workers while doing various project activities. Each activity results in one or more artifacts being produced. For example, most process- es have requirements capture (activi- ty) somewhere early on before design occurs. This is performed by someone (worker) acting as a requireme nts specifier (worker role ), and might result in a requirements speci fication, a set of use cases, and elaborating sequence diagrams (artifacts). A com- plete process wi ll have more steps than this, of course. The result is shown in Figure 1. For a process to be scalable, I mean that it can be used effectively on small one-person projects as well as on huge, distributed team projects with hun- dreds of developers. This is quite a challenge to achieve within a single process. ROPES does this by defining a set of core activiti es, worker roles, and artifacts, as well as many optional activities, worker roles, and artifacts. The most common mixtures of these are defined as a set of ROPES profi les, such as the Small-Team Quick Turnaround Profile, the Large Scale Safety-Critical Profile, and so on . Multi-Ievellifecycles Even though the waterfallli fecycle has been pretty resoundingly denounced over the last 20 years, it is still by far the most common way of scheduli ng and managing projects. The reason is that is it easy to plan and think about. But no project actually fo llows such a li fecycle , which leads to any numbe r of problems in me developme nt process. The basic difficu lty with the waterfall lifecycle is that defects introduced early in tile process are not identified or fixed until late in the process. By far, the most expensive defects are specification and arch itectural defects. The reason that these defects are so expensive is tllat tlle ir scope is far reaching and because many other sys- tem aspects end up depending on them. In order to fix such defects , it is necessary to also fix all the aspects of the sy tem that depend on those flaws. This is inherent in the waterfall li fecy- cle because testing comes at tile end. To reduce or remove the problems associated wim the simplistic waterfall lifecycl e, the spiral or iterative li fecycle has become popular. The basic advan- tage of the spiral li fecycle is that tJle system is tested-early and often-so that fundamental flaws can be caught ear ly when there is less rework to do. This is done by breaking up the devel- opment project in to a set of smaller projects, and scheduling them so that one such subproject builds upon and uses those that came before, and pro- vides a building block for those that wi ll come after. This is the "spiral. " Each subproject is more limited in scope, is produced with much greater ease, and has a much more targeted focus than the e ntire system. The result of each subproject or spiral is an i terative jJTOtotY/J(f-a f1.1I1 ctional, high- quality system that i not as comple te (or pe rhaps not done in as high fideli- ty) as the comple te system. Nevertheless, the prototype does cor- rectly implement some portion of the requirements and/ or reduce some set of risks. The ROPES process can be con- ceptualized as occurring simultane- ously in three different scales or time frames. The 1n([,cro~yde /JTOCf'SS occurs over til e course of many montlls to years and guides the overall develop- ment from concept to final delivery. The ROPES macro process has four prima ry, but ove rlapping, phases. Each macrophase actually contains multiple microcycles, as we will see shortly, and the I 'esull of each micro- cycle is the production of an iterative prototype. The microcycle is more limited than tile macrophase-usually com- pleting within four to six weeks. It is focused around the production and delivery of a prototype Witll limited function ali ty. This is most commonly focused around one or a small num- ber of u e cases, but may also include specific risk-reduction activi ti es. The nanocycle is tile most limi ted scope of all-on th e order of 30 min- utes to a single day. In the nanocycle, ideas are tried / mode led/ executed/ fixed at the I 'ate of several iterations per day. Figure 2 shows the standal'd ROPES lifecycle model. For a number of reasons, a true spi- ral model may not be palatable Ol~ practical for some OI'ganizations, often because of custome r milestone requireme nts (required adherence to DoD 2167A comes to mind) or because the busin ess climate is "uncomfortable" witll the notion of a spiml model. For tllese organizations, Embedded Systems Programming DECEMBER 2000 141

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13