You do not want programmers writing code for your control systems without having software engineers working throughout the system’s life cycle (see the Comprehensive Systems Life Cycle Model graphic at the bottom of this post). Programmers only touch the end of requirements, coding, testing, some integration, and maintenance when their code breaks – and it will! Remember, the code doesn’t wear out – it’s delivered broken!
What can you do about it?
Understand that you do have a life cycle for the development of your assets. You need to recognize and define that life cycle. There are multiple life cycles for system development. The Comprehensive Systems Life Cycle Model is the one we usually recommend. Unfortunately, this is the lifecycle we typically see:
Using the lifecycle above guarantees your code will fail to meet your requirements and will NEVER function within the system to which it is tied.
To gain perspective, download The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide). It’s free and describes generally accepted knowledge about software engineering. Its 15 Knowledge Areas (KAs) summarize the basic concepts and include a reference list pointing to more detailed information. For SWEBOK Guide V3, we as editors received and replied to comments from approximately 150 reviewers in 33 countries.
Please feel free to send reach us, if you’d like more information. We’d be more than happy to chat, do a webinar lunch and learn for your team or just send you some more references.
Read the blog entries on our website – www.athensgroupservices.com, join our LinkedIn Group, and subscribe to our newsletter. If something strikes you as a deserving comment, please post your opinions on our LinkedIn Group.
Comprehensive Systems Life Cycle Model
This model applies to both homegrown and commercially acquired hardware and software. Note that the software engineer’s span of control includes the entire life cycle, while the programmer parachutes in to write some code and then exits.
