50 likes | 174 Vues
In an era where over a thousand software development methodologies exist, the challenge for organizations lies in choosing the right one. This article explores the proliferation of methodologies like Scrum, RUP, and XP, highlighting the common pitfalls and flaws associated with them. It discusses the tendency of organizations to either ignore methodologies or apply them in an ad hoc manner. By examining the characteristics and shortcomings of these methodologies, we aim to shed light on how to effectively manage software projects while remaining adaptable to ever-changing requirements.
E N D
Methodology-free software development: Why having hundreds of methodologies? Herwig Mannaert
Which Methodologies ? • More than 1000 exist... • BON, Booch, BOOM, Catalysis, CBD/e, Coad/Yourdon, COMMA • CRC, Convergent Engineering, Demeter, DOORS, DOOS • EPA, EROOS, Fusion, Goofee, HOOD, IDEA, ION, KISS • MERODE, MOSES, MWOOD, Object COMX, Objecteering • Objectory, OEP, Octopus, OMT, OOAD/OOIE, OOA/RD, OOBE • OOCL, OOHDM, OOram, OOSC, OOSD, OOSE, OOSP • Open, OSA, PAUD, ROAD, ROPES, RUP, Scrum, Skill-Driven Design • SDL, Shlaer & Mellor, Softstar, SOMA, SOMT, Syntropy, XP • Which one do we use ? • The “methodology jungle”...
Adoption of Methodologies • Huisman & IIvari, 2002: “Many organizations claim that they do not use any systems development methods.” • Riemenschneider, 2002: “Only about half of all organizations actually follow a methodology” • Interpretation • Explicit use • Implicit use • Ad hoc
Common Flaws of Methodologies • Most methodologies manage the process: • “Managing the process is what you do if you cannot manage the product.” • Example: assembly lines in manufacturing • Most IT projects are/should be closer related to manufacturing than to R&D. • Example: management training programs VDAB • State-of-the-art design principles are defined informally and leave room for interpretation • Example: coupling, cohesion, and information hiding
Common Flaws of Methodologies • Most methodologies implicitly lead to a one-to-one functional-to-constructional mapping: • In engineering this mapping is many-to-many: requirements are global constraints for the design • Example: specs vs. parts in a car engine • This creates the evolvability challenge: ever changing requirements imply design for change • Example: upfront design of basic changes • Key design activities/decisions are described informally and left over to individual designers • Example: generalization, granularity