Below are comments received on the draft revision for Level 3 to the SPI Chapter for DFAS 8000.1-R:

COLUMBUS - Feb 10, 99

E.C6.1.2 Rewrite first sentence as follows:

"The SPI program is a single program across DFAS, rather than independent programs at each SEO and I&T."

E.C6.2.2.1 Delete

E.C6.2.2.2 through E.C6.2.2.2.2.7 Delete and replace with the following: "The SW-CMM can be expressed as a series of process groupings which, once established and used, provide for achieving a "Level" of process maturity. There are 5 milestone "Levels" used by the SW-CMM as stages in maturity with a continuous process improvement infrastructure being the 5th or Optimized Level. The levels currently being addressed are Levels 2 and 3.

These levels each have key process areas, some of which require that a policy exist. The SW-CMM usually states that each project should follow an organization policy. This is to emphasize the connection between organizational commitment and the projects that actually perform the work.

The applicable policies used at DFAS are shown below:

Appendix 1: Requirements Management
Appendix 2: Project Management
Appendix 3: Software Subcontract Management
Appendix 4: Software Quality Assurance
Appendix 5: Software Configuration Management
Appendix 6: Release Management
Appendix 7: Organization Process Focus and Definition
Appendix 8: Training Program
Appendix 9: Software Project Engineering
Appendix 10: Intergroup Coordination
Appendix 11: Peer Reviews

E.C6.2.2.3 Rewrite last sentence as follows: "Any tailoring of the standard process by AISs must be performed in accordance with documented tailoring guidelines."

E.C6.2.2.3.2 Combine first two sentences as follows: "SEPGs at each I&T and SEO will support the AIS managers in implementing scenario processes."

APPENDIX 2 - Project Management Activities Paragraph 3.a. and 3.h.: Combine and rewrite as a new paragraph 3.a as follows:

a. Each project will document its defined software process by tailoring the organization's standard software process. Each project will then plan and manage, and perform its software activities, in accordance with their defined software process. The project's deviations from the organization's standard software process are documented and approved.

APPENDIX 8 - Training Program Paragraphs 4 through 4.k: Most of the first sentences add little value to the paragraphs because subsequent sentences repeat them and add who is responsible for what. I suggest rewriting all paragraphs. To show an example, paragraph 4.a. should be rewritten as follows:

The ISO Systems Management Directorate (SMD) will define and maintain core competencies for all standard FSO software engineering, managerial and support roles. The automated information system project officer will define competencies for project unique roles. The Director of FSA or DSE will approve the unique roles.

APPENDIX 9 - Software Product Engineering

Paragraph 3.c:
Delete first sentence.
Make last sentence the first sentence.

Paragraph 3.e: It's unclear to me what is placed under configuration management?????

APPENDIX 11 - Peer Reviews

Paragraph 3.c: Rewrite as follows:

Trained peer review leaders shall execute the following responsibilities: identify the objectives, principles, and methods of the peer review, etc. etc.

Paragraph 3.e: Delete sentences two and three **OR** move to end and treat like the list of standard work products.

Also see general comments in Policy comments.

INDIANAPOLIS - Feb 9, 99

E.C6.1.1.2. "DFAS has chosen the Software Engineering Institute's (SEI's) Capability Maturity Model (CMM), Version 1.1, ..." Perhaps it might be wise to refer to this as the CMM-SW.

E.C6.2.2.2.1.2. "They begin with a statement of the work and the constraints and goals that define and bound the software project ..." Change "bound" (past tense) to "bind" (present tense) to agree with define.

E.C6.2.2.5. "A training program plan shall be developed and an organizational training plan shall be maintained. See Appendix 7 of this chapter and Part E, Chapter 7 for additional information." An earlier section which dealt with a training program (E.C6.2.2.2.2.3.) made the reference, "See Appendix 8 of this chapterfor guidance regarding the Training Program. Also, see Part E, Chapter 8 for additional details." Sooo, is the correct reference to Appendix 7 or 8, to Part E, Chapter 7 or 8???

E.C6.2.2.7.5.3. "Until ISO Lead Assessors are available..." This would be better if the ISO was changed to Government so that the statement read: "Until Government Lead Assessors are available..."

E.C6.2.3.5.6. "To review and approve local software process requirements and submit them to the ISO SEPG for approval." What is meant here? In E.C6.2.3.4. the reference is to Corporate SEPG. Is Corporate SEPG the same as ISO SEPG?

