Truck Me App

MS Research Project
Dated: 3rd May, 2019

Submitted To Dr. Ghulam Ahmad Farrukh

Submitted By ZarnabZafar, Hamid Ali, Sohail Khan, Usman Ashraf
Project Manager: ZarnabZafar
TruckMe

Document Overview

Title MS Research Project-1 Version 1.4

Project TruckMe Application Status Intermediate

Client FAST-NU Type External

Doc # RP-V1.4 Doc Date 03 May, 2019

Author(s) ZarnabZafar, Hamid Ali, Sohail Khan, Usman Ashraf Last Save 02 May, 2019

Description: Software Configuration Management Plan Document of TruckMe App

Revision History

Version Date Author(s) Section(s) Brief Description

1.0 8th Feb, 2019 ZarnabZafar, Hamid Proposal Document Documented submission of
Ali, Sohail Khan, Proposal
Usman Ashraf

1.1 1st Mar, 2019 ZarnabZafar, Hamid Software Project Software Project Management
Ali, Sohail Khan, Management Plan Plan, Deliverables and Process
Usman Ashraf

1.2 15th Mar, 2019 ZarnabZafar, Hamid Requirement Requirement specification and
Ali, Sohail Khan, Specification(RS),Risk risk management.
Usman Ashraf Management Plan

1.3 5thAprl, 2019 ZarnabZafar, Hamid Functional Specifications Functional specification of

Ali, Sohail Khan, Truck Me application
Usman Ashraf

1.4 3rd May, 2019 ZarnabZafar, Hamid Software Configuration Configuration Management
Ali, Sohail Khan, Management Plan Plan for Truck Me application
Usman Ashraf

MS Research Project Page 2 of 14

TruckMe

Table of Contents
8. Software Configuration Management 4
8.1. Introduction 4
8.1.1. Purpose 4
8.1.1.1. Configuration Identification 4
8.1.1.2. Configuration Control 4
8.1.1.3. Configuration Status Accounting 4
8.1.1.4. Configuration Audit 4
8.1.2. Objectives 5
8.1.3. Definitions, Acronyms and Abbreviations 5
8.2. Software Configuration Management Resources 6
8.2.1. Roles and Responsibilities 6
8.2.2. Tools and Infrastructure 7
8.3. Software Configuration Management Tasks 7
8.3.1. Identification of Configuration Items 7
8.3.2. Configuration Items (CIs) 8
8.3.3. Baseline Identification 9
8.3.4. Repository Identification 9
8.3.5. Configuration Item Identifier 9
8.4. Configuration Management and Control 10
8.4.1. Change Requests 10
8.4.2. Evaluation of Request 10
8.4.3. Implementation 11
8.5. Configuration Status Accounting (CSA) 11
8.6. Audit 11
8.7. Training 11
8.8. Archive and Retrieval 12
8.9. Conclusion 12

MS Research Project Page 3 of 14

TruckMe

8. SOFTWARE CONFIGURATION MANAGEMENT

8.1. Introduction
The Software Configuration Management (SCM) Plan specifically addresses configuration management
for software. It gives the details of identifying and defining the configuration items in the project,
controlling the release and change of these items throughout the project lifecycle. Recording and
reporting the status of configuration items, change requests, and verifying the completeness and
correctness of configuration items is part of this activity.

8.1.1. Purpose

8.1.1.1. Configuration Identification

The purpose of Configuration Identification is to define the functional and physical characteristics of a CI
in sufficient detail so that it may be developed, tested, evaluated, produced, competitively procured,
accepted, operated, maintained, and supported. Configuration Identification is established by baselines
plus approved changes. For purposes of this SCM Plan, Configuration Identification includes the
selection, creation, and specification of the following:

 Products that are delivered to the client

 SEM documents requiring Structured Walkthroughs (SWT)

8.1.1.2. Configuration Control

Configuration Control is the process of evaluating, approving or disapproving, and managing changes to
controlled items. This includes tracking the configuration of each of the CIs, approving a new
configuration if necessary, and updating the baseline.

8.1.1.3. Configuration Status Accounting

Configuration Status Accounting is the process of creating and organizing the information necessary for
the performance of configuration management. CSA is the recording and reporting of information
needed to manage configuration items effectively, including a record of the approved configuration
documentation and identification numbers, the status of proposed changes, deviations, and waivers to
the configuration. By Configuration Status Accounting, we can analyze the status of all the changes along
with the proposed changes and what components of the system may be affected by the new changes.

8.1.1.4. Configuration Audit

The purpose of Configuration audit is that all documents and software deliverables should be verified
and validated by Software Configuration Management (SCM) team before submitting.

MS Research Project Page 4 of 14

TruckMe

8.1.2. Objectives
Software Configuration Management (SCM) document is proposed to maintain the integrity and control
of system components and elements in project life cycle. This document helps in technical,
administrative and managerial level controls for the changes and integration of project components. All
types of configurations (software, data, documentation, etc.) are identified through configuration
management (CM). It provides a systematic control of changes in the project. Therefore, it maintains the
integrity and traceability of the configuration baseline throughout the project's life cycle.

