Software processes are software too
ICSE '87 Proceedings of the 9th international conference on Software Engineering
Object-oriented software engineering
Object-oriented software engineering
Addressing the essential difficulties of software engineering
Journal of Systems and Software
The Rational Unified Process: an introduction
The Rational Unified Process: an introduction
The unified software development process
The unified software development process
Proceedings of the ACM international conference on Object oriented programming systems languages and applications
A Comparison of Six UML-Based Languages for Software Process Modeling
IEEE Transactions on Software Engineering
Comparing two software design process theories
DESRIST'10 Proceedings of the 5th international conference on Global Perspectives on Design Science Research
A lean and mean strategy for migration to services
Proceedings of the WICSA/ECSA 2012 Companion Volume
| Hi-index | 0.00 |
Over the last 30 years we have tried very hard the rich process models approach, and we have not been extremely successful at it. Maybe we should try "lean and mean" software process models, rather than making them "richer." At minimum, we should try to analyze why the rich approaches have not worked; where they failed. Could it be that we were trying to solve the wrong problem? or that the real problems by far overshadow the process model issue? Or maybe the whole construction paradigm we use for software development is not suitable anymore? My position is that we should try the route of very simple software process models, to ensure a wider applicability, greater versatility, and acceptance. Possibly these new process models would be based on other paradigms of software or system development than the "technical-rational" construction idea. I would be wary of richer process models.