Talk:Baseline (configuration management)

section of prior TALK

(putting in section dividers)

The definition used for Configuration Management in the first paragraph is flawed. The first sentence does not summarise CM nor does it give a user a clear impression as to what CM is. CMMI does not include all CM tasks that are required and the IEEE standard is purely for software therefore should be referenced only to Software CM not CM.

---

This is supposed to be an article for Baseline, not configuration management. Hence this should start with an introduction on what a baseline is right off the bat. 166.20.24.145 (talk) 18:29, 7 January 2010 (UTC)

---

Agreed: the definition of Configuration Management given in the first paragraph only covers the second of the four CM activities, which are: 1) Identify Configuration Items; 2) Control configurations; 3) Configuration status accounting; 4) Configuration audits.

The definitions given for 'baselines' (supposedly the subject of this article) are vague and incomplete, and make no mention of the role of product definitions (requirements) in defining the functional baseline, and the way in which these requirements are allocated to lower-level Configuration Items, thus providing the functional architecture of the system as a whole.

Generally, the article appears confused, is inaccurate and has been poorly researched. Alexibrow (talk) 12:06, 13 January 2010 (UTC)

---

More than that, the article uses basic English words incorrectly, even though you can tell it was written by a native speaker. It's almost like he wrote with big words and long, drawn out sentences, to sound scholarly.

70.82.4.152 (talk) 15:11, 5 April 2010 (UTC)

---

looks like a typo in this sentence... (should "lad" be "lag"?) When an historical baseline is retrieved, the state of the work product(s) in that subset share the same significance in their history of changes; that allows project leaders to compare the relative progress of single parts of a project to the project as whole, which allows project leaders to identify individual items that lad or lead in progress toward better functionality or performance. — Preceding unsigned comment added by TimO123 (talk • contribs) 21:26, 28 December 2013 (UTC)

Table of Baseline items by certifying review

Baseline also has particular meaning tied to Schedule (project management) and Systems Engineering, both as a general term / procedure, and as there are specific named ones.

I've inserted a simple mention that a specific baseline is what was included at a certifying review event. Think that after that details vary case-by-case so I did not go further. It just seems too much detail to be easily readable, and some of it seems done to formalize contract committments more than a systems engineering need. In a program's System Engineering Plan, there may be a table of baselines and items in them to show exactly what that program has for formal review events and what items (commonly documentation) are involved. The U.S. DoD is an example of a structured set of reviews in Defense Acquisition Guidebook where there are service-specific procedures, and I see even a moderately big effort have something like this:

Baseline:	System Specification	System Functional	Allocated	Initial Product	Product
Review:	SRR	SFR	PDR	CDR	SVR
OCS	Done
FRD	TBD
SRD	Replacement	Expansion
SEP	Signed	Updates
ISP	draft	Signed			Updates
RMP	draft	Updates			Updates
TEMP	Signed			Updated
IMS	USG IMS	Ctr Expansion		Updates	Final
Design Documents	Operational Architecture high-lvl for ISP	System Architecture begun, w. data flows	System Architecture complete	Detailed design completed	Updates
Testing Documents	Requirements matrix in SRD indicates section of System Test and verification method	Draft Sample data sets from functional offices		Plans	Full procedurs and results reports
Training materials		Plan outline			Full plans, aids, items, and training test results
Notes:	System requirements derived from FRD or detail added	Add subsystem specifications	Preliminary or high-level design and approach	Design detail, with integration and test plans	Development Test results; detailed Operational test and support items

Does anyone disagree and think this should go into the article ? Markbassett (talk) 21:31, 24 November 2015 (UTC)

Hmm long time no revisit ... should at least mention

• Functional - product Software Requirements Specification, established by Software Requirements Review
• Allocated - Preliminary Design Specifications, Software Preliminary Design Review
• Product - "As Built" Software system, Software End Product Acceptance (test)