8.1.3. Definitions, Acronyms and Abbreviations

SCM Software Configuration Management

RS Requirement Specification

FS Functional Specification

PM Project Manager

SCM Software Configuration Management

SDP Software Development Plan

SQA Software Quality Assurance

SCM Software Configuration Management

MS Research Project Page 5 of 14

TruckMe

8.2. Software Configuration Management Resources

8.2.1. Roles and Responsibilities

Role Assigned Responsibilities

Resource

Project Manager Zarnab Zafar ● Establish the overall project schedule for
SCM activities with Configuration
Management Manager (CMM)
● Validates that team members have been
trained in and knowledgeable of SCM
concepts and techniques and that they
are applied to project activities
● Ensure compliance with the SCM
standards and procedures set by the
CMM, the Change Control Board (CCB),
and any other affected groups as outlined
in this plan
● All communication of CM activities to
project stakeholders.
● Participation in CCB meetings.

Configuration Usman Ashraf ● Document the SCM Plan with assistance

Management from the Project Manager
Manager (CMM) ● Create and update the SCM Plan, as well
as communicating the contents of the
plan to the project team
● Identification of CIs.
● Create, manage and maintain the SCM
Plan, standards, and procedures
● Communicate any changes to the SCM
Plan, standards, and procedures to all
stakeholders
● Validate that all project team members
involved in the SCM process receive
training on their roles
● Update the SCM Plan, as appropriate
● Providing any required configuration
training.
● Approve changes to the SCM Plan

MS Research Project Page 6 of 14

TruckMe

Configuration Change Sohail Khan ● Review and approve/reject configuration

Control Board (CCB) change requests.
● Ensure all approved changes are added to
the configuration management.
● Seek clarification on any CIs as required.
● Prioritizes change requests
● Reviews the status of active change
requests
● Attend regularly scheduled meetings of
the CCB

Local Change Board Hamid Ali ● Reviews Requests for Change(RFC)

submitted by Change Control Boards
● Provide input to CRs.
● Present for Review to CCB.

8.2.2. Tools and Infrastructure

The tools and infrastructure that shall be used for product documentation and development are
following:
Code Repository: https://github.com/
Bug/Defects: Microsoft Excel
Documents Repository: https://drive.google.com/drive/folders/1ci7brL3q7yuYlsPyuk3s0i7mgtIT8K_4
Project Mails Archives: University E-mail/Personal E-mail
Project Tracking and Control: Microsoft Project Plan

8.3. Software Configuration Management Tasks

8.3.1. Identification of Configuration Items
In this SCM Plan, work products are considered for configuration management based on the following
criteria. A work product is any tangible item that results from a project function, activity or task.

● May be used by one or more work groups

● Are expected to change over time either because of errors or change of requirements
● Are dependent on each other in that a change in one mandates a change in another/others
● Are critical to the project

Following are the CIs covered in configuration management:

● Project Management documentation, including SPMP and Project Plan

● Models
● Interfaces

MS Research Project Page 7 of 14

TruckMe

● Product/Application data such as lookup tables, system files

● Source code and executable code
● Test cases
● Test data
● Status/Defects reports, quality review reports, etc.

8.3.2. Configuration Items (CIs)

Following are the configuration items that project team have identified for Truck Me application.
However, changes can be made if required as the project progresses.

Configuration Item Responsibility When item is put

under control

Software Project Schedule Zarnab Zafar May 01, 2019

Software Project Management Plan Zarnab Zafar May 01, 2019

Requirements Specifications Hamid Ali May 15, 2019

Risk Management Plan Zarnab Zafar May 15, 2019

Functional Specification Sohail Khan Apr 05, 2019

Software Design Specifications Sohail Khan May 03, 2019

Software Quality Assurance Plan Hamid Ali May 03, 2019

Software Test Plan Zarnab Zafar May 03, 2019

Software Configuration Management Plan Usman Ashraf May 03, 2019

Database Sohail Khan TBD

Software Development Plan Zarnab Zafar TBD

MS Research Project Page 8 of 14

TruckMe

8.3.3. Baseline Identification

In this SCM Plan, a software baseline is created by the identification and labeling of CIs at a specific point
in time. A baseline represents the current approved configuration. It is the process of defining each
baseline which project team will establish during the software life cycle. It also describes the software
configuration items and their documentation that make up each baseline. It is the basis for subsequent
control of the configuration item.

8.3.4. Repository Identification

All the configuration’s items are managed in secure repository and artifacts are placed with version
control in the following repositories.

1. Google Drive (Documentation Repository)

MS-Research-Project

● Project Schedule
● Software Project Management Plan (SPMP)
● Requirements Specifications (RS)
● Functional Specifications (FS)
● Software Design Specifications (SDS)
● Risk Management Plan (RMP)
● Software Configuration Management Plan (SCMP)
● Software Quality Assurance Plan (SQAP)
● Software Test Plan (STP)
● Software Development Plan (SDP)
● Lessons Learnt (LL)

