Comments on seed document

I had a couple of thoughts about the seed document:

1. I suggest collecting sections enumerated by software development lifecycle phase under a super-section (e.g., in the outline I have seen, this would be section 3, and then 3.1 might be “requirements”, 3.2 “design”, and so on). I have found that there are often comments that apply to all SDLC phases that need a place to go, and referring to “Sections 3-5”, for instance, as opposed to “Section 3” (which includes all its subsections), gets awkward. Also, there tends to be some disagreement on how many SDLC phases to include, and keeping them within a top level section means that inserting or deleting phases doesn’t disturb the rest of the outline.

2. I was wondering at the exclusion of some SDLC phases, such as fielding, maintenance, and retirement- was that intentional (for instance, it was said on the call that missing the implementation phase was unintentional). Protecting privacy during all phases of the SDLC is probably important. (Though perhaps PbD stops once the system is developed, I’m not sure.)

3. Is there some common way in OASIS terms to refer to the SDLC and its phases? If so, it would be good to use it, as otherwise the number of SDLC variants can be quite large and discussions of their (apparent) differences somewhat lengthy.

4. I would think privacy, like security, can be an emergent property-are we likely to miss that if we only address it by dividing discussion into SDLC phases? I’m not sure exactly what to propose to remediate this, but thought it worth mentioning so we don’t lose the issue (if we agree it is an issue).

5. Has a companion document that writes about the rationale of this document been considered? Or an appendix for same? Or is it enough to cite some existing books or papers on PbD for people new to the area to be able to make use of the document? I have found that in trying to strip a document down to the minimum usable by a software engineer, sometimes important background, motivating material gets left out. Yet there is also desire to keep a document such as this one focused on only what the software engineer needs to know to do his or her job.

Respectfully,

Aaron

Aaron L. Temin, PhD, CISSP-ISSAP

Lead Infosec Engineer

The MITRE Corporation

7515 Colshire Drive

McLean, VA 22102

703.983.7330

pbd-se message