<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Schedule Software &#187; deploy</title>
	<atom:link href="http://schedulesoftware.com/tag/deploy/feed/" rel="self" type="application/rss+xml" />
	<link>http://schedulesoftware.com</link>
	<description></description>
	<lastBuildDate>Tue, 19 Jul 2011 15:02:22 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Would this help, to deploy a good system ? What if people treat the document as a checklist of what not to do?</title>
		<link>http://schedulesoftware.com/would-this-help-to-deploy-a-good-system-what-if-people-treat-the-document-as-a-checklist-of-what-not-to-do/416/</link>
		<comments>http://schedulesoftware.com/would-this-help-to-deploy-a-good-system-what-if-people-treat-the-document-as-a-checklist-of-what-not-to-do/416/#comments</comments>
		<pubDate>Mon, 03 May 2010 16:38:48 +0000</pubDate>
		<dc:creator></dc:creator>
				<category><![CDATA[schedule management software]]></category>
		<category><![CDATA[checklist]]></category>
		<category><![CDATA[deploy]]></category>
		<category><![CDATA[Document]]></category>
		<category><![CDATA[good]]></category>
		<category><![CDATA[help]]></category>
		<category><![CDATA[People]]></category>
		<category><![CDATA[system]]></category>
		<category><![CDATA[this]]></category>
		<category><![CDATA[treat]]></category>
		<category><![CDATA[would]]></category>

		<guid isPermaLink="false">http://schedulesoftware.com/would-this-help-to-deploy-a-good-system-what-if-people-treat-the-document-as-a-checklist-of-what-not-to-do/416/</guid>
		<description><![CDATA[Standard:  Configuration Management Plan
Phase:  Production and Deployment
Activity:  Systems Management
Task:  Establish Configuration Management Strategy
Reference:  DFAS 8000.1-R, Part C, Chapter 2
Effective Date:  May 17, 2002
DEFENSE FINANCE AND ACCOUNTING SERVICE
Configuration Management Plan
For
Program Name
Date of Issue and Status: Date plan acknowledged as acceptable (mm/dd/yyyy) and whether plan is draft or approved.  Also [...]]]></description>
			<content:encoded><![CDATA[<p>Standard:  Configuration Management Plan<br />
Phase:  Production and Deployment<br />
Activity:  Systems Management<br />
Task:  Establish Configuration Management Strategy<br />
Reference:  DFAS 8000.1-R, Part C, Chapter 2<br />
Effective Date:  May 17, 2002</p>
<p>DEFENSE FINANCE AND ACCOUNTING SERVICE</p>
<p>Configuration Management Plan</p>
<p>For</p>
<p>Program Name</p>
<p>Date of Issue and Status: Date plan acknowledged as acceptable (mm/dd/yyyy) and whether plan is draft or approved.  Also include version number.</p>
<p>Issuing organization: Identify the organization issuing this plan.</p>
<p>CONFIGURATION MANAGEMENT PLAN</p>
<p>1.  Purpose.  This plan specifies processes and procedures for the execution of configuration management (CM) to support the entire software change/modification process.</p>
<p>2.  Scope.  This plan applies to all activities related to the establishment of system/configuration baseline and change and release of application configuration items (CIs).  These CIs are identified in appendices to this plan.</p>
<p>3.  Software Configuration Management Structure. </p>
<p>     3.1.  Organizational Components.  Identify the organizational units or teams responsible for the system’s CM activities.</p>
<p>          3.1.1.  Systems Engineering.  Identify and describe the systems engineering activities and tasks that will be accomplished and how the results of these efforts will be documented.</p>
<p>          3.1.2. Configuration Management.  Identify and describe CM tasks that will be performed.</p>
<p>          3.1.3.  Development Platform Engineering Team (DPET).  Identify and describe the integration of release management procedures with informational and technical requirements necessary for release of software for test and production.</p>
<p>          3.1.4.  Configuration Control Board (CCB).  Identify and describe the membership, roles, and responsibilities of the CCB.</p>
<p>     3.2.  Configuration Management Responsibilities.  Describe the responsibilities of the organizational components performing CM  activities.</p>
<p>          3.2.1.  Configuration Item Identification.  Identify who is responsible for CI identification.</p>
<p>          3.2.2.  Configuration Control.  Identify who is responsible for configuration control and describe the procedures for accomplishing configuration control (CI identification, establishing baselines, changes, deviations, waivers, configuration change orders (CCOs), CCB requirements).</p>
<p>          3.2.3. Configuration Status Accounting. Identify who is responsible for configuration status accounting and describe the procedures for accomplishing configuration status accounting (CIs, baselines, records, databases, etc.) requirements.</p>
<p>          3.2.4.  Audits and Reviews. Identify the responsibilities involved in audits and reviews and describe what will be accomplished during each audit and review.</p>
<p>4.  Software Configuration Management (SCM) Activities.</p>
<p>     4.1.  Configuration Identification. Describe the procedures for meeting the CI requirements, including a description of activities for identifying CIs and baseline items, formation of releases, and baselining of products.</p>
<p>     4.2.  Configuration Control.  Describe the configuration control activities, including level of authority for approval, change proposal processing, and CCB roles and procedures.</p>
<p>     4.3.  Configuration Status Accounting.  Identify reports required for status accounting, i.e., the status of CIs, SCRs, and releases.</p>
<p>     4.4.  Audits and Reviews.  Describe the formal review/audit procedures to be used for configuration audits and reviews (functional configuration audits and physical configuration audits).</p>
<p>     4.5.  Scheduling and Tracking of SCM Activities.   Describe the scheduling and tracking of CM activities that will be accomplished for each release.</p>
<p>5.  Library Management.  Describe the procedures to be used for development library environment management, release management library environment management, validation testing library environment management, and release certification.</p>
<p>6.  Tools, Techniques, and Methodologies.  Identify tools and techniques and describe any unique methodologies used to accomplish effective CM.</p>
<p>7.  Records Collection and Retention.  Identify CM information to be retained and the locations and methods of retention.</p>
<p>8.  Procedures for Updating Plan.  Describe the steps required to modify the plan to include version number and methodology.</p>
<p>9.  Change Information Sheet.  List the changes and additions included in the current version of the plan.</p>
<p>CONFIGURATION MANAGEMENT PLAN</p>
<p>APPENDIX A &#8211; ACRONYMS</p>
<p>Describe the acronyms as they are used in the plan.</p>
<p>APPENDIX B &#8211; DEFINITIONS</p>
<p>Describe the key terms as they are used in the plan. </p>
<p>APPENDIX C &#8211; REFERENCES</p>
<p>Provide a complete list of documents referenced in the text of the plan.  Each reference shall contain, as approp</p>
]]></content:encoded>
			<wfw:commentRss>http://schedulesoftware.com/would-this-help-to-deploy-a-good-system-what-if-people-treat-the-document-as-a-checklist-of-what-not-to-do/416/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

