Lightweight Software Process (sProcess) for Software Organizations
Group Members:
Muhammad Jahanzeb 18L-2047
Muhammad Shakeel Hussain 19L-2045
Muhammad Irfan 21L-7435
25th January 2022
Final Submission
National University of Computer & Emerging Sciences
NUCES (FAST) Lahore, Pakistan.
1. Literature Review
Maturity models have their beginnings in the software sector, and they have grown into an essential
tool for improvement in organizations looking to access process capabilities. However, a variety
of maturity models, such as the Capability Maturity Model, may be used to business process
management. It is critical for every business to have maturity models in place so that it can analyze
its process maturity and make adjustments. Furthermore, several authors believe there is a definite
need for an adaptive and ready-to-use process maturity tool.
1.1.CMM
Capability Maturity (CMM) model was developed by The Software Engineering Institute (SEI) at
Carnegie Mellon University in 1987, with funding from the US Department of Defense (DoD). It
was created to satisfy the requirements and features of government agencies. "A reference
[process] model of mature practices in a given discipline, intended to develop and assess a group's
competency to perform that discipline". According to SEI, CMM is based on Philip Crosby's
maturity model (1979), although it was improved in 1991 utilizing prior maturity models
developed by Deming (1986), Juran (1988), and Humphrey (1989). (1989). CMM contains five
levels of maturity and serves as an effective guide for an organization to manage all of its process
for improvement:





Optimizing (Continual process improvement)
Managed (Product and process quality)
Defined (Engineering Processes and Organizational Support)
Repeatable (Project Management Processes)
Initial (Process is informal and Adhoc)
This model is based on the idea that an organization may only reach a certain maturity level after
completing a series of processes. Capability Maturity Models contain the basic features of effective
processes for one or more disciplines, and they are simplified representations of the reality.
Attaining goals, which are specified by key practices, sub practices, and examples, satisfies the
main process areas in the CMM. Maturity levels, important process areas, and goals are the CMM's
rating components. The CMM can be a useful tool to guide process improvement because it has
historically been a common-sense application of Total Quality Management (TQM) concepts to
software that was developed with broad review by the software community. Its five stages are
simple, but when utilized wisely, they may be used to move people like the US Department of
Defense DOD programed manager, who frankly declared, "The bottom line is timetable." My
promotions and raises are determined first and foremost by my ability to achieve my deadlines.
1.2.PSP
A further significant step in software quality improvement was taken with the Personal Software
Process (PSP). The PSP extends the process of improvement to the individuals who do the work
practicing engineers. The PSP is focused on the individual engineers' work methods. The PSP is
based on the premise that in order to build high-quality software systems, each engineer who works
on the system must do so. The PSP is intended to assist software engineers in regularly employing
solid engineering principles. It teaches them how to plan and track their work, how to use a defined
and measured process, how to set measurable goals, and how to assess their progress toward those
goals. There are six PSP processes, also called PSP levels: PSP0, PSP0.1, PSP1, PSP1.1, PSP2,
and PSP2.1. Each process builds on the prior process by adding engineering or management
activities.
1.3.TSP
Watts Humphrey created the first iteration of the TSP technique in 1996. His goal was to create a
system that would allow engineers to regularly produce high-quality work. He made the TSP0
procedure as easy as possible, tested it with two teams, and then analyzed the outcomes to
determine how well it performed. He then identified areas where the teams required further advice
and improved the mechanism for providing it. The initial TSP0 procedure was created for PSPtrained teams that got no further training or direction than what the TSP process and the team's
immediate management supplied. Humphrey created nine additional TSP variants during the next
three years. His first goal was to determine if a general-purpose team method might assist
engineering teams in their job. His TSP process development efforts were oriented at simplifying
the process, lowering its size, and giving the assistance and advice needed to make the process
most efficient and effective after it was obvious that it accomplished this fundamental purpose. As
a result, newer TSP versions are significantly smaller than TSP0.1 and TSP0.2, which were
produced in late 1996 and early 1997.The TSP provides a clear operational approach for engineers
and managers to follow as they go through the team-building process.
1.4.CMMI for Development
CMMI for Development is a reference model that covers activities for developing both products
and services. Organizations from many industries, including aerospace, banking, computer
hardware, software, defense, automobile manufacturing, and telecommunications, use CMMI for
Development. CMMI for Development contains practices that cover project management, process
management, systems engineering, hardware engineering, software engineering, and other
supporting processes used in development and maintenance. Use professional judgment and
common sense to interpret the model for your organization. That is, although the process areas
described in this model depict behaviors considered best practices for most users, process areas
and practices should be interpreted using an in-depth knowledge of CMMI-DEV, your
organizational constraints, and your business environment.
2. Company Name:
2B Vision Technologies.
2.1.Company Profile:
2B Vision is a leading application software development and outsourcing company, provide the
highest quality Information Systems Consulting Services, Innovative Software Development,
Web Development, Designing and Mobile Application development. 2BVision believes in
customer satisfaction, with every effort being made to deliver a service that exceeds client
expectations by providing best Quality in time Delivery and Cost effective. 2BVision
Technologies have been established in 2008.
2.2.Intended Audience:
Internal Organization of 9 team members of Web application development section of IT
department.
3. Need of Lightweight Software process
A large number of software development projects are small-size and based on small team.
Provided that well-known software development models have shown limited applicability in such
scenario, developers usually carry out ad-hoc software processes. Similarly, the reactionary
development scenario and the lack of clear guidelines to face the process, push developers to
follow an ad-hoc development process. Besides, each development is influenced by variables like
type of project, client and development team. The heavyweight software processes have many
constraints to be applied in small organizations such as low budget, cultural and languages issues
etc. Lightweight software process proposes a detailed process which structures the development
activities and it improves the process visibility for team members. With the help of this small
teams can be able to improve their capabilities and team productivity.
3.1.Lightweight Software Process Architecture
In this process architecture we have used the CMM level 2, PSP, TSP including CCMI for
development techniques also.
3.2.Lightweight Software Process template defined:
3.2.1. Initiate:
 Requirements Management:
