Software Maintenance and Change Control

Running head: WEEK FIVE SOFTWARE MAINTENANCE AND CHANGE CONTROL

Workshop Five

Software Maintenance and Change Control

Software Configuration Management and Change Control Policies

This policy document is intended to be distributed to all software development and testing staff members. The scope of this document will discuss Inventive Technologies policies and standard operating procedures pertaining to the development, testing, and maintenance of all software applications and components. The following is brief overview of the areas covered by this policy: 1. Tools utilized 2. Change Management 3. Development process 4. Documentation 5. Version control 6. Testing 7. Release management Tools Utilized Rich (any edits?) During development of applications for the Windows platform, Microsoft Visual Basic, Visual Basic .Net, or VB script are the languages of choice. When developing client side code for web based applications, JavaScript is to be utilized. However, exceptions to this rule may be granted if the preferred languages do not support a particular development need or present a technological limitation. An example of this technological limitation is Visual Basic 6 does not support writing multi-threaded applications. All software, utilities, and associated scripts must be contained in a Source Control database. Any code produced for the Window environment must be stored into the Microsoft Source Safe database. Inventive Technologies will utilize an issue tracking database in order to store all reported problems, defects and requested feature enhancements. Moreover, our corporation will utilize multiple white box and black box testing applications. Additionally,

Workshop Five

Software Maintenance and Change Control

Inventive Technologies <removed also> employs stress testing applications where applicable based upon the application or component being developed. Change Management Any new software or changes to existing software shall require approval by the Configuration Change Board (CCB). The CCB will evaluate changes for impact to existing software, cost of change, resources needs, project schedules, impact to other customers product, and fit with existing business needs. Upon approval, the project manger will provide a detailed project plan which will be approved by the CCB. Once approved, project milestone reviews will be conducted to ensure that software changes are implemented per plan and meet the agreed upon objectives. Software changes will be documented with appropriate requirements, specifications, design descriptions and any other documents needed to accurately define the software. Changes to these documents will be reviewed and approved by the appropriate cognizant engineers, project managers, quality assurance and any other affected stakeholders. In an effort to manage scope creep and accurately capture the content of software, all software changes will be documented. This documentation will be managed per the appropriate document control procedures. Changes to software will be conducted on an isolated and self-contained environment to ensure no cross-contamination with existing released software. All software builds shall be conducted on controlled systems designated specifically for the build function. Code builds will be versioned per the current build procedures with each build having a unique identification and shall meet the requirements defined in the project plan. In an effort to self-correct change management processes, periodic code audits will be conducted by the quality assurance organization. Each product will be audited per quality assurance procedures, at least once a year, if a product has undergone software change within a calendar year. The objectives of the audit process are the following: comparison of new

Workshop Five

Software Maintenance and Change Control

software baseline to previous baseline, assurance that standards have been met, establish completeness of software testing per traceability between requirements, specifications and test cases, thoroughness of documentation, and fulfilled execution of the change management process (University of Phoenix, 2005, p. 22). If deviations are identified they will be managed per the corrective action system. Development All software applications and code developed by Inventive Technologies will initially be developed and debugged on the local developers workstation. All developed applications must adhere to Inventive Technologies standard coding practices. When developing new code or editing existing code, the latest labeled version of the application should be retrieved from the source control server and stored on the developers workstation. Any source code files which are to be edited by the developer must be checked out from the source control server to ensure exclusive access. Development activities should make certain the new software or software upgrades do not compromise security. Upon completing the necessary development or debugging, the source control file should be checked back in to the source control server. Additionally, all code must contain comments at the top of each source file describing the function of the code. Any revisions or changes must be documented with the following information: Date of change Author of code Description of change Impact and dependencies (including any applications or objects which directly rely upon or use this code or object) Weak change control procedures can corrupt applications and introduce new security vulnerabilities. Change control considerations relating to security include the following:

Workshop Five

Software Maintenance and Change Control

