Talk:Design review (U.S. government)

Title incorrect
The title is 'design reviews' but listed are things other than reviews of design. The first para also indicated US Military, but in that context these titles are Acquisition "Technical Reviews" as events within the larger Integrated Defense Acquistion lifecycle so it is a different title there and is not about the design. Markbassett (talk) 17:42, 11 April 2013 (UTC)

Separate kinds
I have put a DoD para separate from NASA or medical paras so the different refs and diffferent meanings can be made clearer. Seems like there used to be a separate article for some PDR, CDR, etcetera, but it looks like there no such articles exist now. Markbassett (talk) 18:28, 11 April 2013 (UTC)

Skipping Background and Procedure
Keeping the topic to the reviews - meaning not mentioning the ( i.e. for SRR: a slideshow, risk assessment s/s, the SRD, plans for Software Dev, QA, CM, Acceptance Test, WBS, Data Model, Delivery plan, TEMP) ( or SRD having Tech rqmts, Interface rqmts, Derived rqmts, trace matrix, data conversion impact, and assessment of completeness) Markbassett (talk) 20:40, 18 August 2015 (UTC)
 * Integrated Defense Acquisition framepwrk diagram/doc that puts them on a timeline;
 * Readiness check checklist of items looked for as prerequisites, from SMS systems engineering app C or NAVSEA procedures...
 * Aides such as entry/exit guide, template for PDR report DAU module CL003
 * Activities/topics (Agenda, incl check of liens list; Handling of planned shorefalls; Terminology; identification of signature authorities ...
 * Product alignements to milestone reviews - table specific docs or DODAF vs columns of reviews and X where involved)
 * Milestone B: Statutory and Regulatory Requirements
 * Guidances - Technical reviews should be event-based, are only as good as who conducts them, should review entire program, should result in pgm decisions
 * Actual results other than 'varies widely'; actual behaviour is often short ... not sure there is authoritative survey or open resources, see very little in papers

External links modified
Hello fellow Wikipedians,

I have just added archive links to 1 one external link on Design review (U.S. government). Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive https://web.archive.org/20130213203151/https://ilc.dau.mil/ to https://ilc.dau.mil/

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Cheers.—cyberbot II  Talk to my owner :Online 13:24, 28 January 2016 (UTC)

The terms vary, the concepts less so.
The article is trying to cover the general concept, which means all past, present, and future variations on the theme at a higher level without going through the immense low-level detail and all the individual changes. The question is -- has it struck a reasonable balance between giving illustrative/meaningful detail and yet gotten the overall idea across ?

The problem is that names of reviews and documents change over time and among various schools of approach. The DoD-STD-2167A formal reviews/related documents are similar to what the later Mil-STD-498 Joint management reviews/related documents, and parallel the IEEE 12207 project management reviews/related documents. (Ref the 12207 SPIWG document, SPAWAR Systems Center San Diego, Software Engineering Process Office).

The mechanisms and context or background concepts also change, though a bit less or more slowly. For the U.S. DoD reviews, actual structure of each review varies by the individual service -- not just that how each conducts a SRR involves different offices and personnel, but that there are different prerequisites, goals, conduct or events at the review, and outcome result items. And the overall intent of a review shifts at the DoD level. (e.g. the 2004 framework of acquisition has a review within a post-contract phase, and then 2008 framework of acquisition puts it as part of the pre-contract events, and in 2014 it shifts to a Generic Acquisition Process that only states very high level phases without specific reviews identified.)

Any suggestions to improve the article with regards to this ? Markbassett (talk) 21:13, 31 May 2016 (UTC)


 * p.s. System and Software guidances go back surprisingly far (depresssingly so when one sees the same issues today). Should there be call outs for particular milestone items and/or mention of motivations ?


 * GUIDE FOR TECHNICAL REVIEWS AND AUDITS (1971)
 * MIL-STD-1521B USAF Technical Reviews and Audits for Systems, Equipments and Computer Programs, note MIL-STD-1521A was 1 June 1976
 * Markbassett (talk) 18:53, 28 November 2018 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Design review (U.S. government). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20170131231503/http://www.dau.mil/publications/publicationsdocs/sefguide%2001-01.pdf to http://www.dau.mil/publications/publicationsDocs/SEFGuide%2001-01.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 10:52, 9 September 2017 (UTC)

Key considerations and gotchas
The discussion of reviews commonly seem to include two types of info not mentioned here -- lists of key elements for a review, and warnings of the typical "gotchas" for the review. Those seem something with enough WEIGHT to include, but while the MIL-STD gives just one standard, the descriptions of what really matters or what to watch out for vary according to which branch of the government is involved, and by individual authors. A PDR for the Navy is not the same as a PDR for the Air Force in content and conduct. The "gotchas" from Donald Reifer (external author and expert) for software may be different in 1982 than it is in his 2006 rev 6 Software Management than it is in his 2017 on Agile software. So .. should there be some mention or should it be left up to Google ? Cheers Markbassett (talk) 19:42, 28 November 2018 (UTC)