E.C6 - APPENDIX 1. Requirements Management Policy

3.c.(1) "Document software change requirements via a System Change Request (SCR) in the Configura-tion Management Information System (CMIS) or on DFAS Form 700." What about AISs which have a waiver from using CMIS?

3.d.(2) "Document the amplification of those software requirements shall be documented and modify them if additional clarification is received from the user or when other changes are required." Poor, poor use of the English language!

E.C6 - APPENDIX 2. Project Management Activities Policy

3.b. Each Directorate of I&T and SEO shall implement a project management program for each AIS within its purview." What is a "project management program?"

E.C6 - APPENDIX 3. Software Subcontract Management Policy

1. "Subcontract management does not apply to contracts that require the contractor to employ ISO documented processes." It would be better to substitute "Government" for "ISO" so that the sentence reads: "Subcontract management does not apply to contracts that require the contractor to employ Government documented processes."

3.b. "Technical managers or projects managers shall use ..." The adjective "projects" should be ren-dered as singular so that the phase reads, "Technical managers or project managers shall use ..."

E.C6 - APPENDIX 4. Software Quality Assurance Policy

1. The first paragraph is repetitious, at times verbatim, of the paragraph on Software Quality Assur-ance in E.C6.2.2.2.1.4.

E. C6 - APPENDIX 7. Organization Process Focus and Definition Policy

3.e. This paragraph references Attachments 4 and 5. None of the attachments that follow are num-bered, so unless one actually counts, one is not sure which Attachment is being referenced.

3. h. "AIS Managers shall develop a project training plan and submit it the their SEO/I&T Director for consolidation..." The definite article "the" should be replaced to the preposition "to" so that the phrase reads, "AIS Managers shall develop a project training plan and submit it to their SEO/I&T Director for consolidation..."

APPENDIX 8 - TRAINING PROGRAM POLICY

This appendix is rampant with the phrase "FSO employee." Of course, when it is cleaned up the phrase will be changed to "ISO employee." However, let me suggest that this is an inaccuracy. What is actually being referenced by the phrase are FSA/DSE employees or, in terms of the recent reorganization, I&T/SEO em-ployees. To be an employee of either the I&T or the SEO is NOT to be an employee of the ISO. Addition-ally, one can be an employee of the ISO but NOT be an employee of either an I&T or a SEO.

APPENDIX 11 - PEER REVIEWS

Attachment to Peer Reviews Policy -- STANDARD WORK PRODUCTS FOR PEER REVIEW:

A better word for "Pseudocode" might be "Design Documentation." "Design Documentation" could en-compass not only "pseudocode," but also truth tables, flowcharts, data flow diagrams, and other design documents.

KANSAS CITY - Jan 12, 99

At the recent Chief Information Officer - Plans and Policies Group (CIO-PPG) meeting, Mr. Kauzlarich stressed the need to reduce the volume of policy documentation and make the remaining documentation more usable to the average employee. We feel that Chapter 6 and the associated policies should be revisited in this light. It would be better to take the time to put out a higher quality product rather than rush something out just to say it's done.

Here are some comments on the SPI Program, described in the new Chapter 6 of DFAS 8000.1-R.

E.C6.2 The first sentence could be reworded to say "The SPI program has the overall objective of helping DFAS reduce costs through improved system quality." As written, it is unclear what cost is being reduced.

E.C6.2.1. The goals listed are more objectives than goals and do not follow the SMART criteria for goals. (Specific, Measurable, Attainable, Reasonable, and Time-driven.) We suggest they be reviewed in that light and rewritten accordingly.

E.C6.2.2.2.2. - E.C6.2.2.2.3. Is it applicable or necessary to show KPAs and their definitions in this document? If the definitions are included here they are not needed in the individual policies.

E.C6.2.2.3. Reword first sentence to be clearer and more readable, "The SPI program has developed the standard software process to improve and standardize the software development, modification and re-engineering practices of DFAS."

E.C6.2.2.3.2. Reword second sentence to "Initially, a set of target migratory and interim migratory systems were selected to implement the Systems Modification Scenario."

E.C6.2.2.6. Reword fourth sentence to "Well-defined and consistent measurements are instrumental to effective software processes."