Requirements management is the process of ensuring that your organization
validates and meets the needs of its customers and external and internal
stakeholders. Those needs are typically referred to as requirements.
Requirements represent capabilities that will satisfy your product strategy.
 Project Planning:
A quality program can be built develop the requirements and to understand them.
The prototype of the product should be developed which defines the breakdown
of the product into units. The detailed design of and implementation strategy
should be developed when requirements become clear.

Self-Assessment:
Individual reviews are conducted to find areas that might be improved or exploited
to meet predetermined objectives. In other words, the individual examines himself
in order to have a better understanding of his strengths and potential.
3.2.2. Establish:
 Define Priority:
Tasks are items that can be checked off of a checklist. Task prioritization is
necessary to carry out your projects so that you can achieve your goals while
setting the priority of each of them.
 Project Commitments:
According to Watts S. Humphrey, the commitment should not make lightly of
work involved in project and overall schedule of the project. An agreement should
be considered between the parties that what is to be done and whom can done
including publically stated. The responsible person should tries to meet the
commitment. An advance noticed should be given to the party who does not meet
the commitment.
 Team Roles:
Goals are set, team responsibilities are defined, risks are assessed, effort is
estimated, tasks are assigned, and a team plan is created. Developers track planned
and actual effort, schedule, and defects during the execution phase, and they meet
often to report status and change plans.
 Senior Management support:
Senior management assistance should be at the top of every project manager's
priority list for IT project success. When we failed to acquire enough senior
management backing for our IT initiatives, they had a little chance of succeeding,
and in fact, they failed.
3.2.3. Implement:
 General Standards:
Clear definition of purpose and simplicity of use of the software. Efficiency and
reliability should be considered. Conform to standards, accurate and precise user
documentation.
 Design Reviews:
As a defect proceeds through the development process, the cost of repairing it
rises. Investing more time and effort in the early phases of development to find
and repair faults is likely to pay off. A good illustration of this is design reviews.
As a result, many design reviews may be conducted, for example, to evaluate the
design against distinct sets of criteria at different phases of the design process.
 Code Reviews:
Code review (also known as peer review) is a software quality assurance activity
in which one or more persons examine a program primarily by examining and
reading portions of its source code, either after it has been implemented or as a
break in the process. One of the individuals must not be the code's creator.
Tracking the progress of project.
 Incremental Improvements in development:
The development process can be efficient by reviewing the code of team members
which may lead to improve the quality of code by removing defects side by side.
 Modules Testing:
Module testing refers to the testing of the program's smaller components. Module
testing is mostly focused on white boxes. The goal of module testing is to
demonstrate the presence of a mistake in the module rather than to demonstrate
the module's proper functioning.
 Configuration Management:
To systematically manage, organize, and control the changes in the documents,
codes, and other entities during the Software Development Life Cycle. The
primary goal is to increase productivity with minimal mistakes. The main
objective is to enhance production while making as few mistakes as possible.
 Project Tracking and meetings:
The team will engage in regular weekly meetings and team member will be highly
encouraged to give feedback for improvement. A thorough analysis will be done
to analyze the completed phase, lesson learnt. Tasks not completed during a phase
will be recorded and scheduled for completion in future.
3.2.4. Improve:
 Software Process Assessment:
The software process assessment technique can be used to improve the operations
of software. This can be done by understanding the current process model, senior
management involvement and by taking the reviews of the people in organization.
An action plan should be developed to follow the improvement in software
process.


