_________________________________________________________________ 1. Proponent. AMSAS-IMP, René Robinson, firstname.lastname@example.org, x21144. 2. Purpose. This SOP explains the policies and procedures for processing public Web site change requests. 3. Applicability. This SOP applies to all G-6 personnel and contractors involved in analyzing, reviewing, approving, coding, testing, and publishing Web site change requests. 4. References. a. ASCR 25-2, Management of ASC Publicly Accessible Web Sites. b. Command Web Site Policy. c. Section 508 Compliancy. 5. Terms. a. ASC – Army Sustainment Command b. Contractor – Nongovernmental employees bound by the terms of a contract to perform work for the Government.
c. Requestor – A functional proponent, who formally requests additions, changes, or deletions to the public ASC Web pages. d. Webmaster – The main POC for all ASC Web-related issues. e. Functional Approver – The Government manager, usually a chief or director, who approves the requestor’s requirement. f. Web site – a hierarchy of Web pages starting at a main or “home” page, usually delineated along functional or organizational lines. It may also refer to the entire set of Web sites linked from the main or “home” page for the command. g. Publically accessible Web server (or public Web server) – a server that allows unrestricted access to its Web sites and Web pages via the Internet. h. Private Web Server – A server that restricts access to its Web sites and Web pages via the Internet, sometimes called an “intranet”. For ASC, the private Web servers may only be accessed from within the “.MIL” domain of the Internet. i. Server Team – The Government and contractor personnel responsible for loading files on the Web servers and granting file and folder permissions to authorized users. 6. Responsibilities. a. Requestors enter Web site change requests into the Taskmaster project-tracking program under “new projects”. Details on how to do this can be found on the Command Web Site Policy page under ASC Web Site Change Request Process. b. The IM analysts who review new Web projects created in Taskmaster will typically assign the project lead to the ASC Webmaster. c. The G-6 Webmaster is responsible for reviewing and analyzing Web change requests, coordinating the approval process, and assigning Web page coding to the programmers via Taskmaster. d. The contractor’s programming staff is formally assigned work via Taskmaster. Once assigned, programmers may contact the original requestor directly, or the Webmaster, for further clarification of requirements. Programmers typically close out an open Web project after publishing the changes to the destination Web server. e. The server team is responsible for moving files between servers and granting permissions to folders for programmers and functional users. Such services may or may not be used for a given Web project. 7. Procedures. a. The requestor enters a Web change request as a “new project” via Taskmaster. Details can be found on the Command Web Site Policy page under ASC Web Site Change Request Process.
b. After functional approval (usually by the requestor’s chief or director), the IM analysts determine if the new project is already covered under an existing application. If so, then they will assign the project to the appropriate application analyst/ programmer and the Webmaster does not get involved. If not, then the IM analysts assign the Web page project to the ASC Webmaster as the “project lead”. c. The Webmaster reviews the requirements and, if necessary, refines the requirements with the requestor. The Webmaster also reviews the content for any obvious OPSEC violations. If the proposed/affected Web pages are on the private Web servers, then step e. below; otherwise step d. d. If the proposed/affected Web pages are on the public Web servers, then the Webmaster submits the requirements to the Public Affairs Office (PAO) via email for approval. PAO will determine if G2 (DCS for Intelligence and Security) and/or the Legal Office also need to review the requirements for approval.
e. After approval (if necessary), the Webmaster reassigns the project by changing the “project lead” to the contractor. The contractor assigns the work to the contractor’s programming staff, and the programmers may then contact the requestor and the Webmaster directly if further clarification is necessary. Contractually, the programming staff may only be work loaded via Taskmaster. f. The contractor-programmers then code, test, and publish the requested Web changes, and close the Taskmaster project. Programmers should become familiar with the Web design guidelines posted on the Command Web Site Policy page. Programmers should also be familiar with Section 508 guidelines for Section 508 Compliancy. The requestor is automatically notified via Taskmaster upon completion. g. The project may be cancelled at any time before completion. The original requestor may cancel the project; the Webmaster may cancel if the requirements cannot be implemented or if the approval process nixes the project due to regulatory conflicts.