Software Requirements Specification Template

1,913 views
1,698 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,913
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
87
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Software Requirements Specification Template

  1. 1. Software Configuration Management Plan For HMC POI Inspection & Management System Version 1.00 reviewed Prepared by 4WD <ICU-CMU MSE Studio Project Team> <Dec. 02, 2004>
  2. 2. Table of Contents 1. Introduction.............................................................................................................................................. 1 1.1 Purpose................................................................................................................................................ 1 1.2 Scope................................................................................................................................................... 1 1.3 Mnemonics.......................................................................................................................................... 1 1.3.1 Mnemonics................................................................................................................................... 1 1.4 Reference............................................................................................................................................ 2 2. Management............................................................................................................................................. 3 2.1 Organization........................................................................................................................................ 3 2.2 Responsibilities................................................................................................................................... 3 2.2.1 Configuration Identification......................................................................................................... 3 2.2.1.1 Baselines............................................................................................................................... 4 2.2.2 Configuration Control.................................................................................................................. 4 2.2.2.1 Software Change Request (SCR).......................................................................................... 4 2.2.2.2 Software Change Authorization (SCA)................................................................................ 4 2.2.3 Status Accounting........................................................................................................................ 4 2.2.4 Configuration Control Board....................................................................................................... 4 2.3 SCMP Implementation........................................................................................................................ 4 2.3.1 Configuration Baselines............................................................................................................... 4 2.3.1.1 Allocated Baseline................................................................................................................ 4 2.3.1.2 Development Baseline.......................................................................................................... 4 2.3.1.3 Product Baseline................................................................................................................... 4 2.3.2 Schedules and Procedures for SCM Reviews and Audits............................................................ 5 2.3.3 Configuration Management of Software Development Tools..................................................... 5 3. SCM Activities.......................................................................................................................................... 6 3.1 Configuration Identification................................................................................................................ 6 3.1.1 Configuration Item Lists.............................................................................................................. 6 3.2 Configuration Control......................................................................................................................... 6 3.2.1 Function of the configuration control board................................................................................ 6 3.2.2 Baseline management................................................................................................................... 6 3.2.3 Change Management.................................................................................................................... 7 3.3 Status Accounting............................................................................................................................... 7 4. Tools and techniques and Methodologies.............................................................................................. 8 4.1 About methodologies.......................................................................................................................... 8 4.2 Tools to be used.................................................................................................................................. 8 4.3 Naming Convention............................................................................................................................ 8 4.3.1 Time sheet.................................................................................................................................... 8 4.3.2 Meeting notes............................................................................................................................... 8 4.3.3 Word document and Powerpoint presentation............................................................................. 8 4.3.4 Java source code........................................................................................................................... 9 4.3.4.1 Java Source Files.................................................................................................................. 9 4.3.4.2 Packages................................................................................................................................ 9 4.3.4.3 Java Bytecode....................................................................................................................... 9 ii
  3. 3. Revision History Name Date Reason For Changes Version Jonggul Park Nov 28 2004 Draft 0.10 Kuyul Noh Dec 02 2004 Refinement by Inspection 1.00 iii
  4. 4. Table of Figures Figure 1 Responsibility Assignment........................................................................................................... 3 Figure 2 Configuration Item Lists.............................................................................................................. 6 iv
  5. 5. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan 1.Introduction This document describes the software configuration management activities to be performed in support of the Hyundai POI Inspection and Management System (HPIMS) project. The HPIMS project is charged with developing a program that provides efficient way of finding, cleansing, and reporting duplication and inconsistent data from the POI data that will be used for the input of car navigation system. The primary audience of this document is 4WD team. Every member in our team is responsible for the activities planned in this document such as developing the system, documenting, reviewing, and testing with the project quality controlled by this plan. 1.1Purpose The software configuration management plan (SCMP) for the HPIMS describes the total set of activities used to manage the content of a software product form the beginning to the end of the development process. The purpose of the SCM process is to ensure that the content of the product is known and available at all times. That the product functions are traceable form the requirements through the design to the final implementation, and that all product contents are properly controlled and protected. For large and complex products, SCM systems can be quite sophisticated. For our project with 4 team members, however, the SCM system is concerned largely with controlling changes. 1.2Scope This plan applies to all software and associated documentation used in the production of HPIMS. 1.3Mnemonics 1.3.1Mnemonics The following Mnemonics are referred to within the text of this standard CCB Configuration Control Board CCR Configuration Change Request CMU Carnegie Mellon University DB Database CVS Concurrent Versions System DLD Detailed Level Design GUI Graphical User Interface HMC Hyundai motors Corporations HPIMS HMC POI Inspection and Management System ICU Information and Communication University MDB Microsoft Access Database file POI Point of Interest RUP Rational Unified Process SCA Software Change Authorization SCMP Software Configuration Management Plan SCR Software Change Request SOW Statement of Work SPMP Software Project Management Plan SRS Software Requirements Specification SSR Software Specification Review Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 1 of 7
  6. 6. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan 1.4Reference • IEEE Standard for Software Configuration Management Plans—IEEE Std 828-1998. • IEEE Guide to Software Configuration Management—ANSI/IEEE Std 1042-1987. • Introduction to the Team Software Process Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 2 of 7
  7. 7. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan 2.Management 2.1Organization The HPIMS organization is designed to ensure clear lines of authority and to provide a framework within which administrative and technical control of software activities can be cost-effectively integrated into a quality product. Primary responsibilities for various configuration management tasks are assigned as shown in Table Figure 1. 2.2Responsibilities The software configuration management authority has the authority to require changes in practices and procedures. The general responsibilities of the software configuration management authority are outlined in Figure 1. The software configuration management authority’s functions include, but not limited to the following tasks: • Configuration control • Status accounting • Configuration Identification • Implementation and maintenance of the software configuration plan • Configuration control board cochairperson • Establishment and maintenance of engineering baselines • Cochairperson for formal audits • Participation in reviews Responsibilities Quality CCB Support Developer Manager Manager Configuration identification Originate Approve/release tech documentation Approve/Review Originate Change preparation Originate Change Control Review Approve Change implementation Approve Originate Documentation maintenance Approve Originate Status accounting Originate Formal SCM audits Originate Review Approve Figure 1 Responsibility Assignment 2.2.1Configuration Identification Configuration identification is applied to all software for HPIMS, both code and associated documentation. Associated documentation along with the actual produces software makes up the configuration item. The software configuration management authority originates the identification scheme, with the approval of the team members. Configuration identification of computer programs and documentation during development effort consists of established baselines and releases that are time-phased to development schedules as described in the HPIMS software development plan. Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 3 of 7
  8. 8. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan 2.2.1.1Baselines Baselines are established for the control of design, product, and engineering for the control of design, product, and engineering changes and are time-phased to the development effort. Software configuration management authority administers application of the baselines. Baseline defined for HPIMS include, • Allocated baseline • Development baseline • Product baseline More details on baselines are presented in 2.3.2. 2.2.2Configuration Control All documentation and software entities are released to and maintained by software configuration management by software configuration management in a controlled library. SCM administers change and control process. 2.2.2.1Software Change Request (SCR) The SCR is the mechanism by which change requests are presented to the CCB. This action allows a developer to check out software/documentation from SCM controlled libraries. The mechanism for requesting authorization is to submit CCR to CCB and request approval for work to begin. 2.2.2.2Software Change Authorization (SCA) The SCA is used to request SCM to place a new version of software/documentation into the controlled libraries. 2.2.3Status Accounting A software change authorization database is used for generating reports that track changes to all of the controlled baselines. At project request, SCM generated reports that track the status of documentation and the software. 2.2.4Configuration Control Board The HPIMS project CCB is established by the quality manager and one of the team members and customer. The quality manager is the CCB chairperson and has the final responsibility for CCB actions. 2.3SCMP Implementation The SCMP is implemented as soon as it is signed off by the HPIMS team members but prior to formal reviews with the customer. The configuration control board is established at the time of SCMP approval but prior to the establishment of any baselines. 2.3.1Configuration Baselines 2.3.1.1Allocated Baseline The allocated base is established with the customer approval of the HPIMS software requirement specification. Normally this corresponds to the completion of the software specification review (SSR). The specification and associated documentation define the allocated configuration identification. 2.3.1.2Development Baseline The developmental baseline is established by the approval of technical documentation that defines the top- level design and detailed design. 2.3.1.3Product Baseline The product baseline is established upon customer approval of the product specification following completion of the last formal audit. Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 4 of 7
  9. 9. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan 2.3.2Schedules and Procedures for SCM Reviews and Audits Reviews and audits are held as defined by HPIMS SPMP. 2.3.3Configuration Management of Software Development Tools The configurations of all support software used in development and test on the HPIMS project software is controlled in the same manner as HPIMS software. Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 5 of 7
  10. 10. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan 3.SCM Activities 3.1Configuration Identification The approved list of configuration items is produced and approved. Each item on the configuration item list should contain the following information: • The item name and type • The point in the process when the item is to be baselined • The product owner • Storage location 3.1.1Configuration Item Lists Item Name Item Type Baseline Product owner Storage Location Point SRS DOC Allocated Changki Kim CVSStudioSRS SPMP DOC Allocated Jaeha Song CVSStudioSPMP SQAP DOC Allocated Jonggul Park CVSStudioSQAP SCMP DOC Allocated Jonggul Park CVSStudioSCMP SAD DOC Development TBD TBD Implementation SOURCE Development TBD TBD Test DOC Development TBD TBD Installation and checkout DOC Development TBD TBD Operation and maintenance DOC Product TBD TBD Figure 2 Configuration Item Lists All supporting documentation generated for this project is identified by the use of the following convention: HPIMS, an abbreviation for the document nomenclature, and the product’s version_revision_update numner. EXAMPLE: HPIMS-SRS-v0.11 3.2Configuration Control Software configuration management and change control is applied to all documents and code. Control is effected through the implementation of configuration identification, the CCB, change control, and status accounting functions. 3.2.1Function of the configuration control board The configuration control board reviews proposed changes for assuring compliance with approved specifications and designs, and evaluates impacts on existing software. Each engineering change or problem report that is initiated against a formally identified configuration item is evaluated by the CCB to determine its necessity and impact. 3.2.2Baseline management The general steps required to manage the system baseline are as follows. • With the owner’s agreement, the development engineer prepares a baseline submission, using the CCR form. • The quality manager attests to the quality of the product by signing the CCR form. Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 6 of 7
  11. 11. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan • The CCB reviews the submission and either approves or disapproves it. • The support manager retains backups of all baselined items with the CVS repository and web (selectively) • Every team members retain backups of baselined items using CVS. • Team members may obtain copies of baselined items on request by using CVS. • The development manager ensures that only official baselined product versions are used to build or deliver products. 3.2.3Change Management • Engineers submit all proposed changes to baselined items to the CCB with a completed CCR • Multiple fixes may be submitted at the same time 3.3Status Accounting The support manager reports SCM status weekly on baseline status (CSR) • Change activity for this week and the project to date • The status of outstanding changes • Data on SCM activity and status • Report on the CSR form Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 7 of 7
  12. 12. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan 4.Tools and techniques and Methodologies 4.1About methodologies The methodology used in HPIMS project is TSP. SCM is also managed with TSPi process. The forms and the procedure and so on are TSPi-provided such as CCR, CSR and so on. In other words, as TSPi book indicates, we use manual SCM process because, for typically small size of TSPi projects, the time investment required to set up and learn to use an automated system would probably not be worthwhile. The tool we use is CVS and that is just for version controlling of the source code and shared storage for documents. 4.2Tools to be used The following tools should be used to produce artifacts: • Microsoft Word 2000 and above • Microsoft PowerPoint2000 and above • Microsoft Excel 2000 and above • Microsoft Project Professional 2000 and above • Eclipse to produce Java source code, xml and text files. • Eclipse CVS for version control • Any editor to produce html, customized style sheet (css) and other static content web files. • To produce images (jpg, gif, bmp) or videos (avi, mpeg, etc.), any tool can be used. • CASE tool 4.3Naming Convention 4.3.1Time sheet Where to save: CVSManagementTimesheets File name: Timesheet_<semester><year>_<firstname>.xls Example: Timesheet_Fall2004_jgpark.xls 4.3.2Meeting notes Original meeting notes is created by the note keeper using Microsoft Word. Where to save: CVSManagementMeetingNotes File name: MeetingNotes_YYYY-MM-DD.doc Example: MeetingNotes_2004-09-30.doc The original meeting notes created in Word are subsequently converted to the filtered html format by the webmaster and saved as follows: Where to save: CVSwebmeetings File name: MeetingNotes_YYYY-MM-DD.htm Example: MeetingNotes_2004-09-30.htm Later, the webmaster copies the html version to the web server area on dogbert and updates the web page that has the links to the meeting notes. 4.3.3Word document and Powerpoint presentation Do not use spaces in the abbreviated title part of the file name. The suffix is v99, where 99 is the version number without the “.”. So, version 1.1 will create suffix _v11, version 3.4 will be _v34, and so on. The version number should start at 0.1 or higher. Where to save: NA—depends on the purpose of the document Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 8 of 7
  13. 13. HMC POI Inspection & Management System Development Date: Dec.02, 2004 Software Configuration Management Plan File name: HPIMS_<abbreviated title>_v99.doc Examples: HPIMS_SCMP_v0.01.doc HPIMS_TaskAnalysis_v0.22.doc HPIMS_FallEOSP_v1.00.ppt 4.3.4Java source code 4.3.4.1Java Source Files Each Java source file necessarily has the name of the public class or interface that is defined in that file. Therefore, the name of Java source files is defined by the name of that class or interface. Class and interface names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words—avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). Where to save: CVSHPIMSsrc<package subdirectories> File name: <class or interface name>.java Examples: Raster.java ImageSprite.java 4.3.4.2Packages A Java package corresponds to a directory (or sequence of subdirectories) in the depot of source files. The source files developed by the Dumbledore team must belong to a unique package whose name is always written in all-lowercase ASCII letters. The prefix for all packages must be 4wd. Subsequent components of the package name vary according to the needs of the development effort, but should use preferentially single words and be short. Where to save: CVSHPIMS src File name: NA—a package is not a file, is a directory Examples: 4wd.util  would correspond to HPIMSsrc4wdutil 4wd.ui.common would correspond to HPIMSsrc4wduicommon 4.3.4.3Java Bytecode Compiled class files have the same name of the source file. The only important thing here is to define where the compiled files should be stored. Where to save: CVSHPIMSclasses<package subdirectories> File name: <class or interface name>.class Examples: Raster.class ImageSprite.class Team name: 4WD ICU-CMU MSE Studio Project, 2010 Page 9 of 7

×