2. GitHub (Source Code Repository)

https://github.com/zarnabzafar

8.3.5. Configuration Item Identifier

Configuration Item Identifiers are used to label all of the CIs that make up a particular grouping such as
an application release, a project development phase or documentation changes.This identification
scheme preserves all the files that are used to create each release and exactly which versions of those
files are used. This scheme works for the application installations and then for subsequent upgrades.

Identifiers are used to label the documentation deliverables in a project. For instance, at the end of the
system design stage, all of the approved deliverables will be labeled and preserved for future reference.
After the completion of the project, many of the deliverables will need to be updated to reflect changes

MS Research Project Page 9 of 14

TruckMe

in documents. Those deliverables are assigned identification labels so that their current state can be
identified and preserved for future reference.

CI Identification Convention is as follows:

[PhaseNo] - [BL/CRno] - [DocTitle] - V[Major].[Minor]

1. [PhaseNo]: Represents the phase number

2. [BL/CRno]: Represents the baseline or change request number last modified in document
3. [DocTitle]: Represents the title of the document
4. [Major]: Major version number as per revision
5. [Minor]: Minor version number as per revision

For Example:

P1 -BL - FS - V1.8

8.4. Configuration Management and Control

The change control process ensures that changes which have been initiated are classified and evaluated,
approved or disapproved and only approved changes are implemented, documented and verified.
Changes encompass both error correction and enhancement. The degree of formality necessary for the
change process depends on the project baseline affected and on the impact of the change within the
configuration structure.

8.4.1. Change Requests

This section of SCM Plan will document the nature and functional requirements addressed by a
proposed change to the software or documents. Project team and advisor can request for change. After
posting change request, CCB is responsible to review and make decisions to approve or reject the
change request. In case of rejection, CCB is liable to give explanation. After approval, change will be
implemented and change request is closed.

The change request flowchart is shown in Appendix 7A and change request form is shown in Appendix 7
B.

8.4.2. Evaluation of Request

This section provides adequate analysis of changes in terms of impact to system functionalities,
interfaces, schedule, and requirements. Each change should be analyzed for impact on software safety,
reliability, maintainability, and efficiency. The configuration manager routes the CR to the CCB. The CCB
evaluates the desirability of a change versus the impact of the change. In some cases, CR is screened by
CCB before it is analyzed. This approach saves the schedule change for changes that do not have any
chance of approval.

MS Research Project Page 10 of 14

TruckMe

CCB will conduct CR impact analysis and produce a document, which will describe the changes that are
to be made to implement the CRs, CIs, and documents. The documentation becomes part of the change
package along with the CRs.

The CCB may approve, disapprove, or defer a change request. CCB may have to request more
information and additional analysis. Rejected CIs are sent to the originator along with the CCB's
rationale for rejection. Deferred CRs are filed and are sent back to the board at the proper time. CM
sends approved items to the development team unless it is of a level that needs to be processed
through higher level CCBs. If additional levels of approval are needed then the CCB submits the CR
package to CMM.

8.4.3. Implementation

After approval of change request, the project Manager will assign the appropriate technical resources to
the task. SQA team will test all the changes made as per the change request on development
environment. Moreover, the associated documentation has to be revised to reflect the change. Once
the change has been made and local testing is completed, the revised component and documents are
returned to the control of the program library. Upon verification, the new version takes its place in the
sequence of baselines.

8.5. Configuration Status Accounting (CSA)

The statuses of all configuration items are maintained through the project CR Logs. The CR logs are used
to track this information.

8.6. Audit

Audit is the process of verifying deliverable documents or software baseline that contains all the items
which are required. These items have been verified from the requirement of the deliverable. It consists
of audits that determine the extent to which the actual CI reflects the required physical and functional
characteristics. We will perform informal audits of the deliverable, as the time availability for audit is
short.

8.7. Training

It is the responsibility of the CM to provide training of SCM to all project team members. In case of any
discrepancies or any confusion, team members will ask CMM for the issue. CMM should also maintain
the history of the changes by using versioning control on Google Drive.

MS Research Project Page 11 of 14

TruckMe

8.8. Archive and Retrieval

This project follows GitHub archiving policies for software deliverable and Google Drive archiving
policies for document deliverables. The Configuration Management and Control section 7.4 of this plan
contains information regarding the methods for retention and retrieval.

8.9. Conclusion
This document provides the vision of configuration management throughout the life cycle of the project.
It describes the identification of configuration items and how to manage the CIs with the changes. SCM
plan provides the detailed hierarchy of document version control under the responsible owner of the
document.

Annexes (Appendices)

MS Research Project Page 12 of 14

TruckMe

Appendix 7A: Change Request Flowchart

MS Research Project Page 13 of 14

TruckMe

Appendix 8B: Change Request Form Sample

MS Research Project Page 14 of 14