Restricting changes to authorized users Reviewing the impact changes will have on security controls Identifying all system components that are impacted by the changes Maintaining strict version control of all software updates, and Maintaining an audit trail of all changes (Federal Financial Institutions Examination Council, (n.d.)).

Documentation Our corporations documentation policy requires internal and external use of documentation within source code. This policy considers the completion of this documentation as the responsibility of all developers. In addition to our core development group, associates from within our Documentation department are to be engaged for review and final publication of all external, therefore client-facing documentation. The documentation portion of our policy includes information throughout the SDLC of our proprietary programs. These documentation requirements include business and analysis documentation, design specifications, developers application documentation, object and application dependencies, test plans and end-user documentation. For future reference, all documentation must be archived following the same practice as our source control procedures. One outcome of our planning processes will be the requirements document. This is to include but not be limited to the specific application features and agreed upon functionality based on client need. Secondly, the design specifications will outline the overall application design and intended technologies to be used for completion. During the development process, the assigned developers are required to document the applications purpose to include the object model, methods, and properties. Additionally, this document is to include the intended use, user input and expected output. Should any object be imbedded into the source code, explanation of the necessity of these objects is to be included

Workshop Five

Software Maintenance and Change Control

within the developers documentation. Lastly, all dependencies are to be described for better understanding of application requirements and functions. As our applications complete the development and design phase, they will move onto the analysis phase. Throughout the testing period, documentation consists of test plans in order to fully analyze the applications functionality. Initially, these test plans will be considered working drafts, so that our QA team can make adjustments as needed. The finalized test plans will be transferred to our QC team along with the source code for final inspection. In the event that our QC team discover any discrepancies in the two, both will be returned to QA for further review. Once an application had passed the QA/QC process, all documentation will be gathered in an organized fashion and submitted to our documentation department. One of our qualified analysts will review documentation for creation of end-user documentation. All end-user documentation will consist of application release notes, bug fixes and help documents. Prior to the release of our application, documentation will be completed and reviewed from a managerial perspective. As stated in our policy, documentation must be included with the announcement of beta or GA software. Lastly, all documentation will be warehoused with the source code for future internal reference. Version Control An essential part of Inventive Technologies software maintenance and change control process is version control. This part of the process is used to error check the source code that our programmers submit. All source code must be contained within the source control application. This type of application is a necessity at Inventive Technologies to ensure the different programmers code is kept in tact. Without this type of application, one programmer could overwrite another programmers code, and this could prove to be disastrous to our company.

Workshop Five

Software Maintenance and Change Control

The inclusion of version control applications to our companies software maintenance and change control policy, has led to improvements at Inventive Technologies in communication between programmers and developers; time spent on projects; amount of costs spent on a project; and an overall better company image. When developing new code or editing existing modules, all code must be checked out to ensure exclusive use. Upon completion of the changes; development; or debugging, all modules must be checked back into source control. Upon check in, the following notes must be associated with the file: Date of change Author of code Description of change Impact and dependencies

When creating releases of the applications or objects, all source code must be labeled. The labeling process provides a snapshot of the latest checked in version of all source code files at a particular point in time (Microsoft, n.d.). Notes should be added to each label indicating the date of the build as well as the scope of the release (i.e. internal use, testing, beta release, or production release). Testing The testing phase of development is an ongoing process that actually starts with the development and review of requirements and continues through to final product release. The scope of this section covers physical testing of software to ensure that the product meets the requirements, specifications and intended use as defined. There are three main categories of testing, unit, verification and validation. Unit testing is testing of individual software units or groups of related units (IEEE std 610.12-1990). For the purposes of this plan the term unit is interchangeable with component or

Workshop Five

Software Maintenance and Change Control

