This document summarizes the homework report for a software process improvement project. It discusses using the CMMI and IDEAL models to improve a company's software development process from CMMI maturity level 1 to level 2. The document outlines the current immature ad hoc process and the desired managed process at level 2. It then describes using the five phases of the IDEAL model (Initiating, Diagnosing, Establishing, Acting, and Learning) to guide the process improvement effort. The focus areas are determined to be project planning and project monitoring/control, and plans are described to establish new processes, obtain commitment, and monitor/control projects going forward.

1. Homework Report # 1
Software Process Improvement – CMMI and IDEAL
Arash Sharif, Muhammad Amin Bandeali, Ali Raza,
Fullerton, CA 92834
Muhammad Amin Bandeali (899800544)
Arash Sharif (899568125)
Ali Raza (805253283)
CPSC 544 Software Process Definition,
Prof. Chang-Hyun Jo, 10/08/07
1

3. Revision History
Date Version Description Author
September 3, 2007 0.01 Discussed Outline Arash Sharif
Ali Raza
Muhammad Amin
Bandeali
September 4, 2007 0.05 Created Outline Muhammad Amin
Bandeali
September 7, 2007 0.1 Wrote Executive Arash Sharif
Summary
September 13, 2007 0.2 Wrote Initial Phase Ali Raza
September 18, 2007 0.3 Wrote Diagnostics Muhammad Amin
Phase Bandeali
September 21, 2007 0.4 Wrote Establishing Arash Sharif
Phase
September 21, 2007 0.5 Wrote Acting Phase Ali Raza
September 22, 2007 0.6 Update to Executive Arash Sharif
Summary
September 22, 2007 0.7 Wrote Learning Muhammad Amin
Phase Bandeali
September 23, 2007 0.8 Updated Initial Ali Raza
Phase
September 25, 2007 0.9 Reviewed Initial Arash Sharif
Document
Ali Raza
Muhammad Amin
Bandeali
September 25, 2007 1.0 Finished Appendix Muhammad Amin
Bandeali
October 1, 2007 1.1 Fixed Grammatical Ali Raza
Errors in Action
Phase
October 3, 2007 1.2 Review Second Arash Sharif
Iteration
Ali Raza
Muhammad Amin
Bandeali
1

4. October 3, 2007 1.3 Updated Executive Arash Sharif
Summary
Ali Raza
Muhammad Amin
Bandeali
October 3, 2007 1.4 Updated Arash Sharif
Establishment Phase
Ali Raza
Muhammad Amin
Bandeali
October 6 2007 1.5 Review Third Arash Sharif
Iteration
Ali Raza
Muhammad Amin
Bandeali
October 7, 2007 1.6 Final Revisions Arash Sharif
Ali Raza
Muhammad Amin
Bandeali
2

5. Table of Contents
Revision History..................................................................................................................1
Executive Summary.............................................................................................................3
Purpose.............................................................................................................................3
Scope................................................................................................................................3
Background......................................................................................................................3
Goal..................................................................................................................................3
Problems..............................................................................................................................3
Approach..............................................................................................................................4
CMMI..............................................................................................................................4
Maturity Level 1..........................................................................................................4
Maturity Level 2..........................................................................................................4
IDEAL Model..................................................................................................................4
IDEAL Model......................................................................................................................5
The Initiating Phase.........................................................................................................5
Stimulus for Change....................................................................................................5
Set Context...................................................................................................................5
Build Sponsorship........................................................................................................5
Charter Infrastructure...................................................................................................5
Diagnosing Phase.............................................................................................................5
Characterize Current Phase..........................................................................................5
Characterize Desired State...........................................................................................6
Specific Practices by Goal...........................................................................................7
1