Project Cycle Report:
Detailed project must be generated to review the progress, status and issues faced
at every stage of the project.
Team Evaluations:
A report regarding strengths and weaknesses can be discussed among team
members by their line managers to improve their skills and focus towards the
creativity.
4. Lightweight Process Checklists
4.1.Initiate Phase:
Requirements Management Checklist:
Sr. No.
Details
1
Do you use system requirements to establish a baseline for software engineering
and management use?
2
Are the people who are responsible for managing the allocated requirements
trained in the procedures?
3
Do you use measurements to determine the status of activities performed for
managing the allocated requirements (e.g., total number of requirements changes
that are proposed, open, approved, and incorporated into the baseline)?
4
Do your organization prioritize system requirements in SRS according to
stakeholders need?
5
Are the specified system requirements including their dependencies like impact
on cost, schedule and the technical impact are analyzed?
6
Is the verification criteria for each system requirement for qualitative and
quantitative measures for the verification of a requirement developed?
7
Are the agreed system requirements and updates to system requirements to all
relevant parties communicated?
8
Do your activities for managing allocated requirements on the project subjected
to software quality assurance review?
Any Comments:
Project Planning Checklist:
Sr. No.
Details
1
Are estimation (e.g., size, cost, and schedule) documents used for planning and
tracking the software project?
2
Do the software plans document the activities to be performed and the
commitments made for the software project?
3
Are measurements used to determine the status of the activities for planning the
software project (e.g., completion of milestones for the project planning
activities as compared to the plan)?
4
Is the project planning schedule been defined with work break down structure
and tasks assigned?
5
Is the size of each product element is estimated.
6
Are the resources roles have been defined in project plan?
Any Comments:
Self-Assessment Checklist:
Sr. No.
Details
1
Are the best people available?
2
Do the people have the right combination of skills?
3
Are staff committed for entire duration of the project?
4
Have staff received necessary training?
5
Does the team members have enough knowledge of the software development
standards?
6
Does the technical experience of the team members are up to mark to develop
the quality product?
7
Are the team members well trained to review the code of each other to remove
the defects in early stages on software process?
Any Comments:
4.2.
Establish Phase:
Define Priorities Checklist:
Sr. No.
Details
1
2
Review objectives of your projects and be sure they are strategically aligned with
the overall portfolio.
Identify scheduled timeframes of the project.
3
Evaluate projects tasks against relevance to your commitments.
4
Be sure that every project listed in your inventory has an approved scope statement
that identifies project boundaries, requirements and deliverables.
Are the high priority or initial stages tasks are Cleary defined to the team
members?
5
6
Senior Management should verify the priority tasks has been fulfilled timely.
Any Comments:
Project Commitment Checklist:
Sr. No.
Details
1
2
Are the agreement between the two parties been done defining the work
breakdown structure?
Tasks assigned to person is responsible for the timely completion of them.
3
Evaluate projects tasks against relevance to your commitments.
4
Are the commitments of future software delivery made by senior management of
the organization?
Does the documented project plan is defined including the resource estimate, cost
and schedule estimate.
5
6
An independent review has been conducted by the senior management to make
sure that organization process and standards being followed.
7
Are all of the parties directly involved have agreed to this project plan in writing?
Any Comments:
Team Roles Checklist:
Sr. No.
Details
1
Team members are should be actively communicate between each other discuss
about the progress of the project.
Team members should focus on their goals to timely achieve them which may
improve the quality of product.
Team members should propose the new ideas during the development phase of
the project.
Team members should be knowledge sharing people among each other.
2
3
4
5
Team members are responsible of the tasks which have been defined in the
agreement.
6
Team members should follow the organization standards and follow the defined
software process by organization
7
Team members should have authentic and have positive attitude through all stages
of the project.
Any Comments:
Senior Management Support Checklist:
Sr. No.
Details
1
Does senior management understand their role in driving the IT project
success?
2
Did senior management initiate the project based on business
3
needs/goals?
Is senior management the owner of the project charter?
4
How much time was devoted to the approval process?
5
Are they willing to remain involved with the project and attend executive
update sessions?
6
Do they understand the risks and are willing to see the project through its
rough times?
7
How much support does top management have among its peers?
Any Comments:
4.3.
Implement Phase:
General Standards Checklist:
Sr. No.
Details
1
A unique product that can either be a component of another item, an
enhancement or correction to an item, or a new end item in itself.
2
Project has a definite beginning and end.
3
In business analysis, business value is considered the return, in the form of
elements such as time, money, goods or intangibles in return for something
exchanged.
4
Project Objectives must be SMART. Specific, Measurable, Attainable, Relevant
and Time Bound.
5
Requirements/Functional Specification Document (If PQA involvement required
and prioritized by Project Manager).
6
Test Cases – (If PQA involvement required and prioritized by Project Manager)
7
QC test execution and summary report
Any Comments:
Detailed Design Review Checklist:
Sr. No.
Details
1
Does your organization develop and document the system architectural design that
specify the elements of the system with respect to functional and non-functional
system requirement?
2
Does your organization identify, develop and document the interfaces of each
system element?
3
Is bidirectional traceability between system requirements and elements of the
system architectural design established?
4
Is consistency between system requirements and system architectural design by
review records ensured?
5
Does your organization identify, specify and document the interfaces of each
software units?
6
Is the software detailed design in terms of interoperability, interaction, criticality,
technical complexity, risks and testability evaluated?
7
Are the agreed software detailed design and updates to the software detailed
design to all relevant parties communicated?
8
Are the executable representations of each software unit according to the software
detailed design are developed and documented?
9
Are the agreed system architectural design and updates to system architectural
design to all relevant parties communicated?
Any Comments:
Code Review Checklist:
Sr. No.
Details
1
Is the code written following the coding standards/guidelines?
2
Can I unit test / debug the code easily to find the root cause?
3
Is this function or class too big? If yes, is the function or class having too many
responsibilities?
4
Is the code following the design principles?
5
Is the code followed the defined architecture?
6
Is the code Maintainability is easy?
7
As needed, makes non-functional adjustments. Makes a note of any functional
modifications that need to be done in order to follow the checklist.
8
No modifications to the actual body of code or its structure should be made before
a first pass review to avoid unintended changes in functionality.
9
Separate groups of definitions and declarations, each with a remark heading,
should be used.
10
Each modification to the unit should be listed, together with the date and the name
of the person who made the change. If the adjustment was made to fix a flaw,
make a note of the defect number or ID.
11
Do you have comments and explanations for difficult coding paragraphs that may
create misunderstanding and confusion?
Any Comments:
Incremental Improvements Checklist:
Sr. No.
Details
1
Are the coding practices reviewed before the deployment?
2
Changes should be tested in a non-live environment.
3
Make a list of possible solutions.
4
Make a clear distinction between the issue and the improvement.
5
Discuss about the challenges or any defect with Senior Management timely.
6
Changes should be monitored after the deployment.
Any Comments:
Modules Testing – QA Checklist:
Sr. No.
Details
1
A tiny code unit may be tested using the needed unit test cases to check that the
function, process, or subroutine is working properly.
2
Multiple modules from a single application can be tested in parallel without
interfering with each other.
3
Small chunks of the program should be tested to handle the complexity.
4
Each software module is initially tested, then incrementally increased until the
entire collection is tested using a step-by-step process.
5
In order to run a test for that module, we need to prepare the test data that will be
sent to it via a driver.
6
Test cases should be written throughout the requirement analysis and design
process to guarantee that all requirements are testable.
7
Before you start developing, make your test cases visible to developers. Allow
developers to extensively study your test cases in order to design a high-quality
application. This will also cut down on rework time.
8
When performing regression testing, a module-by-module bug graph might be
helpful in predicting the most likely problem area of the program.
9
Increase the amount of time you spend talking to developers to learn more about
the product. Face-to-face communication should be used wherever feasible to
resolve issues swiftly and avoid misconceptions.
10
Testing teams should share their best testing strategies and knowledge with other
departments inside their company.
Any Comments:
Software Configuration Management Checklist:
Sr. No.
Details
1
Make sure you have a version control system in place.
2
Using configuration management, ensure that the project has identified, managed,
and made available the software work products.
3
Prepare a list of the SCM process's needed tools, techniques, and procedures.
4
Version Control System model should be used by the management.
5
Are there regular audits to ensure that software baselines are compliant with the
documentation that specifies them?
6
The project, the software to be produced, and the life cycle phases are all included
in the scope of the SCM plan.
7
Are all modifications for impact evaluation/implementation routed through
Product Support, Manufacturing, Quality Control, and Product Management?
8
Are the executable representations of each software unit according to the software
detailed design are developed and documented?
9
Are the changes mentioned in CRFs are formally approved and reviewed by the
Senior Management.?
Any Comments:
Project Progress and Meetings Checklist:
Sr. No.
Details
1
Determine the topics to be discussed and draw up the Agenda
2
Determine the Project milestone and percent complete
3
Highlight any open change requests and next steps that need stakeholders
4
Acknowledge any new risks that have occurred since the last report, and present
the management plan(s) to deal with them.
5
Consistency in reporting will allow for easier and more accurate cross-report
comparisons.
6
How much headway has been made on individual tasks leading up to the
milestone?
Any Comments:
4.4.
Improvement Phase:
Software Process Assessment Checklist:
Sr. No.
Details
1
Management commitment is mandatory for the assessment of software process.
2
Four to six professional are taken from the every team for assessment activity.
3
Each assessment team member have 8 to 10 years of professional experience and
have a team player and have good respect in organization.
4
Assessment results must be taken as confidential
5
Senior management must define sufficient priority to the process assessment.
6
Proper questionnaire should be developed to assess the current status of
organization.
7
Are the series of meetings conducted between six to eight professional of technical
arrears?
8
Are the findings presentation is reviewed by the assessment and project
representative team?
Any Comments:
Project Cycle Report Checklist:
Sr. No.
Details
1
After project completion, progress of every stage must be discussed by the senior
management and among team members.
2
Lessons learnt should be discussed among the team members of the project.
3
Team members and senior management tasks evaluations and progress should be
discussed.
4
Project cost and schedule should be discussed after the completion of project with
senior management.
5
Smoke testing issues should be discussed and noted after the deployment.
6
Reusability of features should be discussed after the completion of project.
Any Comments:
Team Evaluations Checklist:
Sr. No.
Details
1
Does the team have clearly identified actionable steps to achieve its goals?
2
Does the team monitor its progress by concrete milestones?
3
Does the team regularly and frequently assess how well they are working
together?
4
Are the team’s successes (both big and small) acknowledged?
5
Is the team the right size, with the right mix of players for your purpose?
6
Does the team meet regularly?
7
Does the team stay motivated?
8
Does the team have effective ways of managing conflict?
9
Does the team have clearly identified actionable steps to achieve its goals?
Any Comments:
5. References:
[1] García-Mireles, G.A., Moraga, M.A. and García, F. (2012) “Development of Maturity Models: A
Systematic Literature Review”, Proceedings of the EASE 2012 - Published by the IET, ISBN 978-1-84919541-6.
[2] Van looy, A., De Backer, M., Poels, G. and Snoeck, M. (2013) “Choosing the right business process
maturity model”, Information and Management, Vol. 50, pp. 466-488.
[3] Humphrey, Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.
[4] Röglinger, M., Pöppelbuß, J. and Becker, J. (2012) "Maturity models in business process management",
Business Process Management Journal, Vol. 18 No. 2, pp.328 – 346
[5] Batista J. and Dias de Figueiredo A. “SPI in a Very Small Team: a Case with CMM”. Software Process
Improvement and Practice 2000; 5: 243-250.
[6] Marsha Pomeroy-Huff. The Personal Software Process SM (PSPSM) Body of Knowledge: A SPECIAL
REPORT (CMU/SEI-2003-TR-014, ADA418430). Pittsburgh, PA: Software Engineering Institute,
Carnegie Mellon University, 2003.
[7] Webb, David & Humphrey, Watts S. ―Using the TSP on the TaskView Project.‖ CrossTalk 12, 2
(February 1999): 3-10
[8] Ahern, Dennis M.; Clouse, Aaron; & Turner, Richard. CMMI Distilled: A Practical Introduction to
Integrated Process Improvement, 3 rd Edition. Boston: Addison-Wesley, 2008.
[9] Batista J. and Dias de Figueiredo A. “SPI in a Very Small Team: a Case with CMM”. Software Process
Improvement and Practice 2000; 5: 243-250
[10] Mokocho, P. M. O. K. (2001). “An overview of the quality, readability and relevance of Distance
Education Instructional Modules at Domasi College of Education (Malawi) – a teacher – learner’s
perspective”. Paper presented at the Pan-Commonwealth Forum on Open Learning, Durban, South Africa,
and 29th July – 2 August, 2002.
[11] Werth, L. H. “Preparing Students for Programming-in-the-Large,” 37- 41. Proc. 20th SIGCSE Tech.
Symp. Computer Science Education, Barrett, R. A., Mansfield, M. J., eds. New York: ACM, Feb. 1989
[12] Scholtes, P. The Team Handbook: How to Use Teams to Improve Quality. Madison, Wis.: Joiner
Associates, 1988.
[13] Humphrey, Watts S. Winning with Software: An Executive Strategy. Reading, MA: Addison-Wesley,
2002.
[14] Software and Information Industry Association and Symphony Services, "SIIA Global software
development survey report," Software and Information Industry Association., 2006.
[15] J.D. Herbsleb and D. Moitra, "Global software development," IEEE Software, vol. 18, pp. 16-20, 2001.
[16] J.A. Espinosa and E. Carmel, "The impact of time separation on coordination in global software teams:
a conceptual foundation," Software Process: Improvement and Practice, vol. 8, pp. 249-266, 2003.