module. The purpose of unit testing is to show through objective evidence that the module being tested meets the applicable requirements/specifications for that specific module. The scope of this level of testing is very narrow. Verification testing is confirmation by examination and provisions of objective evidence that specified requirements have been fulfilled (IEEE std 1012-1998, Annex 1). This level of testing is similar to unit testing but takes the entire program and its requirements/specifications into account. The entire program requirements set may not be tested in the case of software changes, however, regression testing must be considered to detect unintended effects of such changes. Validation testing is confirmation by examination and provisions of objective evidence that the particular requirements for a specified intended use are fulfilled (IEEE std 1012-1998, Annex 1). Validation differs from verification in that the intended use of the program must be considered. Intended use takes the end-user into account and expands the scope of testing beyond just requirements and specifications but how the end-user will actually employ the software. All three categories of testing are required for both new software and software changes. Each category has four basic elements, a test plan, a test protocol, test execution, and a test report. These testing categories will vary in scope for each project but shall be addressed in the project plan. Test plans and protocols require approval prior to use. Test reports must be reviewed and approved before they can be considered objective evidence. Any deviations or issues identified during any phase of testing shall be documented and dispositioned before software can be formally released. Although the testing process defined above contains three distinct categories, it is the responsibility of the CCB, project management and quality assurance to ensure that appropriate testing is conducted for the scope of the project. In addition, pre-defined testing can not identify all software issues. Testing functions are encouraged to include a reasonable amount of

Workshop Five

Software Maintenance and Change Control

exploratory testing into any defined test activities. This type of testing allows for exploration and a better understanding of our products. It is up to the discretion of functional managers to determine the amount of resources applied to this effort. Release Management In order to ensure the accurate release management of all maintenance and change control, of code and software applications, Inventive Technologies, has created a centralized build server. This centralized build server will be used to compile all software releases for both internal testing and external release. Furthermore, this build server has been configured with a standardized install of the operating system and only the necessary software needed for compilation. Prior to performing builds, the latest version of source code should be retrieved from the source control server. Within the source control application, this source code version must be labeled with the newest version control. Release versioning is a simple way to uniquely identify a particular release. It is a top-level assembly identifier that provides an easy handle for reference. (Etude, Inc., 2002) Appropriate version release notes should be generated using the notes captured from the source control application and the issue tracking database. These lists of changes will serve as the basis for the future testing process. When creating releases for change control, the scope of the distribution should be included in the label within the source control application. Exporting all fixes and product enhancements as noted in the issue tracking database will assist in the generation of appropriate release notes. Internal testing will confirm that all release note documentation for tracking database and source control server are accurately updated and acceptable for external release. It is the goal of Inventive Technologies to release at least one major maintenance packets of our software approximately every 18 months to two years. The company also attempts to do minor maintenance releases of the software (i.e. service packs, security updates, and minor feature enhancements) approximately every three to six months. Critical

Workshop Five

Software Maintenance and Change Control

10

maintenance and change control will be released on an as needed basis following Inventive Technologies appropriate release management policies.

Workshop Five

Software Maintenance and Change Control

11

References Etude, Inc., Software Release Management (2002). Retrieved May 29, 2005, from http://www.etudeinc.com/collateral/whitepapers/Software_Release_management.pdf#searc h='software%20Release%20Management. Federal Financial Institutions Examination Council. (n.d.). Security Controls Implementation. Retrieved May 28, 2005, from http://www.ffiec.gov/ffiecinfobase/booklets/information_security/04e_Sys_Dev_Acquisition_ Maintenance.htm. Microsoft. (n.d.). Microsoft Visual Source Safe: Features Overview. Retrieved May 30, 2005, from http://msdn.microsoft.com/vstudio/previous/ssafe/productinfo/features. The Institute of Electrical and Electronics Engineers, Inc. (1990). IEEE Standard Glossary of Software Engineering Terminology. (IEEE std 610.12-1999). The Institute of Electrical and Electronics Engineers, Inc. (1990). IEEE Standard for Software Verification and Validation. (IEEE std 1012-1998). University of Phoenix. (2005). Chapter 31, Software Configuration Management [Quality Software Project Management]. Retrieved May 16, 2005, from University of Phoenix, My Course Info POS370, Course Materials Web site: https://ecampus.phoenix.edu/secure/facWeb/CourseFiles.asp/Configuration_Manageme nt_A_Whole_Chapter.pdf.

Workshop Five