6. Generic Practices by Goal............................................................................................8
Develop Recommendations.........................................................................................8
The Establishing Phase....................................................................................................9
Set Priorities.................................................................................................................9
Develop Approach.......................................................................................................9
Plan Actions...............................................................................................................10
The Acting Phase...........................................................................................................10
Create Solution...........................................................................................................10
Pilot / Test Solution...................................................................................................11
Refine Solution..........................................................................................................12
Implement Solution....................................................................................................12
The Learning Phase........................................................................................................12
Analyze and Validate.................................................................................................12
Propose Future Actions..............................................................................................13
Appendices...........................................................................................................................1
Appendix A (Document)..................................................................................................1
Meeting Mission: .......................................................................................................1
Agenda:........................................................................................................................1
Appendix B (Chart)..........................................................................................................5
Appendix C (References).................................................................................................6
2

7. Executive Summary
Purpose
The purpose of this document is to record the steps taken to improve the RIA
Development Department of E Electronics from a CMMI Maturity level 1 to CMMI
Maturity level 2. The IDEAL Model will be used as a guideline to achieve this goal.
Scope
This document will follow the implementation of process improvement using the Staged
Representation from CMMI Level 1 to Level 2 on a test project called Pole Vault
Configuration System (PVC).
Background
E Electronics is an A/V Engineering/Manufacturing company. The Rich Internet
Application (RIA) Development Department works closely with the hardware engineers
and marketing to develop software that allows resellers and potential clients to customize
the products they buy.
PVC is an application that allows users to configure a custom set of products to fit the
needs of a particular install. The project was originally developed about 6 years ago, and
throughout time, it has slowly become bloated and harder to manage. Senior
management realizes that at one point they will need to scrap and rebuild it, but they have
determined that it will be too expensive for the time being. They, however, do realize
that the process of modifying this software often ends up with inaccurate estimates and
unexpected behavior.
Goal
The goal of process improvement is not only to insure better estimates and fewer bugs
while working on the PVC system, but to also develop a process foundation for all RIA
projects.
Problems
We hope to solve the following problems by raising our maturity level to level 2.
Have formal requirement documentation for projects as a point of reference for
management instead of emails and notes scribbled on notepads [Chrissis et. al., 53]
Have a well defined planning process to set meaningful milestones, and control output,
even during times of stress. [Chrissis et. al., 53] This should help limit bugs, limit the
time it takes to find bugs and not drift from design.
3

8. Have a way of managing, tracking, and controlling changes in a controlled manner
instead of just checking out files and patching in changes. [Humphrey, 7]
Approach
CMMI
The CMMI staged representation will be used as a model to improve our process and
help us meet our goals. We will be using the models process areas [Chrissis et. al.,63] to
show that the RIA Development Department is currently operating at a Maturity Level
1(Initial) and also develop a plan on how to achieve Maturity Level 2(Managed). Also,
the Revolutionary approach will be used to implement these changes.
Maturity Level 1
Processes are ad hoc and chaotic. Requirements and are not managed. The success of
projects depends on the competence and heroics of people and not a proven process. The
few documentations and processes in place are abandoned in the time of crisis. Projects
often exceed their budgets and do not meet their schedules. [Chrissis et. al., 63]
Maturity Level 2
Requirements are managed. The processes are planned documented, executed,
monitored, and controlled. Projects are planned and executed according to plan.
Stakeholders are well aware of milestones, and those milestones are revisited as needed.
The processes hold even under crises. [Chrissis et. al., 63]
IDEAL Model
The IDEAL Model will be used as the approach for this improvement process. The steps
of the IDEAL Model are outlined below.
• Initiating: Laying the groundwork for a successful improvement effort.
• Diagnosing: Determining where you are relative to where you want to be.
• Establishing: Planning the specifics of how you will reach your destination.
• Acting: Doing the work according to the plan.
• Learning: Learning from experience and improving your ability to adopt new
technologies in the future.
4

9. IDEAL Model
The Initiating Phase
Stimulus for Change
The PVC system has become bloated with each new update and as a result of poor
change control and management it has become unpredictable and unstable. This, in turn
will affect the end users, namely the dealers and the customers.
Set Context
By moving to CMMI Level 2, PVC system will become more predictable, stable and as a
result will increase the company’s productivity. The following business goals should be
achieved:
• New business requirements will be implemented and tracked as per business
stakeholders (Product Marketing Manger)
• To meet predicted deadlines
• Bugs will be found and resolved in an organized fashion
• Introducing a version control system
• Higher quality releases
Build Sponsorship
In order to establish the goals and expectations we went to the VP and explained to him
the current chaotic state and how to achieve a stable state. He agreed to commit the
resources necessary.
Charter Infrastructure
Four senior resources have been assigned fulltime duties to analyze the current maturity
level and how to achieve the next maturity level. This group was given access to the
hardware and software they deemed necessary.
Diagnosing Phase
Characterize Current Phase
A product manager, who is in charge of the engineering of the product, and a product
marketing manager, who is in charge of selling that product, sit down and brainstorm
how a software system would help dealers sell the product. When they loosely define
what they want to do they tell the appropriate software manager. That manager will then
determine who has the skill set and the time to develop the system. This developer will
then attend a series of meetings along with the other stakeholders to figure out what the
5

10. software system they want is suppose to do. The developer then goes back and starts
coding. There is no formal documentation, just a series of emails and notes on the
developer’s desk. Weekly or bi-weekly meetings are held to see if the stakeholders like
what they see and/or if they want to change anything until they determine the system is
ready to be made live.
Once the system is live, there are constant changes that stream down from the
stakeholders. Sometimes there are meetings and other times there are just email threads
that the developer has to sort through. The developer then makes the changes and once
the changes are approved the changes are moved to live. This process repeats until the
system is abandoned.
Clearly there is a lack of project management, senior management oversight, formal QA
process, and change management control. This chaotic process obviously resembles a
Maturity Level 1.
Characterize Desired State
To reach staged representation CMMI level 2 we need to emphasize on the following
Process Areas (PA)
Engineering
Requirement Management (RM)
1. Managing all the changes to the requirement [Chrissis et. al.,83]
2. Maintaining all the relationships among the requirements, the project plans and
the work products [Chrissis et. al.,83]
3. Identifying inconsistencies among the requirements, the project plans, and the
work products [Chrissis et. al., 83].
Project Management
Project Planning (PP)
1. Defining the product and project (what to build)
2. Requirement gathering
3. Identify the resources and cost analysis
4. Scheduling and Estimation
5. Deployment plan
Project Monitoring and Control (PMC)
1. Monitor the progress against the identified PP
2. Monitor the cost against the baseline PP
3. Adjusting the PP if necessary
6

11. 4. Monitoring the development effort and the deployment releases
5. Ensure accuracy of documentations
Supplier Agreement Management (SAM)
Formalized the project needs. This does not apply in this project because it is handled by
the infrastructure team.
Support
Measurement and Analysis (MA)
To measure the over all output which includes project performance, requirement
gathering process, and development process by carrying out Quality Assurance
Configuration Management (CM)
1. Control the changes of code, infrastructure, configuration and releases
2. Maintain the product baseline and provide the status to developers, managers and
customers
Process and Product Quality Assurance (PPQA)
1. Evaluate processes, workflows and artifacts against established standards
2. Provide feedback to managers on QA activities
3. Address all non-compliance issues
Specific Practices by Goal
Engineering
Requirement Management (RM)
Completely understanding, managing and committing to requirements has been identified
as an area of concern (SG1).
Project Management
Project Planning (PP)
Establish project, work and task estimates. Define a project life cycle (SG1). Layout a
plan for involvement of project resources and stakeholders (SG2). To get a commitment
from parties involved (SG3).
Project Monitoring and Control (PMC)
7

12. Monitor plan, commitments, risks, data management and stakeholder involvement.
Conduct progress and milestone reviews (SG1). Analyze issues, take and manage
corrective actions (SG2).
Supplier Agreement Management (SAM)
Not Applicable
Support
Measurement and Analysis (MA)
Measurement objectives. Specify measures, data collection, storage procedures and their
analysis (SG1). Collect and measure data. Store Data and communicate the results (SG2).
Configuration Management (CM)
Identify items to be configured, establish configuration system and release baselines
(SG1). Track change requests and control configuration items (SG2). Establish
configuration management records and perform audits (SG3).
Process and Product Quality Assurance (PPQA)
Evaluate processes and work products objectively (SG1). Communicate resolution of
noncompliance issues and establish records (SG2).
Generic Practices by Goal
In order to achieve level 2, all practices must be followed but the implementation team
believes that the following generic goals are very vital to fulfill:
• Establish an Organizational Policy (GP2.1)
• Assign Responsibility (GP2.4)
• Train People (GP2.5)
• Identify and Involve Relevant Stakeholders (GP2.7)
• Review Status with Higher Level Management (GP2.10)
Develop Recommendations
The implementation team determined that Project Monitoring and Control and Project
Planning were the process areas that needed the most attention in this iteration.
8

13. The Establishing Phase
Set Priorities
Senior management has determined that the budget will not allow us unlimited resources,
and therefore we have to limit the process areas that we will be concentrating on. After
analyzing the company’s problems we have chosen to concentrate on two process areas.
Namely, Project Planning (PP) and Project Monitoring and Control (PMC).
Project Planning
Establishing Estimates (SG1), including Estimating the Scope of the Project, Establishing
Estimates of Work Product and Task Attributes, Defining Project Lifecycle, Determining
Estimates of Effort and Cost (SP 1.1-1.3)
Develop a Project Plan, including Establishing the Budget and schedule, Identifying
Project Risks, Planning for Data Management, Planning for Needed Knowledge and
Skills, Planning Stakeholder involvement and establishing the Project Plan. (SP 2.1-2.7)
Obtaining Commitment to the Plan (SG3), including Reviewing plans that Affect the
Project, Reconciling Work and Resource Levels and Obtaining Plan Commitment. (SP
3.1-3.3)
Project Monitoring and Control
Monitoring Project Against Plan (SG1), including Monitoring Project Planning
Parameters, Monitoring Commitments, Monitoring Project Risks, Monitoring Data
Management, Monitoring Stakeholder Involvement, Conducting Progress Reviews and
Conducting Milestone Reviews. (SP 1.1-1.7)
Managing Corrective Action to Closure (SG2), including Analyzing Issues, Taking
Corrective Action and Managing Corrective Action (SP 2.1-2.3)
Develop Approach
This was perhaps one of the hardest areas for us to formalize. The Company has been in
business for 25 years and there are staff members, including developers who have been
with the company for many of those years. Many of the developers did not have formal
computer science degrees and their skill sets were lacking in vital areas, such as Object
oriented programming concepts. In addition many were set in their ways and did not
believe that a change was necessary.
Under these circumstances, we believed, it would be very hard to use an evolutionary
type of approach. Nothing would ever get decided on. We decided to go with a
revolutionary type of approach. A team of four qualified resources was assembled to
build the process documentation, present it to senior management and once approved,
9

14. reveal it to everyone else. This would of course, involve the proper training of everyone
involved.
Plan Actions
The following outlines the plan actions:
Deciding how to Establish Estimates and documenting it.
Since up until now estimating the time it would take to complete a project was solely an
educated guess by a developer which was often strongly influenced by ego, it was
deemed as the first step necessary.
Deciding on how to develop a Project Plan and documenting it
This is perhaps the most important since developers are often swapped out from project
to project. There has to be budgets allocated, documentation completed, and milestones
laid out. It cannot all just be in the original developers head. We need documentation on
how this is to be accomplished.
Deciding on how to Obtain Commitment to the Plan and documenting it
We need to gather appropriate documentation on how get commitment from all parties
involved to stick with a plan.
Deciding on How to Monitor Project against Plan and documenting it
A project plan that is committed on, but not followed is meaningless. We need to know
how to monitor a project plan.
Managing Corrective Action to Closure
We need to know what to do if there are problems following the project plan, a how to
track these action items.
The Acting Phase
Create Solution
Project Monitoring and Control
PVC System was measured against the project plan which includes time line, cost and
resources (SG1 + SP1.1-1), for this purpose bi weekly status meeting was established
with senior management and project managers. Weekly status meeting between the
developer who was assigned the modeled design and project manager was arranged for
10

15. monitoring commencements (SG1 + SP1.2-1). Current milestone were discussed in
enterprise project meetings and risk were communicated to stake holders (SG1 +
SP1.3-1). The data management plan was monitored in project status meeting (SG1 +
SP1.4-1). Stakeholders were updated by monthly project status meeting (SG1 +
SP1.5-1), during this progress reviews were conducted (SG1 + SP1.6-1), and reviews of
major milestones and accomplishment (SG1 + SP1.7-1) were also achieved. During
those activities there was QA recourse issues that were identified which was analyzed
and resolved (SG2 + SP 2.1 -1). For QA resources issue a new QA person was hired
(SG2 + SP2.2 -1). During the analysis phase requirement took 40 hours longer than
expected, therefore, the project plan was adjusted accordingly (SP2.3-1).
Project Planning
The high level scope of the project was estimated (SG1 + SP1.1-1) during the initial
stakeholders JAD session. After that a discussion was arranged with senior software
engineers in which key functions, architecture, high level domain class design and
database were discussed, these were identified in 2 separate sessions (SG1 + SP1.1-2).
Different phases were identified to achieve the entire stakeholders’ requirement (SG1 +
SP1.3.-1). On the bases of these phases cost, development efforts and QA efforts was
estimated (SG1 + SP1.4-1).
For PVC system budget was allocated by the President of the company and timelines
were established as per stakeholder needs (SG2 + SP2.1-1). Since PVC System was
implementing version control for the first time major risks were identified during senior
software engineer and release group meetings (SG2 + SP2.2-1). Security requirement to
connect to version control software was elaborated in initial project meeting (SG2 +
SP2.3-1). To implement PVC system new contracting company was considered for
implementing Rational Clear case and Rational Clear quest (SG2 + SP2.4-1). For
existing developers, training was planned (SG2 + SP 2.5-1). Monthly review for the
PVC project was conducted with stakeholders and senior management (SG2 + SP 2.6-1).
A project plan was written by using Visio which represented timeline, resources and
milestones (SG2 + SP2.7-1). A meeting was arranged with project manager, resource
manager, infrastructure manager and architect, in which the project plan was reviewed
(SG3 + SP 3.1-1). The finished date for PVC project was taking longer than expected in
project plan therefore a meeting was conducted with stakeholders (SG3 + SP3.2-1).
Pilot / Test Solution
To implement Project Monitoring and Control a document and a Gantt chart was
prepared and series of weekly meetings were setup with program manager, senior
software engineer, senior system analyst and the development manager. In that document
PVC system was broken-down into further sub systems (phases), risks, open issues and
tasks status. The Sample of that document is in Appendix A and the chart is in Appendix
B.
11

16. To implement the Project Management, PVC System phase 1 was scheduled and outlined
in which resources were identified. Those resources were as follows
• 1 Solution Architect.
• 2 J2EE Developers.
• 1 Database Programmer for stored procedure and database.
• 1 QA tester.
• Rollout date for QA, UAT (User Acceptant test) and production deadline were
established.
Refine Solution
For refining the solution, it was decided that Microsoft Project shall be implemented for
phase 2 of the PVC System. This is because it is easy to use especially in terms of
resources scheduling, predictions and automations.
Also for more PVC project monitoring an agile type of meeting should be scheduled
among lead architect, developers and the project managers so that everyone will be on
same page during the construction phase of the PVC system phase 2 and so on.
Implement Solution
After the implementation of two new software processes the PVC system phase 1
executed, which went smoothly. The project was launched under the budget, with more
predictability. Later it was decided by senior management that these techniques should be
applied in company wide projects.
The Learning Phase
Analyze and Validate
By moving from CCMI level 1 to level 2, the process improvement team acquired full
support and commitment from the company’s top managers for the PVC system. Process
improvement required extra efforts from the senior management, stakeholders, users and
suppliers and communication between them proved to be very crucial. Moreover, the
process improvement activities had to be arranged and run like an internal company
project.
Mangers, Project Mangers, Senior Developers and Testers had to be assembled in well-
defined teams and to revolutionize the processes due to strong resistance to change
throughout the whole project team.
12

17. Propose Future Actions
One thing that was overlooked was the moral of everyone involved. It takes a
tremendous amount of effort from everyone involved and most people don’t want to be
responsible for what they perceive as more work for the same pay, specially, if the
revolutionary approach was used. Perhaps, a bonus plan or the like could be
incorporated for process milestones.
To reach the Staged Maturity Level 3 we will again need to focus one several process
areas. We have determined that the most important ones we should focus on are
Integrated Project Management (IMP), Verification (VER), and Validation (VAL).
13

19. Appendices
Appendix A (Document)
Meeting Mission:
Provide project status to program leadership by facilitating communication between the
project managers, sharing of critical project information and the surfacing of barriers to
the success of the Program / Projects.
Agenda:
Item Categories:
• A – action
• D – decision
• R - action rolled over
• C – complete
• N - note
Project Name: PVC System
Meeting Date: Time:
Facilitator: Recorder:
Topic A/C/D Time Start Responsible
Frame Time
S.No. N/R*
Agenda Review
Action Item Review
Open Issue Review
Open Risk Review (minimum monthly)
Program Manager Update
Project Status Updates:
PVC Phase 1
PVC Phase 2
PVC Phase 3
Roundtable
Meeting Suggestions & Feedback
Meeting Wrap-up
1

20. Annotated Agenda & Minutes:
Topic 1. Agenda Review <time> <facilitator>
Topic 2. Action Item Review <time> <facilitator>
Topic 3. Open Issue Review <time> <facilitator>
Purpose:
Expectation:
Discussion:
Topic 4. Open Risk Review <time> <facilitator>
Purpose:
Expectation:
Discussion:
Topic 5. Program Manager Update <Time> <Facilitator>
Purpose:
Expectation:
Discussion:
Topic 6. Project Status Updates <Time> <Facilitator>
Purpose:
Expectation:
Discussion:
Topic 7. Phase 1 …Phase 4 <Time> <Facilitator>
Purpose:
Expectation:
Discussion:
2

21. Topic 12. Roundtable <time> All
Purpose: Each team member provides an update of relevant information.
Expectation: Team members share information.
Other topics of concern are identified and scheduled for future detailed
discussion.
<participant name>
<participant 2 name>
Topic 13. Meeting Suggestions & Feedback <time> <facilitator>
Purpose:
Expectation:
Discussion:
Topic 14. Meeting Wrap-Up <time> <facilitator>
Expectation: Review action items created during this meeting.
Set future meeting agendas.
Set future meeting schedule.
Future Meeting Schedule
Date Time Location Facilitator/Scribe
Future Agenda Item(s)
Agenda Item Planned Priority Time Responsible
Date(s)
3

22. Action Items
Open Action Items
AI Create Action Item Assigned Target Date
Date
Nb
r
Closed Action Items
AI Create Action Item Assigned Target Date
Date
Nb
r
Issues/Decision Log
Nb Open Issue Description Assigned Target Date
r Date
4

23. Appendix B (Chart)
5

24. Appendix C (References)
Mary Beth Chrissis, Mike Konrad, Sandy Shrum (2003), “CMMI Guidelines for Process
Integration and Product Improvement”, Addison-Wesley
Watts S. Humphrey (1989), “Managing the Software Process”, Addison-Wesley
Bob McFeeley (1996), “IDEALSM: A User’s Guide for Software Process Improvement”,
SEI
Mark C. Paulk, “Using the Software CMMÒ in Small Organizations”, SEI
6