📄 se standard documents.htm
字号:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Author" content="Bill Tepfenhart"> <meta name="GENERATOR" content="Mozilla/4.7 [en] (Win98; I) [Netscape]"> <title>SE Standard Documents</title></head><body><center><h1>Templates For Software Engineering</h1></center><p><br>The development of software generates a large number of documents.In order to provide consistency across courses and to ease documentation,we have produced specifications and templates for all of the documentswhich the student might be expected to generate. These templates shouldbe used in your course work and the practicum.<p>Use of these specifications and templates will help assure better grades.However, it will not ensure good grades. A good paper requires good content,both in terms in what appears in it and how it is expressed. The authorshould use the correct spelling of words and proper grammar throughoutthe document.<br> <h2>PAPER STANDARDS</h2><b>Last update: 11Feb00</b><blockquote><blockquote><a href="http://www.monmouth.edu/~btepfenh/se_doc_standard.doc">FormattingStandard For Software Engineering Papers</a><br>The standard described in this document applies to papers submittedfor class work. It provides basic guidelines as to how papers are to beformatted. The document itself provides all the formatting styles describedwithin it.<p>Formatting Standard For Software Engineering Thesis (still in construction)<br>The standard described in this document applies to theses submittedfor a Masters degree within the Software Engineering program. It providesbasic guidelines as to how they are to be formatted. The document itselfprovides all the formatting styles described within it.</blockquote></blockquote><h2>SOFTWARE DEVELOPMENT DOCUMENT DESCRIPTIONS</h2><b>Last update: 11Feb00</b><blockquote><ul> <br><a href="http://www.monmouth.edu/~btepfenh/docs/dom.doc">COM Computer Operation Manual</a><br>Identifies and records information needed to operate the computerson which the software will run. Summarizes the purpose of the computersystem and describes any security or privacy considerations associatedwith its use.<p><a href="http://www.monmouth.edu/~btepfenh/docs/cpm.doc">CPM ComputerProgramming Manual</a><br>Identifies and records information needed to program the computerson which the software was developed or on which it will run.<p><a href="http://www.monmouth.edu/~btepfenh/docs/csar.doc">CSAR ConfigurationStatus Accounting Report</a><br>Maintains records of the configuration status of all entities thathave been placed under project level or higher configuration control. Theserecords shall be maintained for the life of the contract. They shall include,as applicable, the current version/revision/release of each entity, a recordof changes to the entity since being placed under project level or higherconfiguration control, and the status of problem/change reports affectingthe entity.<p><a href="http://www.monmouth.edu/~btepfenh/docs/dbdd.doc">DBDD DatabaseDesign Description</a><br>Describes the design of the database, that is, a collection of relateddata stored in one or more computerized files in a manner that can be accessedby users or computer programs via a database management system (DBMS).It can also describe the software units used to access or manipulate thedata. The DBDD is used as the basis for implementing the database and relatedsoftware units.<p><a href="http://www.monmouth.edu/~btepfenh/docs/es.doc">ES ExecutiveSummary</a><br>Describes the background, both the previous and current situation. Motivation, target solution, process and management, approach implemented,and the results.<p><a href="http://www.monmouth.edu/~btepfenh/docs/fca.doc">FCA FunctionalConfiguration Audit</a><br>The FCA is conducted to determine whether or not the actual performanceof each configuration item (CI) complies with its controlling specifications.Specifically, a FCA must verify that the functional, allocated, design(if applicable), and proposed product baselines are consistent and thatfunctional requirements are traceable, as shown through the documentationand test results.<p><a href="http://www.monmouth.edu/~btepfenh/docs/fsm.doc">FSM FirmwareSupport Manual</a><br>Identifies and records information needed to program and reprogramany firmware devices in which the software will be installed.<p><a href="http://www.monmouth.edu/~btepfenh/docs/idd.doc">IDD InterfaceDesign Description</a><br>Provides the detailed design of one or more CSCI interfaces. When InterfaceRequirements Specifications have been prepared, associated Interface DesignDocuments shall be prepared as well. Design issues pertaining to interfacesare included in the IDD.<p><a href="http://www.monmouth.edu/~btepfenh/docs/irs.doc">IRS InterfaceRequirements Specification</a><br>Describes in detail the requirements for one or more CSCI interfacesin the system, segment, or prime item.<br>The specified requirements are those necessary to design, develop,test, evaluate, and deliver the required CSCI. The interface requirementsmay be included in the associated Software Requirements Specificationsunder the following conditions: (1) there are few interfaces, (2) few developmentgroups are involved in implementing the interface requirements, (3) theinterfaces are simple, or (4) there is one contractor developing the software.The requirements concerning CSCI interfaces are included in the IRS.<p><a href="http://www.monmouth.edu/~btepfenh/docs/itp.doc">ITP IntegrationTest Plan</a><br>An Integration Test Plan (ITP) must be developed before unit integrationand testing can begin. The ITP establishes test cases (in terms of inputs,expected results, and evaluation criteria), test procedures, and test datafor conducting unit integration and testing, and should cover all aspectsof the CSCI architectural design. The development of the ITP is the responsibilityof the Software Test and Evaluation Manager.<p><a href="http://www.monmouth.edu/~btepfenh/docs/ivv.doc">IV&V Independent Verification and Validation</a><br>Performed by a specified IV&V Group that will participate/monitoractivities in each phase of the development process including attendingboth formal and informal program reviews. In addition, the IV&VGroup will be provided on-line access to source code, test scripts anddocumentation, and will participate in the SCCB. During all phases of softwaredevelopment, the IV&V Group will be able to initiate change requeststo the evolving baseline or to add their review comments into the activeaction items to be resolved as a part of each end-of-phase review. These comments will be treated like any comment or change request initiatedby a member of the project organization. Review comments are expectedto be supplied in written form, or electronically, for subsequent trackingby the Software Project Manager in the same manner review action itemsare handled. All comments will be adjudicated and responses providedback to the IV&V Manager describing the intended action to be taken. Change requests to change something in the developmental baseline, afterthe phase has been completed, will be entered into the configuration controlsystem as described in SCMP and disposed of like any other change request. The IV&V Group will be able to monitor the status of change requeststhey submitted directly from the SCM system.<p><a href="http://www.monmouth.edu/~btepfenh/docs/msc1.doc">MSC MilestoneChart (Timeline Matrix)</a><br>Task tracking sheet that contains schedules and actual dates of developmentmilestones for the software components. All planned and actual dates ofkey project milestones will be identified. Also included in thisschedule will be all major project milestones, which will enable a contractorto plan for delivery of their individual sections.<p><a href="http://www.monmouth.edu/~btepfenh/docs/mtp.doc">MTP MasterTest Plan</a><br>Establishes the overall plan to demonstrate that the specifically identifiedsystem and associated sub-systems function in accordance with the requirements. The document describes the testing of individual sub-systems and the integratedsystem for compliance. It defines the schedule for all testing, resourcesrequired for test conduct, planning assumptions and constraints, and brieflydescribes each test to be conducted and the cases that are to be tested.<p><a href="http://www.monmouth.edu/~btepfenh/docs/ocd.doc">OCD OperationalConcept Description</a><br>Describes a proposed system in terms of the user needs it will fulfill,its relationship to existing systems or procedures, and the ways it willbe used. The OCD is used to obtain consensus among the acquirer, developer,support, and user agencies on the operational concept of a proposed system. Depen-ding on its use, an OCD may focus on communi-cating the user's needsto the developer or the developer's ideas to the user and other interestedparties. The term "system" may be interpreted to apply to a portionof a system.<p> <a href="http://www.monmouth.edu/~btepfenh/docs/pca.doc">PCA PhysicalConfiguration Audit</a><br>The PCA is a formal examination of configuration items (CI抯) to ensurethat each complies with the technical documentation. It verifies 揳s-built⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -