SCHOOL OF COMPUTING AND IT DEGREE

PROGRAMME

Bachelor of Software Engineering (Hons)

Assignment 1
ITS 60703 Software Process

Hand In Date: 26th March 2015 (Thursday)

Hand Out Date: 17th April 2015 (Friday by 6:00 p.m.)

Instructions to students:
The assignment should be attempted in groups.
Complete this cover sheet and attach it to your assignment

Student declaration:
I declare that:
I understand what is meant by plagiarism
The implication of plagiarism have been explained to us by our lecturer
This project is all my work and I have acknowledged any use of the published or
unpublished works of other people.
Name
Student ID
Cheong Wan Hoy
0314101
Koh Keng Chye
0315048

Software Project Team Recruitment Process

PURPOSE

Provides the organization with necessary human resources

Ensure a supply of skilled, experienced and qualified personnel
Maintain the competencies of human resources to be consistent with the business needs

INPUTS

Job and position description documentation

Hiring specifications
Human Resource Plan
Documents from applicants (eg. resume)

ENTRY CRITERIA

Vacancy available
Need for human resources for project and/or business processes
Need for specific skills and knowledge

PROCESS FLOW DIAGRAM

TASKS
<A sequenced list of the specific steps and their descriptions that must be performed to execute
the process>
T1. Requirements specification
-

Specification and documentation of job description, position description, and hiring

specifications
T2. Internal search
- Search internally for qualified personnel before searching externally.
T3. Advertising
- Advertising the job vacancy on various media such as websites and newspapers.
T4. Screening

Screen through job applicants based on their qualifications as specified in documents

received from them.
T5. Interview
The interviewer gains further understanding of the applicants skills, personality, goals,
and other criteria associated with the job position applied to determine if the applicant is
qualified for it.
T6. Recruitment
-

After passing through another screening process, the successful applicants are recruited
to join the business.

VERIFICATION
V1. Milestone reports
-

Produce periodical reports at milestones to review and verify if the process adheres to ISO
standards.

METRICS

Indirect costs (candidate review and interview time, administrative and accounting costs)
Ratio of offers to acceptance
Cost of unfilled positions

EXIT CRITERIA

Need for qualified and skilled personnel is satisfied

Sufficient human resource for projects and business processes achieved

OUTPUTS
The following deliverables are outputs of the test execution process:
D1. Job and position description documentation
-

Job description describes a non-management job, covering title, duties and

responsibilities. Position description describes management positions.
D2. Hiring specification documentation
-

Defines the education, experience and skills required for an individual to perform
effectively in the position applied for.
D3. Milestone Reports

Periodically reports used to review and verify the process at milestones to ensure that the
process is being performed as required.
D4. Recruitment documentation

The processes and results of the recruitment process are compiled and documented in detail
for the next stage.

The following quality records are outputs of the system test execution process:
Required Record

Custodian

Retention Period

Job and position description

Human Resource Department

2 years

Hiring Specifications

Human Resource Department

2 years

Applicant data

Recruitment Office

1 year

Recruitment documentation

Recruitment Office

5 years

Quality Management Process

PURPOSE

Assure that products or services meets the customer satisfaction

Delivering the project to meet time, cost and quality
Raise the quality levels within the project

INPUTS

Stakeholders Requirements
Organization policies

ENTRY CRITERIA

Stakeholder requirements definition process must be completed

Projects require certain level of quality
Consistency of quality level is required for the organizations missions

PROCESS FLOW DIAGRAM

TASKS
T1. Establish quality management goals
This step requires the project manager/quality manager to establish the quality management
goals that need to be achieve throughout the project based on the customer satisfaction. The
outcome of this step is the D1: Quality Management Plan.
T2. Conduct periodic reviews of project quality plan
This step requires the quality reviewer to review the project quality plan monthly to assure the
quality goals are established based on the stakeholder requirements. Deliverable Quality review
form will be produce for the purpose of monitor the stakeholders review on the project quality
plan.
T3: Monitor the status of quality management goals

To check whether the quality management goals have been achieved or not. This step require
the quality manager to keep track of the each quality goal.
T4: Implement corrective actions
To come out the solutions or actions for the quality goals which are not achieved.

VERIFICATION
V1. Verify against the stakeholders
This verification is necessary to assure the quality goals are established based on the
stakeholders requirements.
V2. Verify against the clients
The quality goals need to verify based on the customer satisfaction to know whether the goals
have been achieved or not.

METRICS

Customers Satisfaction (Scale x Efficiency x Quality)

Scale: Numbers of customers complaints received
Efficiency: Times to respond for one complaint
Quality: Percent of complaints settled in one interaction

Quality Status (Numbers of actual reviews/ Numbers of planned reviews x 100%)

Numbers of actual review: The numbers of total actual review done
Numbers of planned review: The numbers of total planned review according the quality
management plan

EXIT CRITERIA

Each goal / objective in the quality management plan have been met.
Quality management plan approved by the stakeholders.

OUTPUTS
The following deliverables are outputs of the test execution process:

D1: Quality Management Plan

The plan contains the quality management goals/objectives, policies, standards and
procedures to manage the quality of the projects.

The following quality records are outputs of the system test execution process:
Required Record

Custodian

Retention Period

Quality Management Plan

Quality Manager

Indefinitely

Software Product/Service Acquisition Process

PURPOSE

Obtain a software product and/or software service to achieve a goal contributing to

business objectives and needs

INPUTS

Documentation of system requirements

Documentation of acquisition requirements
Agreement contract

ENTRY CRITERIA

There is a need for the acquisition of software products/services to fulfill system

requirements

PROCESS FLOW DIAGRAM

TASKS
<A sequenced list of the specific steps and their descriptions that must be performed to execute
the process>
T1. Acquisition preparation
-

Describe the need to acquire a system, software product or software services

Define and analyze system requirements

- Risk and cost-benefit analysis

- Prepare, document and execute acquisition plan
- Document acquisition requirements
T2. Acquisition advertisement
- Communicate the request for the product/service to identifies suppliers
T3. Supplier selection
- Select supplier based on the evaluation of the suppliers proposals and capabilities
T4. Contract agreement
- Prepare, negotiate or change a contract with the supplier
T5. Agreement monitoring
- Monitor suppliers activities to ensure that they act according to the agreement
T6. Acceptance and acquisition
- Conduct acceptance review and testing of product/service
- Acquisition of product/service
T7. Payment and closure
-

Make payment and other agreed upon considerations to the supplier

VERIFICATION
V1. Documentation of system requirements
V2. Documentation of acquisition plan and acquisition requirements
V3. Review, verify, and validate suppliers activities in accordance to the agreement
V4. Conduct acceptance review and acceptance testing of product/service

METRICS

Commercial practices (Contract specifications, credit card purchases)

Acquisition performance (Contract defaults, contract charges)
Schedule (Acquisition phase time, logistics response time)

EXIT CRITERIA

Conditions of agreement has been satisfied

Product/service has been accepted and acquired
Payment has been made to the supplier

OUTPUTS
The following deliverables are outputs of the test execution process:
D1. System requirements documentation
-

Includes business, organizational, user, security, and other critical requirements along
with related design, testing, and compliance standards and procedures.
D2. Acquisition Plan documentation
-

Details requirements for the system, planned employment of the system, type of contract
to be employed, responsibilities of parties involved, risk considered as well as risk
management methods.
D3. Acquisition Requirement documentation
-

Describes system requirements, terms and conditions, technical constraints, control of

subcontracts, etc.
D4. Agreement contract
-

Addresses acquisition requirements, including the cost and schedule, of the deliverable
product/service. Also addresses usage, proprietary, ownership, warranty and licensing
rights related to the deliverable.

The following quality records are outputs of the system test execution process:
Required Record

Custodian

