I use/used several for version control, architecture/scheme development, developers/engineers development environment, problem/bug tracking and auditing reporting.
The Professional Facilitator:
While there are many tools and applications for software control, many of them do not start with configuration management. As the question shows configuration management is not fully addressed (configuration identification, which begins with requirements (functional (capability), performance, non-functional) documented and specified but it does cover some design and implementation activities. As stated in the book, \”Software/Firmware Configuration Management (Within the System Development Process), Configuration Control is change management and control for the product(s), after having a baseline (approved document/specification) and establishing an entity to review changes to a system/product, its requirements/technical documents, and assurance that a change was implemented. This is configuration control and its activities after each configuration identification document(s) is/are put under control or mutually signed off by customer, user, project manager, and developer.
When we speak of requirements management, design management and change control, Configuration Management (CM) being at one time an engineering discipline (although many engineers did not like to document), accounts for management and control of the product and its development, production, and maintenance. So, although there are tools and applications that support configuration control, many do not address the full life cycle and activities for CM. There are some companies/vendors that are currently addressing this deficiency. The November Newsletter will identify some the companies/vendors that have commercial products for configuration control.
How did we all make the above mistake? Because in the beginning the \”best practice\” processes (identified in the September Newsletter and the author\’s book, \”Software/Firmware Configuration Management\” were a part of a successful system and hardware development environment. Software came along but could not be controlled in the same manner because it was a non-tangible product; within the computer, on tape, and documented in listings. Now, the objective was not only control specifications and documents but the compute files, and how to guarantee authorization, data integrity, and access control for products being developed (like hardware, during the system research and development (R and D) process). R & D, the basis of successful aerospace, DOD, and commercial Information Technology (IT) project\’s development process methodologies.
That is when some vendors/companies developed programs and applications to automate the CM process but many did not begin with requirements. Instead many began with design and implementation because they did not understand configuration identification. They thought or interpreted it as control of the product\’s structure/units/components (which in hardware terms was the architecture and implementation and identification scheme; is part/labeling identification). Oops, but that was not specifying the functional (characteristics) requirements (which is described within the definition of \”configuration\”). Configuration is defined as the functional (requirements) and physical (design) characteristics.
And now you know why we are where we are. Software and Firmware Configuration Management always begins with requirements, if not you are not doing CM, although you may have automated one or more of its activities. If you remember many failed projects, some did not have a complete specification of requirements and sometimes the high level or architecture was not documented (some project managers and developers saying, we will get to it (specify/document later). I would/will not accept that method/intent for any of my projects as a Program or Project Manager having overall responsibility. Notice I said the Program Manager having overall responsibility because there were times in the beginning of my project management career that I was project manager/lead for one of the processes (e.g., software configuration management, software quality assurance) but not the overall project and program for the system or software being developed. And although I may have had a successful career as a program and project manager, all my projects had risks and challenges. Lessons learned, and documented.
Leave a Reply
You must be logged in to post a comment.