On Systems Development Life Cycle (SDLC): Several Inconvenient Facts for Discussion
- Category: Systems Development
- Published on Sunday, 17 February 2013 19:52
- Hits: 2673
The purpose of this short article is to trigger discussion about Systems Development Life Cycle (SDLC) and to serve as a research agenda. SDLC is defined as the series of changes of a system from its creation and development to its productive state and final withdrawal.
Assuming that the SDLC model pictured above and its building blocks (or factors that impact SDLC) are self-explanatory, I offer several facts about SDLC that people often find inconvenient because these particulars do not fit simplified views of systems development. These properties are also generators of risk and, if not mitigated, can cause systems development endeavours to fail.
1.Systems development is context dependent; the optimal approach or methodology must be tailored to fit the specific organization, people, culture, technology, market, etc.
2.Systems develop all the time; they may evolve or devolve. After all, could you think of an example of a system that has never been changed, modified, updated, or upgraded?
3.The goal of the Systems Development Process is to determine the order of the stages involved in systems development. We have to move on from the process paradigm and focus on the quality of the system. Relying on the process of SDLC is like believing that superstitious objects can bring you success.
4.A successful team can deliver no matter what SDLC process is used. An unsuccessful team cannot deliver either way, regardless of the SDLC process.
5.Each and every initiative changes the system; only the impact may vary. These initiatives include programs, projects, systems iterations, releases, enhancements, patches, ad hoc changes, insourcing, self-sourcing, and outsourcing.
6.People have to change their behaviour and focus depending on the phase of the SDLC; for example, development of a new systems architecture requires different behaviour than development of a new release architecture.
7.Reusability of systems structural blocks should be the goal; that is, if reliable resources are involved in the systems development endeavour, the effectiveness and efficiency of the system will be much higher. Reliable resources include smart people who can work together and create high-quality reusable systems building blocks (e.g., strategy, architecture, or very structured code).
Let me know what you think. Do you agree or disagree? How would you support or challenge these facts?
References:
Boehm, B.W., TRW Defense Systems Group (1998). A spiral model of software development and enhancement. Los Alamitos, CA: Computer, 21 (5), pp. 61-72. Retrieved from http://weblog.erenkrantz.com/~jerenk/phase-ii/Boe88.pdf.
Polovina, R., Wojtkowski, W. (2002). Reusable Abstract Design as a Knowledge Repository: Its Utility in Software Intense Systems for the Networked Enterprise. Orlando, Florida: World Multiconference of Systemics, Cybernetics and Informatics (SCI)
Rubina Polovina, PhD is a principal IT consultant who has been providing leadership on national and international multi-party initiatives in the public and private sectors. During more than 20 years in the IT industry, she contributed to projects in Europe, North America and in the Middle East. Currently, Rubina lives and work in Toronto, Ontario. Rubina's research interests include enterprise architecture, knowledge management, IT management, IT project management, IT risk management, privacy protection, social networks and eHealth. Rubina’s scientific work has been both tested across various vertical industries and presented on peer-review international conferences. Rubina graduated in electrical engineering in 1987 from the University of Sarajevo, Bosnia and Herzegovina, and she received her PhD in computer science and engineering in 2000 from the Czech Technical University in Prague, Czech Republic. Contact: This email address is being protected from spambots. You need JavaScript enabled to view it.