Retention Period

System Requirements
Documentation

System Analyst

6 months

Acquisition Plan
Documentation

System Analyst

2 years

Acquisition Requirement
Documentation

System Analyst

2 years

Agreement Contract

Acquirer

5 years after closure

References
Calderone, K. (2012). The Mathematics of Customer Satisfaction | Cvent Survey.
Survey.cvent.com. Retrieved 4 April 2015, from http://survey.cvent.com/blog/customerfeedback-how-tos/the-mathematics-of-customer-satisfaction
Goff, S. (2008). Measuring and Managing Project Quality (1st ed.). www.asapm.org,
www.ProjectExperts.com. Retrieved from
http://sinche.uom.gr/sites/default/files/managingquality.pdf
Pinker, A., G. Smith, C., & W. Booher, J. (1997). SELECTING EFFECTIVE ACQUISITION
PROCESS METRICS (1st ed.). Defence Acquisition University. Retrieved from
http://www.dau.mil/pubscats/pubscats/AR%20Journal/arq97/pinke.pdf
Simplicant,. (2014). Recruiting Metrics To Improve Your Hiring Process. Retrieved 17 April
2015, from http://www.simplicant.com/blog/recruiting-metrics-improve-hiring-process/

Protech Corporation

CDPP Life Cycle (CLC)

Cloud-based Digital Portfolio Platform / CDPP

Software Process Improvement Plan
Version 1.0
4/17/2015

Document Number: 1.0

Contact Number: 0163525166

Protech CLC

Table of Contents

Table of Contents
1. Introduction .............................................................................................................. 4
2. Overview ................................................................................................................... 4
2.1
2.2
2.3

Key Stakeholders ............................................................................................ 4

Key Milestones ................................................................................................ 4
Project Deliverables ........................................................................................ 5

3. Assumptions/Constraints/Risks ............................................................................. 5
3.1
3.2
3.3

Assumptions.................................................................................................... 5
Constraints ...................................................................................................... 6
Risks ............................................................................................................... 6

4. Process Review Background .................................................................................. 7

4.1
4.2

Process Review Methodology ......................................................................... 7

Process Review Findings and Recommendations .......................................... 7

5. SPI Approach ........................................................................................................... 8

5.1
5.2
5.3

Goals ............................................................................................................... 8
Methodology.................................................................................................... 8
Roles and Responsibilities .............................................................................. 8

Appendix ...................................................................................................................... 10
Acronyms ..................................................................................................................... 11
Glossary ....................................................................................................................... 12
Referenced Documents .............................................................................................. 13
Record of Changes ..................................................................................................... 14
Approvals ..................................................................................................................... 15
References ................................................................................................................... 16

List of Figures
No table of figures entries found.

Software Process Improvement Plan Version 1.0

ii

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

List of Tables

List of Tables
Table 1: Acronyms ....................................................................................................... 11
Table 2: Glossary ......................................................................................................... 12
Table 3: Referenced Documents .................................................................................. 13
Table 4: Record of Changes ........................................................................................ 14

Software Process Improvement Plan Version 1.0

iii

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Introduction

1. Introduction
This Software Process Improvement Plan (SPIP) describes the approach for continued software
development process improvement during the life cycle of the Cloud-based Digital Portfolio
Platform (CDPP). The document identifies the specific actions that will be taken to improve the
software process, and outlines the plans for implementing those actions. The intended audience
for the document are the key stakeholders such as project managers and the developers that are
interested in the project. The content inside this document is remains updated at the date of
publishing the current version of the SPIP. It is possible that other changes will emerge as the
project progresses and if so they will be covered in future releases of this document.

2. Overview
CDPP Project is the companys attempt to develop a cloud - based Portfolio Platform, whereby
users can showcase and manages all the digital evidence of their skills, achievements, work
experiences and related artifacts of portfolio in such a way easy, time-saving and effective. The
platform is to believe that able to improve the enterprises and companies human resources
through the recruitment of specific talented employees. The users for the system probably are the
authenticated user, web administrator and database administrator. Authenticated users will use
the browser to access the system to create and manages their e-portfolio.

