Wanneer Cleanroom / RUP gebruiken?

[Reveller]

*Afgesplitst van Software ontwikkel methodiek; ik zie niet waarom je hier een 3½ jaar oud topic voor moet schoppen En meteen extra-gratis een schop naar SEA.*

Ik schop dit oude draadje even omhoog omdat ik mij iets afvraag over RUP en Cleanroom, waar ik sinds gisteren over aan het lezen ben

Wat ik van Cleanroom weet, is ondermeer het volgende (copy-paste vanuit mijn aantekeningen):

Intended to produce software with a certifiable level of reliability. Defect prevention, rather than defect removal; the final product is near defect-free with a scientific certification of reliability. Team reviews replace testing (e.g. compiling) by developers for the purpose of finding defects. This has proven to be more cost-effective (resulting in less defects in the code).

Nu het volgende. Stel dat je de software moet ontwikkelen voor een grote energie leverancier. De software is mission-critical; het zorgt voor de aan- en verkoop en de versturing van energie naar huishoudens. Als de software faalt, zijn vele huishoudens de dupe.

Gebruik je in zo'n voorbeeld dat automatisch Cleanroom? Of kan het best zijn dat er RUP (of een ander framework) gebruikt wordt? Ik lees namelijk tegenstrijdige berichten: Cleanroom zou allang begraven zijn (en het boxing model al helemaal); Cleanroom zou springlevend zijn bij de bouw van de Spaceshuttle, etc. Kan iemand wat duidelijkheid verschaffen?

[ Voor 17% gewijzigd door RobIII op 01-10-2010 02:26 ]

[Avalaxy]

Een aanrader die ik hier nog niet voorbij heb zien komen is AUP. Dat is een meer agile versie van RUP. Het is gebaseerd op het 'just barely good enough' principe, wat neerkomt op onder andere geen eindeloze documentatie. Er is een hele theorie over, wat betreft de hoeveelheid tijd je in documentatie steekt, en de extra benefit die het heeft om er nog extra tijd in te steken. Volgens AUP is dat een soort bergparabool, waar de meest efficiënte manier dus in het midden zit (bij de top).

Ik zal het verder niet teveel uitleggen, maar iedereen die RUP interessant vindt maar het net iets te zwaar vindt moet zeker even een kijkje nemen naar AUP:
http://www.ambysoft.com/unifiedprocess/agileUP.html

Overigens:

RiCk schreef op donderdag 29 maart 2007 @ 08:54:
- RUP
RUP is cool. Maar RUP is zwaar, ik heb niet zo'n zin om de mensen eerst een UML cursus te gaan geven oid.

Bij AUP is het dus ook zo dat je dit niet eindeloos gaat modelleren in UML... Een globaal klassediagram in UML en/of wat CRC diagrammen zouden moeten volstaan, je applicatie reverse engineeren naar UML kan later nog

Zie ook http://www.agilemodeling.com/artifacts/crcModel.htm

[ Voor 27% gewijzigd door Avalaxy op 26-09-2010 01:44 ]

[Reveller]

@Avalaxy, je schijnt er wel wat vanaf te weten. Zou je wat op mijn vraag in kunnen gaan?

[Avalaxy]

Oh sorry, ik had niet door dat het al zo'n oud topic was, ik reageerde meer op de TS en andere reageerders die over agile begonnen.

Ik heb geen ervaring met Cleanroom, dus daar zal ik niet veel zinnigs over kunnen zeggen In principe denk ik dat iets als RUP prima zou moeten volstaan in combinatie met een strenge set black box/white box/unit/etc. tests bij elke iteratie van je product. Gewoon beginnen met het dichttimmeren van de security en dit ook door derden laten testen

Maar wellicht is dit precies wat Cleanroom voorschrijft, ik denk dat je dat zelf beter kunt beantwoorden