E.C6.2.2.7.2.1. The SPI waiver and procedures should be part of this document.

E.C6.2.3.3.1. Are the goals from E.C6.2.1 from the CSC?

E.C6.2.3.4.1. This is the same responsibility as E.C6.2.3.2.1 for the Corporate Program Sponsor. Which one is really responsible? We suggest either removing or rewording this.

E.C6.2.3.4.2. Same as E.C6.2.3.4.1.

E.C6.2.3.4.3. Same as E.C6.2.3.4.1 and E.C6.2.3.4.2.

E.C6.2.3.4.4. What is meant by low-level processes?

E.C6.2.3.4.8. What recommendations are reviewed?

E.C6.2.3.5.2. Add "and local business strategy." to the end of the sentence.

E.C6.2.3.5.3. What is meant by high-level processes?

E.C6.2.3.5.4. What is meant by low-level processes?

E.C6.2.3.5.6. Change "ISO SEPG" to "Corporate SEPG".

E.C6.2.3.6. Does this group exist? If so, who are the voting members of this chartered group? Is a copy of the group's charter available?

PENSACOLA - Feb 9, 99

Good comments from Indy. Just a couple of comments on their comments as part of our dialog with each other.

E.C6.2.2.2.1.2 - The use of the word "bound" is probably correct as they mean it to imply boundaries; whereas "bind" connotes tying up.

E.C6 Appendix 1, 3.C.(1) - Systems that have a waiver from CMIS should still use DFAS Form 700 as stated in 8000.1-R.

E.C6 Appendix 3, 1 - Rather than ISO or Government documented procedures, this should probably say "DFAS" as we don't want to rule out 8000.1-R. We probably don't want the whole government either or even DOD as these are supposed to be organizational in nature. In the case of our SPI efforts, we currently have defined the ISO as the "organization", bearing in mind that it is an element of and represents DFAS.

It seems I am reduced to commenting on other folks comments rather than providing my own comments for comment. However, some thoughts about your thoughts:

E.C6.2.2.2 - E.C6.2.2.2.2.7 : My own view is that these paragraphs should be retained. Sure, they are quotes or paraphrases of the "Red Book" or more correctly, the CMM. This is old hat for those of us that have been in the trenches for years and own tattered and threadbare Red Books. But, for those still to come who won't own a Red Book and may be too intimidated by the CMM to dig into it, these paragraphs provide a clear and concise explanation of what the Level 2 and 3 KPAs are all about and the tie into policy.

E.C6.2.2.3.2 should be E.C6.2.2.3.3

Other than that, I say Bravo!

Here are some comments of mine on the SPI Program, described in the new Chapter 6 of DFAS 8000.1-R. I agree with the comments from Denver and Columbus, except as noted, so hopefully I'm not going to be redundant.

E.C6.2.2.2.2.4. Using the policy for Level 2 Project Management, even though it has been modified to include Level 3 key practices, still leaves a gap for Integrated Software Management. Notably, this is;

The shift in emphasis from making adjustments when problems occur, to anticipating problems and preventing their occurance. This could be resolved by changing the second sentence of iteg g. to: "Corrective actions are taken when it is anticipated the software plan will not be achieved as well as when it is not, either by adjusting performance or the plan".

E.C6.2.2.6. I presume this paragraph is meant to address the metrics program, but, emphasis seems to be on the collection and storing of data and not the why, i.e. goals, what data is needed to meet those goals, how will it be used, etc. This seems to be a key ingredient to any metrics program that has to precede any data collection or storage which is only the mechanical end of the process.

E.C6.2.2.7.2.1. This talks about the need to identify and share best practices across DFAS. This is a great thought, but I think it needs more teeth regarding a process for evaluating or making this happen. For instance in Pensacola, the training program was identified in the Level 3 SCE as a "Global Strength that is exceptional and should be viewed as a Best Practice". There is no mechanism identified that provides for looking at this program in view of the fact that we are proceding down a different path with AdminStar. I am sure the same kind of situation will occur as we move into Level 3 appraisals at the other sites.

E.C.2.3.2.2. This establishes a General Corporate Responsibility to set and direct strategy for continuing SPI across DFAS. I realize we are only addressing SPI as it relates to ISO/ITDs/SEOs. However, somewhere, across the future, we need to think about the integration of process improvement within the DFAS functional user communities in the Centers or wherever requirements flow begins.