2.1

Key Stakeholders

The stakeholders in the project that have different roles and responsibilities are as follows:
Stakeholder

Responsibility

Company
Investors

Provide the necessary resources for the company to carry on the project

Clients

Define the softwares functionality and approve the end result of the
project.

2.2

Key Milestones

The key project milestone are as follows:

Milestone

Milestone Goal

Document outline
complete

Outline the documents required in the project by describing the

purpose and content of the documents.

Proposed software
approval

The proposed basic system concepts have been approved by the

clients and the project is authorized to proceed.

Software Process Improvement Plan Version 1.0

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Assumptions/Constraints/Risks

Requirements review

Software Requirements Specification (SRS) are complete, correct

and approved by the clients.

Design specification
review

Assure the Software Design Specification (SDS) made based on the

requirements established in SRS.

Design
Implementation
review

The system architecture are approved and are suitable for the
development of the code.

System test review

Ensure all the systems features are tested.

Document complete

All the important documents such as SRS and SDS must be

completed at the end of the project.

2.3

Project Deliverables

The following is a list of Project deliverables are identified as the key deliverables to easily
keep track of the project completion. It is possible that other deliverables will be identified
during the course of the Project and these will be included in future releases of this document.
Deliverable

Project Stage

Software Process Improvement Plan (SPIP)

Project initiation

Software Requirement Specification (SRS)

Project initiation

Project Schedule

Project initiation

Software Design Specification (SDS)

Design Phase

3. Assumptions/Constraints/Risks
3.1

Assumptions

The following are the known assumptions, which have been assumed for the implementation of
the SPI at the date of publishing the current version of the SPIP. It is possible that other
assumptions will be made as the SPI progresses and if so they will be covered in future releases
of this document.
Ref.
A1

Assumption
Software Processes were strictly followed according to the SPD

Software Process Improvement Plan Version 1.0

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Assumptions/Constraints/Risks

A2

There are flaws in SPD

A3

The process can be improved to deliver software on time and within budget.

A4

There is a process that describes how the software is developed, and how
this development is managed

3.2

Constraints

The following are the major constraints, which have been identified for the implementation of the
SPI at the date of publishing the current version of the SPIP. It is possible that other constraints
will be made as the SPI progresses and if so they will be covered in future releases of this
document.
Ref.

Constraints

C1

Project team members dont have the capacity to deliver the project scope

C2

Quality assurance programs is required to control the quality level within the project.

C3

Deadline for the project to deliver each key components of the software

C4

Need to program in a certain language

3.3

Risks

The following are the major risks associated with the implementation and non-implementation of
this SPIP which are facing for the successful implementation of SPI. It is possible that other risks
will be made as the SPI progresses and if so they will be covered in future releases of this
document.
Ref.

Risk Item

Mitigation Strategy

R1

Recruitment problems

Alert customer to potential difficulties and

the possibility of delays.

R2

Changes to requirements that require

major design rework
are proposed

Derive traceability information to assess

requirements change impact.

R3

The time required to develop the

software is underestimated.

Investigate buying components.

Software Process Improvement Plan Version 1.0

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Process Review Background

4. Process Review Background

Feedback on the software development processes are collected from process users through
formal process reviews. This is a basis for process improvement as it reflects the changing
requirements within the software project. Lessons learned regarding software process
development and implementation should be used to guide process improvement strategies.
Continuous Software Quality Assurance (SQA) audits of process adoption and compliance
identifies areas where improvements can be made. Additionally, the audit helps to highlight
problems in software development processes, as well as the software process improvement
program itself.
Besides that, measurement and analysis of data collected and documented across projects are
reviewed to identify areas of improvement.

4.1

Process Review Methodology

