IEEE S2ESC Meeting Notes
Standards Development Practices
The IEEE Standards Association is developing a new Style Guide (and standards document template) for 2005. This will impact how standards need to be structured and expected content in any new or revised standards once the Guide (and template) are finalized. The IEEE SA may also be changing its editorial toolset so MSWord becomes the fundamental tool for editing standards documents (even if they are converted to another format for production and, finally, to a PDF document). Standards editors/chairs will need to supply draft graphics in both non-editable format (e.g., TIF or one of a few other common formats) and original source (in whatever tool was used to great the graphic). This will allow them to archive both so the latter will be available to future revision efforts.
The S2ESC Executive Committee decided that a requirement needs to be communicated to all Working Group Chairs that future standards revision/development work must describe how they conform to both IEEE 12207 and 15288 (just adopted by S2ESC as their system lifecycle framework standard) or where there are exceptions.
The SEI liaison to the S2ESC noted that the next incremental release of the CMMI material will be a combined “book” with both models but no major changes (e.g., no added PAs). Version 1.2, though, will likely have a Safety and Security Process Area added. There has been some strong urging from the Department of Defense to eliminate the Staged version, but that is not currently planned. During S2ESC discussion it was noted that, if you look at CMMI from an improvement perspective, you want to use the Continuous model. However, levels in the Staged model help less mature organizations focus initial improvement effort and, thus, have value.
Safety and Security
Joe Jarzombek, the DoD liaison, will be moving to a Department of Homeland Security position in mid-March. Up to now, he has been the Deputy Director for Software Assurance in the Information Assurance Directorate for the Office of the Assistant Secretary of Defense for Networks and Information Integration. This new position will mean an expanded scope of his assurance focus to include critical infrastructure concerns in telecommunications, utilities, energy, financial systems, and, perhaps, identity theft/fraud.
In discussion of assurance (i.e., safety and security), the Department of Energy liaison noted that they use the CSQE as one type of recommended certification for those developing software related to high integrity/assurance systems. The subject of safety and security is an area, though, where they have to go outside the CSQE to get the coverage they need. The same was suggested with regard to the Software Engineering Body of Knowledge (SWEBOK). The IEEE may look into adding safety and security to the SWEBOK in some form. Perhaps the ASQ Software Division should consider where and how to address this in the CSQE BoK.
Process and Best Practices
One of the guest speakers on the second day of the meeting was from the Fraunhofer Institute at the University of Maryland. The DoD has funded a Best Practices Clearinghouse data repository where people can report their experiences using various practices, methods, processes, etc. As with any repository of “reusable” information/artifacts, there are issue of categorization and searching to be addressed. But most of the time on this topic was spent discussing “vetting” of experiences. There was some concern that most people involved in this were academics, not practitioners, hence the judgment of what evidence existed to claim a successful (hence “best practice”) experience would be different than what a practitioner might expect. There was also some discussion of “tailoring” guidance, i.e., how one might take the experience and apply it in a different context (and, indeed, whether the experience data would indicate whether one should expect to even do so).
Other (non-Clearinghouse) discussion addressed the need, not for specific practices to be used, but for artifacts as evidence of whatever process was followed. That is, what an assurance approach would be interested in, for example, would be to see whether the results could be shown to meet certain expectations, regardless of the process used to get those results. Hence, perhaps, instead of best practice processes, one should focus on best practice artifacts, i.e., the “best” evidence is of what happened, not how it happened.
Specific Standards Efforts
Vocabulary - The IEEE S2ESC had offered up an international editor for the ISO/IEC effort in SC7 to produce a consolidated vocabulary. That person could not be available and another person will have to be found who could lead the work to develop a new international system and software engineering vocabulary (which the IEEE S2ESC would then consider adopting, replacing the existed IEEE 610.12 vocabulary document).
IEEE 1044 (on anomalies, i.e., defects) - David Card is the Working Group Chair for this effort and he will be turning the standard into a Defect Causal Analysis process standard, taking the existing defect taxonomy and making it an appendix. Previously the taxonomy was the standard.
IEEE 730 (on software quality assurance ) - The standard, when its revision begins later this year, may need “lightening up” to match IEEE 12207 as 12207 is “lite” on the SQA since it builds QA into processes through PDCA improvement expectations. Also, 730 needs a link to (what will become) the IEEE version of ISO 90003. Ron Dean is the planned WG Chair for 730; Keith Middleton is the S2ESC Management Board Representative.
IEEE 1648 (on agile methods) - It was suggested that this work, needs to address those aspects of 12207 and 15288 not addressed by agile methods. It was considered of significant value for the standard to do this. This will be something new to be added to the work of the group. The issue will be presented to the Working Group along with information on process goals and outcomes as many from the agile community may not be familiar with the content and structure of 12207 and/or 15288.
Official minutes of S2ESC Meetings
Minutes and some of the presentations given at S2ESC face-to-face meetings and telecons can be found at http://standards.computer.org/sesc/s2esc_excom/minutes/minitndx.htm.
As always, those interested in any of the topics mentioned above, or other standards-related issues, can contact Scott Duncan by email (email@example.com or firstname.lastname@example.org or email@example.com or firstname.lastname@example.org) or phone (706-649-2345 (weekdays), (706-562-1256 (evenings and weekends)).