The project team recruitment process was evaluated using the Lean methodology. This
methodology looks at processes with the intention of eliminating waste at each stage of the
process, and regards everything that is not adding value to the customer as waste. Waste must
be clearly identified in order to eliminate it. An activity is considered waste if it can be bypassed
to achieve the same results.
The first step of the process review process is to utilize the value stream mapping technique to
analyze the current state of the process to identify waste. The second step is to recognize and
point out sources of waste to eliminate them. The process of removing waste is to take place
iteratively until the waste has successfully been eliminated.

4.2

Process Review Findings and Recommendations

There are some findings and improvements on the Software Project Team Recruitment Process
after the process was evaluated with the Lean Methodology. The findings show that the process
have a great opportunity for improvement by identifying the non-value-added activities or waste.
The wastes on the process have been identified and serves as the reasons for the process to be
improve in the current SPIP.
Waste comes in three main forms according the definition of waste in Lean System. One of the
form for waste is Muda which also known as Seven form of waste. The form of waste that have
been identified through the findings of the process review was Extra Processing. The waste is
recruiters still need to look at email and the hundreds of resumes or electronic profiles that have
accumulated during the screening activity.
The team recommends that an additional screening activity might be required in approaching the
potential candidates and reduce the burden of the recruiter team. The additional screening activity
will be provide a small test for the candidates to test their ability on certain skills that are necessary
for the job. This aims is to further narrow down the scope of the candidates so recruiters only
need to look at the candidates documents who have passed the tests.

Software Process Improvement Plan Version 1.0

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

SPI Approach

5. SPI Approach
To improve the process and meet the organizations goals, the CMMI staged representation will
be used as a model. Based on the staged CMMI model definition of capability levels, the maturity
level that the organization is operating at is at the initial stage (Level 1). At this stage, the
processes are chaotic and improvised; requirements are unmanaged; project success is
attributed to the competence of the staff instead of a proven process; and projects often go over
their budgets and do not meet set deadlines and schedules.
The organization plans to advance to the managed stage (level 2), where requirements are
managed; processes are properly planned, documented, executed, monitored, and controlled;
projects are planned and executed according to plan; and processes still remain valid under crisis.
To implement these changes, the agile approach will be used.

5.1

5.2

Goals
To improve upon the effectiveness of the screening process.
To further screen out more qualified candidates.

Methodology

The process improvement will be done using the agile approach in order to adopt the process
improvement program to constantly changing business needs, and deliver more value to the
business. As many organizations are utilizing the agile software development method, it is natural
to adopt similar models for process improvement. Besides that, the agile approach helps the
process improvement to be delivered quickly and effectively within budget using frequent
feedback.
The iterative process of the agile approach enables the software process improvement team to
gain a better understanding of the strengths and weaknesses of the processes, and the business
values. Furthermore, the agile approach can enhance the collaboration between the stakeholders
and the software process improvement team as there are frequent interactions and
communication between those involved in the software process improvement.
The process improvement will be monitored and controlled through agile iterations. With every
iteration many documents, slides sets, and supporting materials are produced that the software
process improvement team can utilize to further review, align, and improve the software
development processes.

5.3

Roles and Responsibilities

Role

Software Process Improvement Plan Version 1.0

Responsibility

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

SPI Approach

Executive Leadership Group

(ELG)

Review and approve SPI plans and budgets

Review SPI progress and results periodically
Sponsor team for the software process
improvement program

Management Steering Group

(MSG)

Frequently presents plan details, progress, and

status reports to the ELG
Primary accountability for the software
improvement programs success

Software Engineering Process

Group (SEPG)
Process Action Teams (PATs)

Software Process Improvement Plan Version 1.0

Made up of a variety of software engineering

professionals
analysts, architects, developers, specialists, etc.

Undertakes process improvement tasks

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Appendix

Appendix

Software Process Improvement Plan Version 1.0

10

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Acronyms

Acronyms
Acronym

Literal Translation

CMMI

Capability Maturity Model Integration

CMS

Centers for Medicare & Medicaid Services

CDPP

Cloud-based Digital Portfolio Platform

ELG

Executive Leadership Group

MSG

Management Steering Group

PATs

Process Action Teams

PMP

Project Management Plan

SCAMPISM

Standard CMMI Appraisal Method for Process Improvement

SDMP

System Development Management Plan

SPI

Software Process Improvement

SPIP

Software Process Improvement Plan

SQA

Software Quality Assurance

SEPG

Software Engineering Specification

SRS

Software Requirements Specification

SDS

Software Design Specification

SPD

Software Process Definition

Table 1: Acronyms

Software Process Improvement Plan Version 1.0

11

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Glossary

Glossary
Term

Definition

Table 2: Glossary

Software Process Improvement Plan Version 1.0

12

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Referenced Documents

Referenced Documents
Document Name
ISO: Systems and
software engineering Software life cycle
processes

Document Number and/or URL

ISO/IEC 12207, IEEE Std 12207-2008,
Second edition

Issuance Date
2008-02-01

https://times.taylors.edu.my/pluginfile.p
hp?file=%2F1684863%2Fmod_resourc
e%2Fcontent%2F1%2FISO%2012207.
pdf

Table 3: Referenced Documents

Software Process Improvement Plan Version 1.0

13

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Record of Changes

Record of Changes

Version
Numbe
r

Date

Author/Owner

Description of Change

Table 4: Record of Changes

Software Process Improvement Plan Version 1.0

14

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

Approvals

Approvals
The undersigned acknowledge that they have reviewed the Software Process Improvement
Plan and agree with the information presented within this document. Changes to this Software
Process Improvement Plan will be coordinated with, and approved by, the undersigned, or their
designated representatives.
Signature:

Date:

Print Name:
Title:
Role:

Submitting Organizations Approving Authority

Signature:

Date:

Print Name:
Title:
Role:

CMS Approving Authority

Signature:

Date:

Print Name:
Title:
Role:

CMS Business Owner

Software Process Improvement Plan Version 1.0

15

Cloud-based Digital Portfolio Platform / CDPP

Protech CLC

References

References
Bandeali, A., Sharif, A., & Raza, A. (2009). Software Process Improvement CMMI and
IDEAL.Slideshare.net. Retrieved 14 April 2015, from
http://www.slideshare.net/aminbandeali/software-process-improvement-cmmi-and-ideal
Layman, B. (2005). Implementing an Organizational Software Process Improvement
Program (1st ed.). IEEE. Retrieved from
http://www.compaid.com/caiinternet/ezine/layman-organize.pdf
Linders, B. (2015). Process Improvement, The Agile Way!. Methods & Tools, (Winter
2010). Retrieved from http://www.methodsandtools.com/archive/archive.php?id=115
McFeeley, B. (1996). IDEALSM: A Users Guide for Software Process Improvement (1st
ed.). Pittsburgh, Pennsylvania: Carnegie Mellon University. Retrieved from
https://resources.sei.cmu.edu/asset_files/handbook/1996_002_001_16433.pdf
Sayer, N., & Williams, B. (2012). Lean for dummies, 2nd edition. Indianapolis, Ind.: John
Wiley & Sons.
Ul Haq, I. (2012). Software Process Improvement. Slideshare.net. Retrieved 14 April
2015, from http://www.slideshare.net/bilalhashmishah/software-process-improvement12777417
Wheeler, K. (2003). Lean Recruiting: Applying the Principles of Lean Manufacturing to
Recruiting.Ere.net. Retrieved 16 April 2015, from http://www.ere.net/2003/10/22/leanrecruiting-applying-the-principles-of-lean-manufacturing-to-recruiting/
Wikipedia,. (2015). Lean software development. Retrieved 14 April 2015, from
http://en.wikipedia.org/wiki/Lean_software_development

Software Process Improvement Plan Version 1.0

16

Cloud-based Digital Portfolio Platform / CDPP