EEI6360 Study Guide

Table of Contents
Unit 01: Process Concepts 3

Session 1: Software project management definition 3
Session 3: Software development process 7
Session 4: Measurement and analysis of software processes 10
Session 5: Software engineering process improvement (individual, team) 11
Unit 02: Management Concepts 15

Session 1: General project management 15
Session 2: Classic management models 16
Session 3: Project management roles 18
Session 4: Enterprise/Organizational management structure 28
Session 5: Software management types (acquisition, project, development,
maintenance, risk) 29
Unit 03: Project personnel and organization 31

Session 1: Organizational structures, positions, responsibilities, and authority 31
Session 2: Formal/informal communication 33
Session 3: Project staffing 35
Session 4: Personnel training, career development, and evaluation 36
Session 5: Meeting management 39
Session 6: Building and motivating teams 43
Session 7: Conflict resolution 53
Unit 04: Process implementation 59

Session 1: Levels of process definition (organization, project, team, individual) 59
Session 2: Life cycle models (agile, heavyweight, waterfall, spiral, V-Model) 61
Session 3: Life cycle process models and standards (IEEE, ISO) 64
Session 4: Individual software process (model, definition, measurement, analysis,
improvement) 66
Session 5: Team process (model, definition, organization, measurement, analysis,
improvement) 69
Session 6: Process tailoring 71
Unit 05: Project planning 73

Session 1: Evaluation and planning 73
Session 2: Work breakdown structure 75
Session 3: Effort estimation 78
Session 4: Resource allocation 80
Session 5: Task scheduling 81
Session 6: Risk management 84
Unit 6: Software configuration management 85

Session 1: Revision control 85
Session 2: Release management 88
Session 3: Tool support 90
Session 4: Builds 93
Session 5: Software configuration management processes 95
1
Unit 07: Project control 101
Session 1: Change control 101
Session 2: Monitoring and reporting 104
Session 3: Measurement and analysis of results 105
Session 4: Correction and recovery 107
Session 5: Standards of performance 111
2
UNIT 01: PROCESS CONCEPTS
Objectives of this unit are to discuss and understand the basic terminologies and
fundamental concepts of software project management.
Session 1: Software project management definition
Introduction to acronyms and definitions commonly used in Software Project

Management
1.1. Introduction
Software project management is a sub-discipline of project management in

which software projects are planned, monitored and controlled. It involves
understanding concepts and processes. The main function of process is to
make what is done predictable and repeatable from a management point of
view.
Definition of a project and project management.

o What is a Project? A project can be any of the following,
Developing a new product or service
Acquiring/Implementing a software product
Constructing a building or facility
Running a campaign for political office
Implementing a new business process
o PMI definition: A project is a temporary endeavor undertaken to

create a unique product or service. Temporary means that every
project has a definite beginning and a definite end. Unique means
that the product or service is different in some distinguished way
from all similar products or services.
o What is project management?

Project management is the application of knowledge,
skills, tools and techniques to project activities in order to
meet project requirements. (PMBOK)
o Project management involves,
Managing competing demands on scope, time, cost and
quality attributes.
3
Managing stakeholders with differing needs and
expectations.
Managing identified requirements.
1.2 Required Reading
What is a project - A Guide to the Project Management Body of Knowledge : P 5
What is a project – Software project management, 4th edition, Bob Hughes & Mike
Cotterell : P 2
Software projects versus other types of project - – Software project management,

4th edition, Bob Hughes & Mike Cotterell : P4
What is project management - A Guide to the Project Management Body of

Knowledge : P 8
1.3 SAQ
Exercise 1.1 : Software project management, 4th edition, Bob Hughes & Mike
Cotterell : P 2
1.4 References
A Guide to the Project Management Body of Knowledge
Software project management, 4th edition, Bob Hughes & Mike Cotterell
4
Session 2: Project management context
Introduction to project phases and project life cycle
2.1. Introduction
Project management exists in a broader context that includes program

management, portfolio management and project management office.
Frequently there is a hierarchy of strategic plan, portfolio, program, project
and sub projects in which a program consisting of several associated
projects will contribute to the achievement of a strategic plan. Described in
this section are key attributes in the project management context.
o Project management context broadly covers the following,

Project Phases
• Attributes
o Each phase is associated with one or
more deliverables.
o Division of a project into multiple phases
of execution.
o Conclusion of a phase is marked by
review of key deliverables and project
performance.
• The need for project phases
o Project is a unique undertaking
o Involves uncertainty
o To have a better management control
• End of phase activities
o Deliverables: Tangible, verifiable work
products
o Reviews: Evaluation of deliverables and
project performance.
o Phase exit criteria: Measurements used to
determine if project should go into next
phase.
Project life cycle
• Collection of project phases
• Serves to define the beginning and end of a
project
• Helps to define the process for a specific project
product
• Generally defines
5
o What technical work should be done at
each phase
o Who should be involved in each phase
• Characteristics
o Starts with the feasibility study after which
a decision to proceed will be made
o Cost and staffing levels are low at the
start, higher towards the end, and reduce
as project closes
o Probability of success is lowest at the
inception due to risk and uncertainty
o Impact to failure is highest towards the
ends as more resources are committed
o Stakeholder influence is highest at the
start of the project
o Cost of change/ error correction increases
over time
• Generic project lifecycle
o Concept
o Planning (development)
o Execution (Implementation)
o Finish (Closeout)
What is project management context - A Guide to the Project Management

Body of Knowledge : P 16
2.3 References
A Guide to the Project Management Body of Knowledge
6
Session 3: Software development process
Introduction to software engineering process infrastructure

Define modeling and specification of software processes
3.1. Introduction
A software development process is a structure imposed on the
development of a software product. Synonyms include software life cycle
and software process. There are several models for such processes, each
describing approaches to a variety of tasks or activities that take place
during the process.
Define Software engineering process infrastructure (e.g. personnel, tools,

training, etc.)
o Software Development process
development of a software product. There are several models
for such processes, each describing approaches to a variety of
tasks or activities that take place during the process. When
applied to software development process can increase the
quality of the software produced. The first requirement of
process is that it is documented. The process needs to be
sufficiently well defined and documented that it covers the vast
majority of the most important aspects of the work carried out
on the project. The second requirement of process is that it is
followed. This can only be achieved if it substantially fits the
way that people work currently, if those who have to work
within it are sufficiently motivated to do so and if sufficient
training is provided for aspects of the work that depart from the
current procedure. Achieving these things is helped a great
deal by making any given process easily customized and
introducing it gradually so as not to upset any current work in
progress. Conformance to the process should be monitored as
part of increment assessments and problem areas addressed
as the project progresses. A good process is:
• Available
• Comprehensive
• Easily Customizable
• Introduced Incrementally
• Followed
• Continuously Improved
7
Common roles is SW development
Define modeling and specification of software processes
o The modeling of the software process refers to the definition of the

processes as models, plus any optional automated support available for
modeling and for executing the models during the software process.
o Specific goals and benefits of modeling the software process are,
Ease of understanding and communication: requiring a process

model containing enough information for its representation. It
formalizes the process, thus providing a basis for training.
Process management support and control: requiring a project-
specific software process and monitoring, management and co-
ordination.
Provision for automated orientations for process performance:
requiring an effective software development environment,
providing user orientations, instructions and reference material.
Provision for automated execution support: requiring automated
process parts, co-operative work support, a compilation of
metrics and process integrity assurance.
Process improvement support: requiring the reuse of well-defined
and effective software processes, the comparison of alternative
processes and process development support.
o The software process basically consists of two interrelated processes: the

production process and the management process. The first is related to
the construction and maintenance of the software product, whereas the
second is responsible for estimating, planning and controlling the
necessary resources (people, time, technological, etc) to be able to carry
out and control the production process. This control makes it possible to
8
generate information about the production process, which can be used
later on by the management process with a view to improving the software
process and increasing the quality of the developed software.
o Basic process modeling components
Agent or Actor: is an entity that executes a process.

Role: describes a set of agent or group responsibilities, rights
and skills required to perform a specific software process activity
Activity: is the stage of a process that produces externally visible
changes of state in the software product. An activity can have an
input, an output and some intermediate results,
Artifact or Product: is the (sub) product and the “raw material” of
a process. An artifact produced by a process can be used later
as raw material for the same or another process to produce other
artifacts.

o Modeling approaches
Processes can be modeled at different levels of
abstraction (for example, generic models versus tailored
models) and they can also be modeled with different goals
(descriptive models versus prescriptive models).
3.2. Required Reading
Software development process:

http://en.wikipedia.org/wiki/Software_development_process
9
Session 4: Measurement and analysis of software
processes
Identify why software process need to be measured

What are the techniques used.
4.1. Introduction
Rationale behind measuring the software processes are driven by the need
to identify,
• How well are we meeting schedules and budgets?

• Has our performance really improved?
• What software practices and/or technologies should our organization invest
in and what yields can we expect from this investment?
• How does our organization's performance compare to other organizations'
performances?
4.2 References
http://www.martinig.ch/ae/process.php?id=7
10
Session 5: Software engineering process improvement
(individual, team)
Understand different techniques used for process improvement
5.1. Introduction
Process improvement is a series of actions taken to identify, analyze and

improve existing processes within an organization to meet new goals and
objectives. These actions often follow a specific methodology or strategy to
create successful results. A sampling of these are listed below.
Benchmarking
Business Process Improvement
Business process reengineering
Capability Maturity Model Integration/Capability Maturity
Model
Hoshin Kanri
5.1.1. Benchmarking
Is the process of comparing the cost, cycle time, productivity, or quality of a
specific process or method to another that is widely considered to be an
industry standard or best practice.
5.1.2. Business Process Improvement (BPI)

Is a systematic approach to help any organization optimize its underlying
processes to achieve more efficient results.
5.1.3. Business process reengineering (BPR)

An approach aiming at improvements by means of elevating efficiency and
effectiveness of the business process that exist within and across
organizations.
5.1.4. Capability Maturity Model Integration (CMMI)

Is a process improvement approach that provides organizations with the
essential elements for effective process improvement. It can be used to
guide process improvement across a project, a division, or an entire
organization. CMMI helps integrate traditionally separate organizational
functions, set process improvement goals and priorities, provide guidance
for quality processes, and provide a point of reference for appraising
current processes.
11
5.1.5. Hoshin kanri
Is a method devised to capture and cement strategic goals as well as
flashes of insight about the future and develop the means to bring these
into reality. Also called Policy Deployment or Hoshin Planning, it is a
Strategic planning/Strategic management methodology, developed by Dr.
Yoji Akao, that uses a Shewhart cycle (Plan-Do-Check-Act) to create
goals, choose control points (measurable milestones), and link daily control
activities to company strategy.
5.5. References
Process improvement:
http://en.wikipedia.org/wiki/Process_improvement
12
Session 6: Quality analysis and control (defect
prevention, review processes, quality metrics, root
cause analysis)
Purpose of Software review and review techniques

Measurement of software quality via metrics
6.1. Introduction
Quality analysis is defined as “Examination of the quality goals of a product

or service”.
6.1.1. Software review
A software review is "A process or meeting during which a software

product is [examined by] project personnel, managers, users, customers,
user representatives, or other interested parties for comment or approval".
6.1.2. Software quality
Measures how well software is designed (quality of design), and how well
the software conforms to that design (quality of conformance). Another
definition by Dr. Tom DeMarco says "a product's quality is a function of
how much it changes the world for the better.
6.1.3. Software metrics
Software metrics can be classified into three categories: product metrics,

process metrics, and project metrics. Product metrics describe the
characteristics of the product such as size, complexity, design features,
performance, and quality level. Process metrics can be used to improve
software development and maintenance. Examples include the
effectiveness of defect removal during development, the pattern of testing
defect arrival, and the response time of the fix process. Project metrics
describe the project characteristics and execution. Examples include the
number of software developers, the staffing pattern over the life cycle of
the software, cost, schedule, and productivity. Some metrics belong to
multiple categories. For example, the in-process quality metrics of a project
are both process metrics and project metrics.
13
6.1.4. Root cause analysis (RCA).
Is a class of problem solving methods aimed at identifying the root causes

of problems or events. The practice of RCA is predicated on the belief that
problems are best solved by attempting to correct or eliminate root causes,
as opposed to merely addressing the immediately obvious symptoms. By
directing corrective measures at root causes, it is hoped that the likelihood
of problem recurrence will be minimized. However, it is recognized that
complete prevention of recurrence by a single intervention is not always
possible. Thus, RCA is often considered to be an iterative process, and is
frequently viewed as a tool of continuous improvement.
Software quality – Software project management, 4th edition, Bob Hughes

& Mike Cotterell : P 258
6.3. References
Software review: http://en.wikipedia.org/wiki/Software_review
Software quality: http://en.wikipedia.org/wiki/Software_quality
Software quality metrics overview:

http://www.informit.com/articles/article.aspx?p=30306
http://en.wikipedia.org/wiki/Software_metric
Root cause analysis: http://en.wikipedia.org/wiki/Root_cause_analysis
14
UNIT 02: MANAGEMENT CONCEPTS
Objectives of this unit are to discuss and understand the basic constituents in
software project management, different models and roles, influence made by
organization structure and types of software projects.
Session 1: General project management
What does management involve?
1.1. Introduction
Management involves the following activities,
Planning – deciding what is to be done
Organizing – making arrangements
Staffing – selecting the right people for the right job
Directing – giving instructions
Monitoring – checking on the progress
Controlling – taking action to remedy the holdups
Innovating – coming up with new solutions
Representing – liaising with clients, users, developers. Suppliers,
and other stakeholders
What is management, 4th edition, Bob Hughes & Mike Cotterell : P 9 – 17

Project management - A Guide to the Project Management Body of
Knowledge : P 11
The difference between different types of projects.
http://www.maxwideman.com/guests/typology/abstract.htm
http://www.maxwideman.com/guests/typology/intro.htm
http://www.maxwideman.com/guests/typology/projects.htm
http://www.maxwideman.com/guests/typology/characteristics.htm
http://www.maxwideman.com/guests/typology/approach.htm
http://www.maxwideman.com/guests/typology/variables.htm
http://www.maxwideman.com/guests/typology/conclusions.htm
http://www.maxwideman.com/guests/typology/appendix.htm
15
1.3. SAQ
Software quality – Software project management, 4th edition, Bob Hughes & Mike
Cotterell : P 19 - 19
1.4. Conclusion
At the end of this session the student should have a high level understanding of
what project management involves and what are the different aspects in project
management.
Session 2: Classic management models
Introduction to the project life cycle

Six stage project management model
Waterfall process
Drawbacks with the classic software development model
2.1. Introduction
As each project is different, there are a number of ways of taking an overview of a

project. Two of these are:
the project life-cycle, which is a useful way of understanding the different
phases of a project as it progresses, and
the classic six-stage project management model, which helps us to identify
the key stages and to integrate them through the processes of the project.
Although all projects are different, any project can be considered to have a life-
cycle consisting of five phases. The phases are usually referred to collectively as
the life-cycle of a project because they provide an overview of the life of the project
from its beginning to its end.
2.1.1 The classic six-stage project management model
The classic six-stage project management model consists of stages, but, unlike the
sequential flow of the project life-cycle, the six-stage model assumes that some
stages are carried out simultaneously. In particular, the model assumes that
communications will take place throughout the project. It also assumes that team
building, leading and motivation will take place once the project has been defined
and continue until it ends.
16
2.1.2 Waterfall process
The waterfall model shows a process, where developers are to follow these steps
in order:
Requirements specification
Design
Construction
Integration
Testing and debugging
Installation
Maintenance
After each step is finished, the process proceeds to the next step.
2.1.3. Drawbacks with classic software development model
A major drawback with classic software development model is the resistance to

change once the scope of work is fixed. On large projects it took 3-4 year of
development and they tend to freeze the requirements in the start of work. Client is
not allowed to request any changes unless whole application is complete and
deployed. In between lot of parameters affecting the application tend to change like
government policies, market conditions, user requirements and most importantly
goals and objectives of the company. It may fulfill all requirements, as required
when the development started but now it is obsolete without being used for a single
day.
Choice of process models – Software project management, 4th edition, Bob

Hughes & Mike Cotterell : P 75 - 89
2.3. References
Life cycle of a project,

http://openlearn.open.ac.uk/mod/resource/view.php?id=261579
The classic six-stage project management model,

http://openlearn.open.ac.uk/mod/resource/view.php?id=261581
Software development process

http://en.wikipedia.org/wiki/Software_development_process
Choose the Right Software Method for the Job

http://www.agiledata.org/essays/differentStrategies.html
17
Session 3: Project management roles
Typical roles and responsibilities in a software project
3.1. Introduction
The roles and their relationship to the organizational management

structure need to be determined for each project or type of project, taking
into account its scale and nature. The interests of the various roles differ. If
any one person is allocated more than one of these roles, then they will, at
times, be placed in a position of attempting to satisfy competing interests.
3.1.1 Project roles
Project roles are broadly defined as follows:
Customer – a person with authority, nominated to represent the

organization(s) that receives the business benefit of the project.
Sponsor – a person with authority nominated to represent the
organization(s) undertaking the project.
Project management mentor – a person nominated to assist/advise the
project manager and provide project management oversight to the
project.
Content mentor – a person nominated to assist/advise the project
manager and provide content oversight to the project.
Project manager (concept) – a person appointed to manage a project
from initiation to project approval (i.e. only the concept phase).
Project/sub project manager – a person appointed to manage a
project/sub project from initiation (approval) through until project
finalization.
Component manager – a person who manages a project component.
Team leader – a person appointed to lead a team to deliver part of the
project’s work scope.
Team member – person assigned to a project team.
Project advisory group – the group advising the sponsor and project
manager.
Stakeholders – people and organizations that are impacted by the
project.
Users – people and organizations that will use the output of the project.
18
3.1.2 Rational Unified Process roles
RUP role definitions are consistent with the notion of separating breadth and depth.
Personality types for breadth workers and depth workers are very different. Breadth
work is quick, inexact, and resilient. Depth work takes much more time, requires
attention to detail, and must be of significantly better quality.
Each of RUP's nine disciplines has one role that focuses on breadth for that
discipline, and a different role that focuses on depth for the same discipline. Once
you understand this basic principle, it is a whole lot easier to remember the roles.
Following table lists each RUP discipline along with its corresponding breadth and
depth roles, and briefly explains the roles' functions.
Discipline Breadth role Depth role
Business Business Process Analyst Business Designer

Modeling Discovers all business use Details a single set of business use cases.
cases.
Requirements Systems Analyst Requirements Specifier

Discovers all requirement use Details a single set of requirement use cases.
cases.
Analysis and Software Architect Designer

Design Decides on technologies for Details the analysis and design for a single set of use
the whole solution. cases.
Implementation Integrator Implementer

Owns the build plan that Codes a single set of classes or a single set of class
shows what classes will operations.
integrate with one another.
Test Test Manager Test Designer

Ensures that testing is Implements automated portions of the test design for
complete and conducted for the iteration.
the right motivators.
Tester
Test Analyst Runs a specific test.
Selects what to test based on
the motivators.
Test Designer
Decides what tests should be
automated vs. manual and
creates automations.
Deployment Deployment Manager Tech Writer, Course Developer, Graphic Artist

Oversees deployment for all Create detailed materials to ensure a successful
deployment units. deployment.
19
Project Project Manager Project Manager
Management Creates the business case Plans, tracks, and manages risk for a single iteration.
and a coarse-grained plan; (Note that this discipline has only one role. Assigning
makes go / no go decisions. the depth view to a project coordinator can provide relief
for overburdened project managers.)
Environment Process Engineer Tool Specialist

Owns the process for the Creates guidelines for using a specific tool.
project.
Configuration and Configuration Manager Configuration Manager

Change Mgt Sets up the CM environment, Creates a deployment unit, reports on configuration
policies, and plan. status, performs audits, and so forth.
Change Control Manager Change Control Manager

Establishes a change control Reviews and manages change requests.
process.
(Again, note that breadth and depth roles are assigned
to the same people in this discipline; assistant or
associate managers in the depth roles would be
helpful.)
Described on the following sections are a typical Roles and Responsibilities

document for the Management Information Systems group. (The original for this
can be found at
https://mis.vanderbilt.edu/METHODOLOGY/RolesandResponsibilites.doc )
3.2.1 Advanced Application Development Management Team (AAD) – This

Team is made up of the MIS Director, Practice Managers, Program Managers and
the Technical Architect. Their responsibilities include:
I. Provide the strategic direction for the MIS department
II. Manage MIS resources and assignments
III. Establish and evaluate MIS development policies, methodologies, and
procedures
IV. Review Project Workbooks.
3.2.2 Customer – The Customer is the person or department requesting work

from MIS. The Customer’s responsibilities will vary throughout the project phases.
Their primary responsibilities will include:
I. Partner with the MIS Practice Manager to create the Project
Workbook
II. Partner with the MIS Practice Manager to manage the project
including the timeline, work plan, testing, resources, training and
documentation of procedures
20
III. Work with the Practice and Program Manager to identify the technical
approach to be used and the deliverables to be furnished at the
completion of the project
IV. Provide a clear definition of the business need
V. Sign-off on project deliverables
VI. Take ownership of the developed process and software.
3.2.3 Customer Feedback Evaluation Team – The Customer Feedback

Evaluation Team consists of various members of the MIS department. Their
responsibilities include:
I. Review the completed Project Performance Evaluation Forms
II. Highlight ratings below “satisfied” so the MIS Practice Manager can
contact the customer for additional details
III. Forward copies of all forms to the MIS Director and the MIS Practice
Manager for review and/or follow-up
IV. Follow-up with MIS Practice Manager on resolution of those being
reviewed with the customers
V. Track the results of the forms for general trends and areas to improve.
3.2.4 Design Review Team – The Design Review Team will consist of the
Technical Architect, the Program Manager for Infrastructure and the Program
Manager for Development. Their responsibilities include:
I. Review and approve all Design Overview Documents
II. Review, prior to the meeting, design packages to be presented and be
prepared with questions and comments
III. Perform audit reviews on tested packages.
IV. Be available to provide consultative support to any developer or
development team on questions of standards, procedures, techniques,
etc.
3.2.5 Executive Sponsor – The Executive Sponsor is typically a high-level

executive who acts as the project advocate from University Administration. Their
primary responsibilities include:
V. Champion the project, project manager and project team
VI. Manage the project scope and change requests
VII. Approve the Project schedule
VIII. Communicate project goals to all management levels
IX. Provide appropriate and timely resources for efficient and effective
project completion
X. Ensure sustained adherence to schedule commitments
21
XI. Provide on-going guidance and direction to the project team
XII. Provide regular feedback to the project team on performance vs.
expectations
XIII. Follow up to ensure project benefits defined in the Project Workbook
are realized
XIV. Escalate issues and project scope changes
XV. Act as the final decision maker on unresolved project issues.
3.2.6 Functional Resources – The Functional Resources represent the

business areas for which work is being performed and are usually members of that
business area. The primary project activities of the Functional Resources include:
I. Share their in-depth understanding of the business and system
processes and their knowledge of federal regulations
II. Provide business expertise on the system functionality related to their
job functions
III. Participate actively in all phases of the project including planning and
analysis, design, development, testing and implementation, related to
their area of expertise
IV. Be available for the indicated percentage of their time allotted for the
project.
3.2.7 Functional Lead – The Functional Lead represents the customer’s

business area for which work is being preformed. The Functional Leads
responsibilities include:
I. Provide expertise on the overall business processes around which the
project is focused and provide needed business expertise in those
areas
II. Provide direction to the functional resources on managing day-to-day
activities and adhering to project deliverable due dates
III. Participate actively in the development of the Project Workbook (in
conjunction with the Program Manager and Practice Manager)
including why the project was requested, as well as the project
requirements and scope including the risk, time, and cost
IV. Participate actively in all phases of the project including planning and
analysis, design, development, testing and implementation, related to
their area of expertise
V. Help identify change barriers within the business areas
VI. Provide two way communication between the affected business area
and the Project Team
VII. Be available for the indicated percentage of their time allotted for the
project.
3.2.8 Help Desk & End User Computing Group – The Help Desk and End
User Computing Group provide training and support during the implementation and
production support phases of the project. This team is led and managed by the
22
Systems Manager responsible for End User Computing Activities. The Help Desk
and End User Computing Group responsibilities include:
I. Provide team and end user training during implementation
II. Provide help desk support after implementation
III. Assist in the distribution and configuration of workstations for the
Vanderbilt community
IV. Provide support for network problems, firewall problems, security
problems, and access issues.
3.2.9 Maintenance and Enhancement Group – The Maintenance and

Enhancement Group provides on-going support for systems after implementation
occurs. There are two M & E Groups currently defined: Business Operations and
Student Systems. The M & E Groups are led and managed by the Systems
Manager responsible for either Business Operation activities or Student System
activities. Primarily, the M & E Groups responsibilities include:
I. Provide day-to-day technical support in maintaining the information
system, including responsibility for ensuring processes and outputs are
complete and error-free
II. Develop an in-depth understanding of the business processes
supported by the system
III. Consult with customers (independently or in partnership with other
members of MIS) to evaluate, design, test and install requested
enhancements to the new system
IV. Run production-level programs to obtain output when necessary
V. Identify, analyze, and resolve problems with production applications
independently or in partnership with other MIS teams and/or functional
resources
VI. Develop and maintain technical documentation and operational
procedures on the new information system
VII. Provide support for the legacy systems
VIII. Manage the System Enhancement Request Form process.
3.2.10 MIS Functional Consultant – The MIS Functional Consultant is a support

role to the MIS Practice Managers and Project Implementation Team during a
project implementation. Their responsibilities include:
IX. Make written and oral presentations to project teams and groups
outside the department
X. Evaluate, establish and maintain MIS development policies,
methodologies, and procedures
XI. Plan, schedule, and coordinate activities related to system
development projects
XII. Contact department heads and various levels of staff in user
departments to provide functional support in documenting, designing,
and implementing project(s)
XIII. Assist with customer service and communication
23
XIV. Perform some planning/scheduling/prioritizing/coordination of project-
related activities for project team members.
3.2.11 Operations Group – The Operations Group monitors the operations of all
administrative information systems. The Operations Group is led and managed by
the Systems Manager responsible for Operations. Their responsibilities include:
I. Monitor and oversee the daily, weekly and monthly operations of all
administrative information systems
II. Ensure deadlines are met
III. Endure the processing and printing of forms, reports and checks and
the processing of other interfaces, during and after business hours.
IV. Perform daily scheduled tasks, such as EDI and other batch
processing
3.2.12 Practice Manager – The Practice Manager is a liaison between MIS and
the customer. The Practice Manager performs a variety of functions that include:
I. Provide leadership and management to MIS development teams and
projects
II. Consult with customers (independently or in partnership with MIS
Consultant, MIS Senior Consultant and/or Program Manager) to
understand and analyze operational procedures and information
generation or utilization needs, including why the project was
requested, as well as the project requirements and scope including the
risk, time, and cost
III. Oversee and actively participate in the development of the Project
Workbook (in conjunction with the Program Manager and Customer)
IV. Develop the project plan including the resource, skill and skill level
requirements
V. Develop procedures for changing scope and project acceptance
procedures
VI. Develop review schedules and acceptance criteria at each phase of
the project
VII. Work with the Program Manager and Customer to identify the technical
approach to be used and the deliverables to be furnished at the
completion of the project, including the development of a strategic
plan, systems analysis, technical design, coding, testing, and turnover
to production of the application
VIII. Oversee and direct, in conjunction with a Program Manager, the
strategic IS plan, development of business requirements, development
of functional and program specifications, relational database design,
programming, testing, implementation and documentation for
applications
IX. Develop the project management approach including training needed
for the project team, reporting structure of the project, frequency of
interaction between managers and resources, the number and
24
frequency of team meetings, and the need for and the extent of
involvement of external project stakeholders
X. Outline the responsibilities of different parties including customers,
management, project team, vendors, and other stakeholders
XI. Work with customers and project teams to integrate new systems into
the end-user environment.
3.2.13 Program Manager – The Program Manager provides leadership and

management of MIS development teams and projects. Program Managers perform
a variety of functions that include:
I. Oversee and direct, in conjunction with a Practice Manager, the
strategic IS plan, development of business requirements, development
of functional and program specifications, relational database design,
programming, testing, implementation and documentation for
applications
II. Oversee and actively develop the Project Workbook (in conjunction
with the Practice Manager and Customer) including why the project was
requested, as well as the project requirements and scope including the
risk, time, and cost
III. Work with Practice Manager and Customer to identify the technical
approach to be used and the deliverables to be furnished at the completion
of the project
IV. Schedule and assign resources to ensure that applications satisfy
users’ needs and are completed within agreed upon time parameters
V. Monitor the status of the technical resources and tasks using tools
such as the MIS Work Database
VI. Work with the Practice Manager to manage and oversee the system
development process including systems analysis, technical design, coding,
testing, and turnover to production of the application
VII. Develop and maintain technical documentation on computer-based
information systems; compile documentation for design changes or
creation criteria.
3.2.14 Technical Architect – The Technical Architect is a member of the MIS

department who manages the overall technical architecture of the department.
Their responsibilities include:
I. Continually research the information technology marketplace for new
and innovative technologies and application development practices.
Proactively propose these new technologies as solutions to business
problems.
II. Review proposed projects to ensure that they adhere to MIS strategic
technology vision
III. Review on-going and proposed projects to identify opportunities for
reuse, process improvement
IV. Serve as a resource to all teams in evaluating and proposing technical
alternatives for resolving project issues.
25
V. Serve as technical lead for pilot projects in areas of strategic
significance in which MIS does not yet have established skills and
methodologies.
3.2.15 Technical Lead – The Technical Lead provides leadership to the technical
resources and works in conjunction with the Program Manager and Practice
Manager to ensure that project milestones are met. The Technical Lead performs
a variety of functions that include:
I. Provide technical leadership to technical resources and customers to
meet project deadlines and ensure project objective are met
II. Plan, schedule, and coordinate activities related to system
development projects
III. Consult and mentor technical resources concerning methods,
procedures, and standards to be used during design, development,
and unit testing phases of system development projects
IV. Provide system or technical development expertise to the technical
resource team
V. Communicate issues and status information to the Program Manager
and Practice Manager concerning system development activities.
3.2.16 Technical Resources – Technical Resources may be either Vanderbilt

employees or external consultants specifically hired to do development work. The
Technical Resources responsibilities include:
• Consult with members of the project team to analyze operational
procedures and information generation or utilization needs, which may
include analyze, design, test, and implement enhancements to complex
production information systems
• Provide consultation on business process design, database administration
functions for project implementation teams, maintenance and
enhancement teams, and training teams
• Design computer programs, forms, reports, and interfaces
• Create innovative software applications from scratch using state-of-the-art
languages, protocols, and software methodologies
• Perform unit testing on computer programs, forms, reports, and interfaces
• Create and maintain technical documentation on computer-based
information systems; compiling documentation for design changes or
creation criteria
• Update systems data and prepare conversion requirements
• Provide assistance to users with software-related issues or problems.
26
3.2.17 Technical Infrastructure Team – The Technical Infrastructure Team is
the group responsible for supporting the hardware and software
components required by a system implementation. This includes the
servers, network printers, operating system, databases, user security, and
network connectivity. The primary responsibilities of this team include:
I. Ensure the application software/hardware is consistent with the

technical environment and standards
II. Provide technical system and database support for:
A. Capacity and planning
B. Space management
C. Backup and recovery
D. Performance tuning and monitoring
III. Provide application software change control across the different
environments
IV. Install and upgrade server and application software
V. Assist technical resources with database design
VI. Provide database administration support for systems development and
upgrades.
3.3. Conclusion
At the end of this session the reader should have an understanding of different
roles in a typical software development project. Many factors come into when the
Roles and Responsibilities are defined. Organizational structure, industry best
practices, skill availability are to name a few.
3.4 References
Breadth and depth roles in RUP

http://www.ibm.com/developerworks/rational/library/apr05/crain/index.html
27
Session 4: Enterprise/Organizational management
structure
What is an Organization and how is it organized?
4.1. Introduction
Projects are typically part of an organization that is larger than the project.
Examples of organizations include corporations, government agencies,
healthcare institutions, international bodies, professional associations, and
others. Even when the project is external (joint ventures, partnering) the
project will still be influenced by the organization or organizations that
initiated it. The maturity of the organization with respect to its project
management system, culture, style, organizational structure and project
management office can also influence the project.
Organizational Influences - A Guide to the Project Management Body of

Knowledge: P 27 - 33
28
Session 5: Software management types (acquisition,
project, development, maintenance, risk)
Different types of software projects.
5.1. Introduction
Not all software projects are similar in nature. They range from enhancement to an
existing software system to a complete overhaul of an existing legacy system.
Depending on the type of the project the applicable project management technique
varies.

Following table consists of different software projects that are commonly
undertaken. The project category column states the type of the project and the
description provides a summary description on what the project type will involve.
Project Category Description

You have purchased or downloaded a system built
externally to your organization that may (or may
not) be modified to meet your unique needs and/or
to integrate into your existing environment. Legacy
Commercial Off-The analysis will comprise a significant portion of this
1 Shelf (COTS) effort
You are building a database, or collection of
2 Data warehouse databases, to be used for reporting purposes.
You have to quickly add a new feature, or fix a high-
priority defect, within a system that is currently in
3 Emergency release production.
You are integrating two or more existing systems, to
wrap access to one or more existing systems, or
4 Integration/replacement simply to replace them.
New application
development –
Component/object
technologies (e.g.
5 Java) You are developing a new system.
29
New application
development –
Procedural
technologies (e.g.
6 COBOL) You are developing a new system.
You are operating and evolving an existing system
7 Ongoing maintenance in production.
8 Outsourced You are managing an outsourcing effort.
9 Retirement You are retiring an existing legacy system.
Your system can affect the health or safety of
people. Examples include air traffic control
systems, medical research data analysis reports,
10 Safety Critical and heart monitoring systems.
The link in the references section contains the suggested methodology.
5.3 References
Choose the Right Software Method for the Job

http://www.agiledata.org/essays/differentStrategies.html
30
UNIT 03: PROJECT PERSONNEL AND
ORGANIZATION
Objectives of this unit are to introduce the organization structure, the roles and
responsibilities of the individuals in the organization and the management of the
individuals.
Session 1: Organizational structures, positions,

responsibilities, and authority
What is an Organization structure?

Roles and responsibilities of the individuals in the organization
1.1. Introduction
Organization Structure is the form of an organization that is evident in the

way divisions, departments, functions, and people link together and
interact. Organization structure reveals vertical operational responsibilities,
and horizontal linkages, and may be represented by an organization chart.
The complexity of an organization's structure is often proportional to its
size and its geographic dispersal. The traditional organization structure for
many businesses in the 20th century was the bureaucracy, originally
defined by Max Weber. More recent forms include the flat, network, matrix,
and virtual organizations. These forms became more prevalent during the
last decades of the 20th century as a result of the trend toward
restructuring and downsizing and developments in telecommunications
technology. According to Harold J. Leavitt, organization structure is
inextricably linked to the technology and people who perform the tasks.
Charles Handy has shown that it is also directly linked to corporate culture.
Leadership is a role, and leadership is a responsibility; mainly considered it

is a responsibility.
Managing people and organizing teams – Software project management, 4th

edition, Bob Hughes & Mike Cotterell : P 232 – 235
31
Organizational structures – Software project management, 4th edition, Bob Hughes
& Mike Cotterell : P 247 - 249
Leadership – Software project management, 4th edition, Bob Hughes & Mike
Cotterell : P 245 - 247
Project human resource management - A Guide to the Project Management Body

of Knowledge: P 199 – 200
Human resource planning - A Guide to the Project Management Body of

Knowledge: P 205 - 209
32
Session 2: Formal/informal communication
What is formal and informal communication?

What are the different types of networks used in communication?
2.1. Introduction
Communication can be formal and informal. However, formal

communication does not mean written communication. For example, a
verbal reprimand from a manager to a subordinate is a form of formal
communication, whereas a written joke passed around the office is a form
of informal communication. The purposes of informal communication are
(1) to satisfy personal needs; (2) to prevent boredom; (3) to provide
information relevant to the job that is not provided by formal channels.
2.2.1 Informal & Formal Networks
2.2.1.1. Informal Networks
Informal communication can be defined as passing information outside the

official channels, for example employees chatting in the canteen or pub. It
can affect the future of a business, particularly if the formal system has
broken down.
2.2.1.2. Formal Networks
This takes place within the official channels, i.e. the lines of communication
approved by senior management, for example a marketing manager
talking to the marketing director.
Communication channels are established by the organization and are

accepted and recognized by employees and managers. Formal Networks
are split into two different areas which are centralized and decentralized
networks.
2.2.1.2.1. Centralized Networks
In this network the information must pass through a central position. This is
ideal for simple problems which are quick. There is a possibility that the
centralized position can become overloaded. Centralized networks can be
put into three categories which are: the Y, the chain and the wheel.
33
• The Y chain is an example of formal communication within a hierarchy
such as in the police force and the army, where information needs to
be passed from many superiors to the lower level workers. The Chain
is where one person passes information to the others, who then pass it
on. This is a formal approach that tends to be by adopted
organizations such as the Civil Service. The main advantage is that
there is a leader at the top of the hierarchy who can oversee
communications downwards and upwards to different areas of the
business. One problem may be the isolation felt by those at the bottom
of the network as they feel they have no contact with the bosses.
• The Wheel pattern has one person in the centre who feeds information
out to each individual. This network is particularly good at solving
problems as everybody is involved in the communication.
2.2.1.2.2. Decentralized Networks
In decentralized networks, the information is generally passed around to all

employees. Decentralized networks can be put into two categories, the
circle and all channels.
• The Circle In a circle it is possible to communicate with any two others.

This type of communication may occur between middle managers from
different departments at the same level of the organization. The main
problem with this type of network is that decision making can be slow
or poor because of a lack of co-ordination.
• The” All Channel” Network communication system might be used in

small group environments. It provides the best solution to difficult
problems as everyone is involved. This type of network may be used
when a department decides to”brainstorm“. Its disadvantages are that
it is slow as so many people need to be consulted.
2.2.2. Dispersed and virtual teams – Software project management, 4th edition,
Bob Hughes & Mike Cotterell : P 249 - 253
2.2.3. Project communications management - A Guide to the Project

Management Body of Knowledge: P 221 – 231
34
Session 3: Project staffing
How to choose the right person for the right job?
3.1. Introduction
Your project is only as good as the people working on it. Get the right people for
the job by finding those who know the project or subject matter inside and out, who
get along well with others, who are available and interested and who can use the
appropriate technology with expertise and skill.
Staffing the project organization can become a long and tedious effort, especially
on large and complex engineering projects. Three major questions must be
answered;
• What people resources are required?

• Where will the people come from?
• What type of project organizational structure will be best?
To determine the people resources required, the types of individuals (possibly job
descriptions) must be decided on, as well as how many individuals from each job
category are necessary and when these individuals will be needed.
Selecting the right person for the job – Software project management, 4th edition,
Bob Hughes & Mike Cotterell : P 235 – 237
Acquire project team - A Guide to the Project Management Body of Knowledge: P

209 – 215
Section “4.8 THE ORGANIZATIONAL STAFFING PROCESS” in the following link,

http://media.wiley.com/product_data/excerpt/70/04712257/0471225770.pdf
35
Session 4: Personnel training, career development,
and evaluation
Benefit of the career development for the company and the individual
How can an individual be evaluated?
4.2.1 Career development (http://en.wikipedia.org/wiki/Career_development)
In organizational development, the study of career development looks at;
• How individuals manage their careers within and between

organizations
• How organizations structure the career progress of their members,
it can also be tied into succession planning within some
organizations.
In personal development, career development is:
• The total constellation of psychological, sociological, educational,

physical, economic, and chance factors that combine to influence
the nature and significance of work in the total lifespan of any
given individual.
• The lifelong psychological and behavioral processes as well as

contextual influences shaping one’s career over the life span. As
such, career development involves the person’s creation of a
career pattern, decision-making style, integration of life roles,
values expression, and life-role self concepts.
Manage project team: Tools and techniques - A Guide to the Project Management
Body of Knowledge: P 217 – 219
4.2.2 Employee evaluation
An organization needs constantly to take stock of its workforce and to

assess its performance in existing jobs for three reasons:
36
To improve organizational performance via improving the
performance of individual contributors. Two key questions
should be posed:
What has been done to improve the

performance of a person last year?
What can be done to improve his or her
performance in the year to come?).
To identify potential, i.e. to recognize existing talent and to use

that to fill vacancies higher in the organization or to transfer
individuals into jobs where better use can be made of their
abilities or developing skills.
To provide an equitable method of linking payment to

performance.
On-the-spot managers and supervisors, not HR staffs, carry out

evaluations. The personnel role is usually that of:
Advising top management of the principles and objectives of

an evaluation system and designing it for particular
organizations and environments.
Developing systems appropriately in consultation with

managers, supervisors and staff representatives. Securing the
involvement and cooperation of appraisers and those to be
appraised.
Assistance in the setting of objective standards of evaluation /

assessment, for example:
Defining targets for achievement;
Explaining how to quantify and agree
objectives;
Introducing self-assessment;
Eliminating complexity and duplication.
Publicizing the purposes of the exercise and explaining to staff

how the system will be used.
Organizing and establishing the necessary training of

managers and supervisors who will carry out the actual
evaluations/appraisals. Not only training in principles and
procedures but also in the human relations skills necessary.
37
Monitoring the scheme - ensuring it does not fall into disuse,
following up on training/job exchange etc. recommendations,
reminding managers of their responsibilities.
Full-scale periodic reviews should be a standard feature of schemes since

resistance to evaluation/appraisal schemes is common and the temptation
to water down or render schemes ineffectual is ever present.
Basically an evaluation/appraisal scheme is a formalization of what is done

in a more casual manner anyway (e.g. if there is a vacancy, discussion
about internal moves and internal attempts are usually a result of a casual
evaluation). Most managers approve merit payment and that too calls for
evaluation. Made a standard routine task, it aids the development of talent,
warns the inefficient or uncaring and can be an effective form of motivation.
38
Session 5: Meeting management
Selecting participants
Developing an Agenda
Opening a meeting
Establishing ground rules
Time management at a meeting
Evaluate the meeting
Closing a meeting
5.1. Introduction
Meetings are unpopular because they take up time, usually that of many
people. However, there are good meetings and there are bad meetings.
The process used in a meeting depends on the kind of meeting you plan to
have, e.g., staff meeting, planning meeting, problem solving meeting, etc.
However, there are certain basics that are common to various types of
meetings
5.2.1 Selecting Participants
The decision about who is to attend depends on what you want to

accomplish in the meeting. This may seem too obvious to state, but it's
surprising how many meetings occur without the right people there.
Don't depend on your own judgment about who should come. Ask several
other people for their opinion as well.
If possible, call each person to tell them about the meeting, its overall
purpose and why their attendance is important.
Follow-up your call with a meeting notice, including the purpose of the
meeting, where it will be held and when, the list of participants and whom
to contact if they have questions.
Send out a copy of the proposed agenda along with the meeting notice.
39
Have someone designated to record important actions, assignments and
due dates during the meeting. This person should ensure that this
information is distributed to all participants shortly after the meeting.
5.2.2 Developing Agendas
Develop the agenda together with key participants in the meeting. Think of
what overall outcome you want from the meeting and what activities need
to occur to reach that outcome. The agenda should be organized so that
these activities are conducted during the meeting.
In the agenda, state the overall outcome that you want from the meeting
Design the agenda so that participants get involved early by having

something for them to do right away and so they come on time.
Next to each major topic, include the type of action needed, the type of
output expected (decision, vote, action assigned to someone), and time
estimates for addressing each topic
Ask participants if they'll commit to the agenda
Keep the agenda posted at all times
Don't overly design meetings; be willing to adapt the meeting agenda if

members are making progress in the planning process.
Think about how you label an event, so people come in with that mindset; it
may pay to have a short dialogue around the label to develop a common
mindset among attendees, particularly if they include representatives from
various cultures.
5.2.3 Opening Meetings
Always start on time; this respects those who showed up on time and
reminds late-comers that the scheduling is serious.
Welcome attendees and thank them for their time.
Review the agenda at the beginning of each meeting, giving participants a

chance to understand all proposed major topics, change them and accept
them.
Note that a meeting recorder if used will take minutes and provide them
back to each participant shortly after the meeting.
40
Model the kind of energy and participant needed by meeting participants.
Clarify your role(s) in the meeting.
5.2.4 Establishing Ground Rules for Meetings
You don't need to develop new ground rules each time you have a
meeting. However, it pays to have a few basic ground rules that can be
used for most of your meetings. These ground rules cultivate the basic
ingredients needed for a successful meeting.
Four powerful ground rules are: participate, get focus, maintain momentum
and reach closure. (You may want a ground rule about confidentiality.)
List your primary ground rules on the agenda.
If you have new attendees who are not used to your meetings, you might
review each ground rule.
Keep the ground rules posted at all times.
5.2.5 Time Management
One of the most difficult facilitation tasks is time management -- time

seems to run out before tasks are completed. Therefore, the biggest
challenge is keeping momentum to keep the process moving.
You might ask attendees to help you keep track of the time.
If the planned time on the agenda is getting out of hand, present it to the
group and ask for their input as to a resolution.
5.2.6 Evaluations of Meeting Process
It's amazing how often people will complain about a meeting being a
complete waste of time -- but they only say so after the meeting. Get their
feedback during the meeting when you can improve the meeting process
right away. Evaluating a meeting only at the end of the meeting is usually
too late to do anything about participants' feedback.
Every couple of hours, conduct 5-10 minutes "satisfaction checks".
41
In a round-table approach, quickly have each participant indicate how they
think the meeting is going.
5.2.7 Evaluating the Overall Meeting
Leave 5-10 minutes at the end of the meeting to evaluate the meeting;
don't skip this portion of the meeting.
Have each member rank the meeting from 1-5, with 5 as the highest, and
have each member explain their ranking
Have the chief executive rank the meeting last.
5.2.8 Closing Meetings
Always end meetings on time and attempt to end on a positive note.
At the end of a meeting, review actions and assignments, and set the time
for the next meeting and ask each person if they can make it or not (to get
their commitment)
Clarify that meeting minutes and/or actions will be reported back to

members in at most a week (this helps to keep momentum going).
5.3. References
Managing meetings:
http://managementhelp.org/grp_skll/meetings/meetings.htm
42
Session 6: Building and motivating teams
Motivation is the set of reasons that determines one to engage in a particular

behavior
6.1. Introduction
Within a business, the employees or the team is a very important part.

They are responsible for doing most of the work that keeps the company
going altogether. When these employees are not motivated, the production
will be down, sales will be down and the company will no longer be on a
'forward' moving track. The key to keeping the company moving forward is
to have motivated employees. One of the best ways to motivate the
employees is through teamwork. It is proven through research that when
employees feel 'included' as part of a team and part of a work family, they
will be more productive and more efficient.
Motivation – Software project management, 4th edition, Bob Hughes &

Mike Cotterell : P 238 - 245
6.2.1 Motivation theorists and their theories
Although the process of management is as old as history, scientific

management as we know it today is basically a twentieth century
phenomenon. Also, as in some other fields, practice has been far ahead of
theory.
This is still true in the field of management, contrary to the situation in

some of the pure sciences. For instance, Albert Einstein, formulates a
theory, which is later proved by decades of intensive research and
experimentation. Not so in the field of management.
In fact this field has been so devoid of real fundamental work so far, that
Herbert A. Simon is the first management theoretician to win the Nobel
Prize for Economics in 1978. His contribution itself gives a clue to the
difficulty, bordering on impossibility, of real fundamental work in this field
concerned with people. In order to arrive at a correct decision, the
manager must have all the information necessary relevant to the various
factors and all the time in the world to analyze the same.
43
This is seldom, if ever, the case. Both the information available and the
time at the manager’s disposal are limited, but he or she must make a
decision. And the decision is, therefore, not the optimum one but a
'satisfying' one - in effect, a satisfactory compromise under the real
conditions prevailing in the management 'arena'.
6.2.1.1 Traditional theory 'X'
This can best be ascribed to Sigmund Freud who was no lover of people,
and was far from being optimistic. Theory X assumes that people are lazy;
they hate work to the extent that they avoid it; they have no ambition, take
no initiative and avoid taking any responsibility; all they want is security,
and to get them to do any work, they must be rewarded, coerced,
intimidated and punished. This is the so-called 'stick and carrot' philosophy
of management. If this theory were valid, managers will have to constantly
police their staff, whom they cannot trust and who will refuse to cooperate.
In such an oppressive and frustrating atmosphere, both for the manager
and the managed, there is no possibility of any achievement or any
creative work.
6.2.1.2 Theory 'Y' - Douglas McGregor
This is in sharp contrast to theory 'X'. McGregor believed that people want
to learn and that work is their natural activity to the extent that they develop
self-discipline and self-development. They see their reward not so much in
cash payments as in the freedom to do difficult and challenging work by
themselves. The manager’s job is to 'dovetail' the human wish for self-
development into the organizations need for maximum productive
efficiency. The basic objectives of both are therefore met and with
imagination and sincerity, the enormous potential can be tapped.
Does it sound too good to be true? It could be construed; by some, that

Theory 'Y' management is soft and slack. This is not true and the proof is
in the 'pudding', for it has already proved its worth in the USA and
elsewhere. For best results, the persons must be carefully selected to form
a homogeneous group. A good leader of such a group may conveniently
'absent' from group meetings so they can discuss the matters freely and
help select and 'groom' a new leader. The leader does no longer hanker
after power, lets people develop freely, and may even (it is hoped) enjoy
watching the development and actualization of people, as if, by
themselves. Everyone and most of all the organization, gains as a result.
6.2.1.3 Theory 'Z' - Abraham Maslow
This is a refreshing change from the theory X of Freud, by a fellow

psychologist, Abraham Maslow. Maslow totally rejects the dark and dingy
Freudian basement and takes us out into the fresh, open, sunny and
cheerful atmosphere. He is the main founder of the humanistic school or
44
the third force which holds that all the good qualities are inherent in people,
at least, at birth, although later they are gradually lost.
Maslow's central theme revolves around the meaning and significance of

human work and seems to epitomize Voltaire's observation in Candide,
'work banishes the three great evils -boredom, vice and poverty'. The great
sage Yajnavalkya explains in the Brihadaranyaka Upanishad that by good
works a man becomes holy, by evil works evil. A mans personality is the
sum total of his works and that only his works survive a man at death. This
is perhaps the essence of Maslow's hierarchy of needs theory, as it is more
commonly know.
Maslow's major works include the standard textbook (in collaboration with
Mittlemann), Principles of Abnormal Psychology (1941), a seminal paper,
'A Theory of Human Motivation' (1943) and the book, Eupsychian
Management (pronounced yew-sigh-keyan) published in 1965. Maslow's
theory of human motivation is, in fact, the basis of McGregor's theory 'Y'
briefly described above. The basic human needs, according to Maslow,
are:
o physiological needs (Lowest)

o safety needs;
o love needs;
o esteem needs; and
o self-actualization needs (Highest)
Man’s behavior is seen as dominated by his unsatisfied needs and he is a

'perpetually wanting animal' for when one need is satisfied, he aspires for
the next higher one. This is, seen as an ongoing activity, in which the man
is totally absorbed in order to attain perfection through self-development.
The highest state of self-actualization is characterized by integrity,

responsibility, magnanimity, simplicity and naturalness. Self-actualizers
focus on problems external to themselves. His prescription for human
salvation is simple, but not easy: 'Hard work and total commitment to doing
well the job that fate or personal destiny calls you to do or any important
job that "calls for" doing'.
Maslow has had his share of critics, but he has been able to achieve a
refreshing synthesis of divergent and influential philosophies of:
o Marx - economic and physical needs;
o Freud - physical and love needs;
o Adler - esteem needs;
o Goldstein - self-actualization.
45
6.2.1.4 Frederick Herzberg - Hygiene / Motivation Theory
This is based on analysis of the interviews of 200 engineers and

accountants in the Pittsburgh area in the USA. According to this theory,
people work first and foremost in their own self-enlightened interest, for
they are truly happy and mentally healthy through work accomplishment.
People’s needs are of two types:
• Animal Needs (hygiene factors)

o Supervision
o Interpersonal relations
o Working conditions
o Salary
• Human Needs (motivators)

o Recognition
o Work
o Responsibility
o Advancement
Unsatisfactory hygiene factors can act as de-motivators, but if satisfactory,

their motivational effect is limited. The psychology of motivation is quite
complex and Herzberg has exploded several myths about motivators such
as:
o shorter working week;
o increasing wages;
o fringe benefits;
o sensitivity / human relations training;
o Communication.
As typical examples, saying 'please' to shop-floor workers does not

motivate them to work hard, and telling them about the performance of the
company may even antagonize them more. Herzberg regards these also
as hygiene factors, which, if satisfactory, satisfy animal needs but not
human needs.
6.2.1.5 Chris Argyris
According to Argyris, organization needs to be redesigned for a fuller

utilization of the most precious resource, the workers, in particular their
psychological energy. The pyramidal structure will be relegated to the
background, and decisions will be taken by small groups rather than by a
single boss. Satisfaction in work will be more valued than material rewards.
Work should be restructured in order to enable individuals to develop to the
46
fullest extent. At the same time work will become more meaningful and
challenging through self-motivation.
6.2.1.6 Rensis Likert
Likert identified four different styles of management:
• exploitative-authoritative;
• benevolent-authoritative;
• consultative;
• participative.
The participative system was found to be the most effective in that it

satisfies the whole range of human needs. Major decisions are taken by
groups themselves and this result in achieving high targets and excellent
productivity. There is complete trust within the group and the sense of
participation leads to a high degree of motivation.
6.2.1.7 Fred Luthans
Luthans advocates the so-called 'contingency approach' on the basis that

certain practices work better than others for certain people and certain
jobs. As an example, rigid, clearly defined jobs, authoritative leadership
and tight controls lead in some cases to high productivity and satisfaction
among workers. In some other cases just the opposite seems to work. It is
necessary, therefore, to adapt the leadership style to the particular group
of workers and the specific job in hand.
6.2.1.8 Victor Vroom
Vroom's 'expectancy theory' is an extension of the 'contingency approach'.

The leadership style should be 'tailored' to the particular situation and to
the particular group. In some cases it appears best for the boss to decide
and in others the group arrives at a consensus. An individual should also
be rewarded with what he or she perceives as important rather than what
the manager perceives. For example, one individual may value a salary
increase, whereas another may, instead, value promotion. This theory
contributes an insight into the study of employee motivation by explaining
how individual goals influence individual performance.
We have discussed above only a selection of the motivation theories and

thoughts of the various proponents of the human behavior school of
management. Not included here are, among others, the thoughts of:
47
• Seebohm Rowntree - labor participation in management;
• Elton Mayo - the Hawthorne Experiments;
• Kurt Lewin - group dynamics; force field theory;
• David McClelland - achievement motivation;
• George Humans - the human group;
• William Whyte - the organization man.
What does it all add up to? Back to 'square one'? Yes, indeed, the overall
picture is certainly confusing. This is not surprising, for the human nature
and human mind defy a clear-cut model, mathematical or otherwise.
In some of the theories and thoughts presented, however, one can see
some 'glimpses' of the person and how, perhaps, he or she could be
motivated. This is rewarding in itself. But, as noted earlier, practice has
been ahead of theory in this field, so let us now move to the practical side
of management of human behavior and motivation in the workplace.
6.2.2 Application of employee motivation theory to the workplace
Management literature is replete with actual case histories of what does

and what does not motivate people. Presented here is a tentative initial
broad selection of the various practices that have been tried in order to
draw lessons for the future.
6.2.2.1 'Stick' or 'carrot' approach?
The traditional Victorian style of strict discipline and punishment has not
only failed to deliver the goods, but it has also left a mood of discontent
amongst the "working class".
Punishment appears to have produced negative rather than positive results

and has increased the hostility between 'them' (the management) and 'us'
(the workers). In contrast to this, the 'carrot' approach, involving approval,
praise and recognition of effort has markedly improved the work
atmosphere, leading to more productive work places and giving workers
greater job satisfaction.
6.2.2.2 Manager's motivation 'toolkit'
The manager's main task is to develop a productive work place, with and
through those he or she is in charge of. The manager should motivate his
or her team, both individually and collectively so that a productive work
place is maintained and developed and at the same time employees derive
satisfaction from their jobs.
48
This may appear somewhat contradictory, but it seems to work. The main
tools in the manager's kitbag for motivating the team are:
• approval, praise and recognition

• trust, respect and high expectations
• loyalty, given that it may be received
• removing organizational barriers that stand in the way of individual and
group performance (smooth business processes, systems, methods
and resources - see outline team building program)
• job enrichment
• good communications
• financial incentives
These are arranged in order of importance and it is interesting to note that

cash is way down the ladder of motivators. Let's look at a couple of
examples taken from real life situations.
The Swedish shipbuilding company, Kockums, turned a 15 million dollar

loss into a 100 million dollar profit in the course of ten years due entirely to
a changed perception of the workforce brought about by better motivation.
At Western Electric there was a dramatic improvement in output after the
supervisors and managers started taking greater interest in their
employees.
6.2.2.3 Don't coerce - persuade!
Persuasion is far more powerful than coercion, just as the pen is mightier
than the sword. Managers have a much better chance of success if they
use persuasion rather than coercion. The former builds morale, initiative
and motivation, whilst the latter quite effectively kills such qualities. The
three basic components in persuasion are:
• suggest;
• play on the person's sentiments; and
• appeal to logic.
Once convinced, the person is so motivated as to deliver the 'goods'. The

manager will have achieved the goal quietly, gently and with the minimum
of effort. It is, in effect, an effortless achievement.
There has been a considerable amount of research into persuasion /

motivation in the field of advertising and marketing. The research is entirely
of the applied type, which can and has been used to great practical
advantage. Some of the findings in this field were first published in the
fifties in a book with the title, The Hidden Persuaders, which became a
bestseller.
49
More contemporary 'persuaders' used by advertising and marketing people
include:
• Faster talk is found to be more effective, since it is remembered better.

• Brain emits fast beta waves when a person is really interested in a
particular presentation. These waves can be detected by an
instrument.
• Subliminal approach using short duration presentation, whereby the
message is transmitted below the level of awareness.
Can these findings be used in actual work conditions? AT&T (The

American Telephone and Telegraph Co.,) recognizing the importance of
hidden needs, at one time succeeded in promoting long distance calls by
use of the simple phrase: 'Reach out, reach out and touch someone'.
Managers will need to adapt this persuasion / motivation technique to their
own situation.
6.2.3 Job satisfaction - is there a trend?
This is the title of a study carried out by the US Department of Labor

among 1500 workers, who were asked to rate the job factors, from a list of
23, which they considered important starting from the most important
factor.
Their findings (Sanzotta (1977)) are contained in the table below.
It is interesting that out of the 23 job factors listed for the survey, yet with
the exception of two items (white-collar workers' choice (B) and blue-collar
workers' choice (C)) groups selected the same top ten factors, although
with different rankings. It is significant that good pay was considered as the
50
most important factor by the blue-collar workers, but it ranked as the least
important for white-collar workers.
6.2.4 Individualize motivation policies
It is well known that individual behavior is intensely personal and unique,

yet companies seek to use the same policies to motivate everyone. This is
mainly for convenience and ease compared to catering for individual
oddities (Lindstone (1978)). 'Tailoring' the policy to the needs of each
individual is difficult but is far more effective and can pay handsome
dividends. Fairness, decisiveness, giving praise and constructive criticism
can be more effective than money in the matter of motivation.
Leadership is considered synonymous (Tack (1979)) with motivation, and

the best form of leadership is designated as SAL, situation adaptable
leadership. In this style of leadership, one is never surprised or shocked,
leadership must begin with the chief executive and it is more a matter of
adaptation than of imparting knowledge. Ultimately, it is the leadership
quality which leads to the success of a company through team building and
motivating its people.
6.2.5 'The one-minute manager'
A contemporary bestseller (Blanchard & Johnson (1983)) aimed at

managers who seek to make star performers of their subordinates. To start
with, the manager sets a goal, e.g. one page read in one minute, and it is
seen to be achieved by 'one minute' of praising or reprimand as the case
may be. But to be effective, these must be given (a) promptly, (b) in
specific terms, and the behavior, rather than the person, should be praised
or reprimanded.
The concept is basic and it makes sense, although the book seeks to
'dramatize' it. 'One minute' praising is seen to be the motivating force.
Everyone is considered a winner, though some people are disguised as
losers, and the manager is extolled not to be fooled by such appearances.
6.2.6 'Lessons from America's Best-run Companies'
Another bestseller, In Search of Excellence (Peters & Waterman (1982)).

Several criteria, including analysis of annual reports and in-depth
interviews, were used to pick 14 'model excellent companies' out of an
initial sample of 62 companies. As expected, most of the action in high-
performing companies revolved around its people, their success being
ascribed to:
• productivity through people;
• extraordinary performance from ordinary employees;
• Treating people decently.
51
Personnel function and in particular leadership were considered the most
critical components. If the leaders in an organization can create and
sustain an environment in which all employees are motivated, the overall
performance is bound to be good. The three essentials for creating such
an environment are:
• fairness;
• job security; and
• Involvement.
Of all the resources available, the human resource is clearly the most
significant, but also the most difficult to manage. Excellence can only be
achieved through excellent performance of every person, rather than by
the high-pitched performance of a few individuals. And motivation is,
undoubtedly, the crux.
6.3. Conclusion
There is no simple answer to the question of how to motivate people. Can

money motivate? Yes, but money alone is not enough, though it does help.
We have discussed some of the pertinent theories bearing on human
motivation and this is balanced by some of the practical factors which can
lead to excellence. Human resource remains the focal point and leadership
the critical component, and motivation has to be 'tailored' to each
individual.
Reference: http://www.accel-team.com/motivation/index.html
52
Session 7: Conflict resolution
Conflict in the workplace just seems to be a fact of life. As long as it is resolved

effectively, it can lead to personal and professional growth.
7.1. Introduction
Conflict resolution is a range of processes aimed at alleviating or

eliminating sources of conflict. The term "conflict resolution" is sometimes
used interchangeably with the term dispute resolution or alternative dispute
resolution. Processes of conflict resolution generally include negotiation,
mediation and diplomacy. The processes of arbitration, litigation, and
formal complaint processes such as ombudsman processes, are usually
described with the term dispute resolution, although some refer to them as
"conflict resolution." Processes of mediation and arbitration are often
referred to as alternative dispute resolution.
7.2.1 Resolving conflict rationally and effectively
In many cases, conflict in the workplace just seems to be a fact of life.

We've all seen situations where different people with different goals and
needs have come into conflict. And we've all seen the often-intense
personal animosity that can result.
The fact that conflict exists, however, is not necessarily a bad thing: As
long as it is resolved effectively, it can lead to personal and professional
growth.
In many cases, effective conflict resolution skills can make the difference
between positive and negative outcomes.
The good news is that by resolving conflict successfully, you can solve
many of the problems that it has brought to the surface, as well as getting
benefits that you might not at first expect:
• Increased understanding: The discussion needed to resolve conflict

expands people's awareness of the situation, giving them an insight
into how they can achieve their own goals without undermining those
of other people;
53
• Increased group cohesion: When conflict is resolved effectively, team
members can develop stronger mutual respect, and a renewed faith in
their ability to work together; and
• Improved self-knowledge: Conflict pushes individuals to examine their

goals in close detail, helping them understand the things that are most
important to them, sharpening their focus, and enhancing their
effectiveness.
However, if conflict is not handled effectively, the results can be damaging.

Conflicting goals can quickly turn into personal dislike. Teamwork breaks
down. Talent is wasted as people disengage from their work. And it's easy
to end up in a vicious downward spiral of negativity and recrimination.
If you're to keep your team or organization working effectively, you need to

stop this downward spiral as soon as you can. To do this, it helps to
understand two of the theories that lie behind effective conflict resolution
techniques:
7.2.2 Understanding the Theory: Conflict Styles
In the 1970s Kenneth Thomas and Ralph Kilmann identified five main
styles of dealing with conflict that vary in their degrees of cooperativeness
and assertiveness. They argued that people typically have a preferred
conflict resolution style. However they also noted that different styles were
most useful in different situations. The Thomas-Kilmann Conflict Mode
Instrument (TKI) helps you to identify which style you tend towards when
conflict arises.
Thomas and Kilmann's styles are:
• Competitive: People who tend towards a competitive style take a firm

stand, and know what they want. They usually operate from a position
of power, drawn from things like position, rank, expertise, or
persuasive ability. This style can be useful when there is an
emergency and a decision needs to be make fast; when the decision is
unpopular; or when defending against someone who is trying to exploit
the situation selfishly. However it can leave people feeling bruised,
unsatisfied and resentful when used in less urgent situations.
• Collaborative: People tending towards a collaborative style try to meet

the needs of all people involved. These people can be highly assertive
but unlike the competitor, they cooperate effectively and acknowledge
that everyone is important. This style is useful when you need to bring
together a variety of viewpoints to get the best solution; when there
have been previous conflicts in the group; or when the situation is too
important for a simple trade-off.
54
• Compromising: People who prefer a compromising style try to find a
solution that will at least partially satisfy everyone. Everyone is
expected to give up something and the compromiser him- or herself
also expects to relinquish something. Compromise is useful when the
cost of conflict is higher than the cost of losing ground, when equal
strength opponents are at a standstill and when there is a deadline
looming.
• Accommodating: This style indicates a willingness to meet the needs

of others at the expense of the person’s own needs. The
accommodator often knows when to give in to others, but can be
persuaded to surrender a position even when it is not warranted. This
person is not assertive but is highly cooperative. Accommodation is
appropriate when the issues matter more to the other party, when
peace is more valuable than winning, or when you want to be in a
position to collect on this “favor” you gave. However people may not
return favors, and overall this approach is unlikely to give the best
outcomes.
• Avoiding: People tending towards this style seek to evade the conflict
entirely. This style is typified by delegating controversial decisions,
accepting default decisions, and not wanting to hurt anyone’s feelings.
It can be appropriate when victory is impossible, when the controversy
is trivial, or when someone else is in a better position to solve the
problem. However in many situations this is a weak and ineffective
approach to take.
Once you understand the different styles, you can use them to think about
the most appropriate approach (or mixture of approaches) for the situation
you're in. You can also think about your own instinctive approach, and
learn how you need to change this if necessary.
Ideally you can adopt an approach that meets the situation, resolves the
problem, respects people's legitimate interests, and mends damaged
working relationships.
7.2.3 Understanding The Theory: The "Interest-Based Relational Approach"
The second theory is commonly referred to as the "Interest-Based

Relational (IBR) Approach". This conflict resolution strategy respects
individual differences while helping people avoid becoming too entrenched
in a fixed position.
In resolving conflict using this approach, you follow these rules:
55
• Make sure that good relationships are the first priority: As far as
possible, make sure that you treat the other calmly and that you try to
build mutual respect. Do your best to be courteous to one-another and
remain constructive under pressure;
• Keep people and problems separate: Recognize that in many cases

the other person is not just "being difficult" – real and valid differences
can lie behind conflictive positions. By separating the problem from the
person, real issues can be debated without damaging working
relationships;
• Pay attention to the interests that are being presented: By listening

carefully you'll most-likely understand why the person is adopting his or
her position;
• Listen first; talk second: To solve a problem effectively you have to

understand where the other person is coming from before defending
your own position;
• Set out the “Facts”: Agree and establish the objective, observable
elements that will have an impact on the decision; and
• Explore options together: Be open to the idea that a third position may
exist, and that you can get to this idea jointly.
By following these rules, you can often keep contentious discussions

positive and constructive. This helps to prevent the antagonism and dislike
which so-often causes conflict to spin out of control.
7.2.4 Using the Tool: A Conflict Resolution Process
Based on these approaches, a starting point for dealing with conflict is to

identify the overriding conflict style employed by yourself, your team or
your organization.
Over time, people's conflict management styles tend to mesh, and a “right”
way to solve conflict emerges. It's good to recognize when this style can be
used effectively, however make sure that people understand that different
styles may suit different situations.
Look at the circumstances, and think about the style that may be
appropriate.
Then use the process below to resolve the conflict:
56
7.2.4.1 Step One: Set the Scene
If appropriate to the situation, agree the rules of the IBR Approach (or at
least consider using the approach yourself.) Make sure that people
understand that the conflict may be a mutual problem, which may be best
resolved through discussion and negotiation rather than through raw
aggression.
If you are involved in the conflict, emphasize the fact that you are
presenting your perception of the problem. Use active listening skills to
ensure you hear and understand other’s positions and perceptions.
• Restate
• Paraphrase
• Summarize
And make sure that when you talk, you're using an adult, assertive
approach rather than a submissive or aggressive style.
7.2.4.2 Step Two: Gather Information
Here you are trying to get to the underlying interests, needs, and concerns.
Ask for the other person’s viewpoint and confirm that you respect his or her
opinion and need his or her cooperation to solve the problem.
Try to understand his or her motivations and goals, and see how your
actions may be affecting these.
Also, try to understand the conflict in objective terms: Is it affecting work

performance? Damaging the delivery to the client? Disrupting team work?
Hampering decision-making? Or so on. Be sure to focus on work issues
and leave personalities out of the discussion.
• Listen with empathy and see the conflict from the other person’s
point of view
• Identify issues clearly and concisely
• Use “I” statements
• Remain flexible
• Clarify feelings
7.2.4.3 Step Three: Agree the Problem
This sounds like an obvious step, but often different underlying needs,
interests and goals can cause people to perceive problems very differently.
57
You'll need to agree the problems that you are trying to solve before you'll
find a mutually acceptable solution.
Sometimes different people will see different but interlocking problems - if

you can't reach a common perception of the problem, then at the very
least, you need to understand what the other person sees as the problem.
7.2.4.4 Step Four: Brainstorm Possible Solutions
If everyone is going to feel satisfied with the resolution, it will help if

everyone has had fair input in generating solutions. Brainstorm possible
solutions, and be open to all ideas, including ones you never considered
before.
7.2.4.5 Step Five: Negotiate a Solution
By this stage, the conflict may be resolved: Both sides may better
understand the position of the other, and a mutually satisfactory solution
may be clear to all.
However you may also have uncovered real differences between your
positions. This is where a technique like win-win negotiation can be useful
to find a solution that, at least to some extent, satisfies everyone.
There are three guiding principles here: Be Calm, Be Patient, and Have
Respect.
7.2.5 Key Points
Conflict in the workplace can be incredibly destructive to good teamwork.

Managed in the wrong way, real and legitimate differences between people
can quickly spiral out of control, resulting in situations where co-operation
breaks down and the team's mission is threatened. This is particularly the
case where the wrong approaches to conflict resolution are used.
To calm these situations down, it helps to take a positive approach to

conflict resolution, where discussion is courteous and non-confrontational,
and the focus is on issues rather than on individuals. If this is done, then,
as long as people listen carefully and explore facts, issues and possible
solutions properly, conflict can often be resolved effectively.
58
UNIT 04: PROCESS IMPLEMENTATION
Objective of this unit is to introduce the student to software development process.
A process may be defined as a method of doing or producing something.
Session 1: Levels of process definition (organization,

project, team, individual)
A software process is a method of developing or producing software
1.1. Introduction
A software development methodology refers to the framework that is used

to structure, plan, and control the process of developing an information
system. A wide variety of such frameworks have evolved over the years,
each with its own recognized strengths and weaknesses. One system
development methodology is not necessarily suitable for use by all
projects. Each of the available methodologies is best suited to specific
kinds of projects, based on various technical, organizational, project and
team considerations.
The framework of a software development methodology consists of:

A software development philosophy, with the approach or
approaches of the software development process
Multiple tools, models and methods, to assist in the software
development process.
These frameworks are often bound to some kind of organization, which

further develops, supports the use, and promotes the methodology. The
methodology is often documented in some kind of formal documentation.
According to the IEEE, a process is "a sequence of steps performed for a

given purpose." The SEI, in their CMM, expand upon process to define a
software process as "a set of activities, methods, practices, and
transformations that people use to develop and maintain software and the
59
associated products, e.g., project plans, design documents, code, test
cases, and user manuals."
1.2.1 A software development process is a structure imposed on the

development of a software product. There are several models for such
processes, each describing approaches to a variety of tasks or activities
that take place during the process.
http://en.wikipedia.org/wiki/Software_process
1.2.2 The Many Dimensions of the Software Process

http://www.acm.org/crossroads/xrds6-4/software.html
60
Session 2: Life cycle models (agile, heavyweight,
waterfall, spiral, V-Model)
A methodology is more likely to be used if it is simple, clearly effective, and small in

terms of required work products
2.1. Introduction

development of a software product. There are several models for such
processes, each describing approaches to a variety of tasks or activities
that take place during the process.
Selection of an appropriate project approach – Software project

management, 4th edition, Bob Hughes & Mike Cotterell : P 68 – 75
The three basic patterns in software development methodologies can be

depicted as below.
61
The waterfall model – Software project management, 4th edition, Bob
Hughes & Mike Cotterell : P 75 – 76
The V-Process model – Software project management, 4th edition, Bob

The Spiral model – Software project management, 4th edition, Bob

Software prototyping – Software project management, 4th edition, Bob

Extreme programming – Software project management, 4th edition, Bob

2.3 References
2.3.1 Agile software development refers to a group of software development

methodologies based on iterative development, where requirements and
solutions evolve through collaboration between self-organizing cross-
functional teams.
http://en.wikipedia.org/wiki/Agile_software_development
2.3.2 A Tale of two Methodologies: Heavyweight versus Agile
http://ausweb.scu.edu.au/aw04/papers/edited/balbo/
2.3.3 The waterfall model is a sequential software development process, in

which progress is seen as flowing steadily downwards (like a waterfall)
through the phases of Conception, Initiation, Analysis, Design (validation),
Construction, Testing and maintenance.
http://en.wikipedia.org/wiki/Waterfall_software_development
2.3.4 The spiral model is a software development process combining elements

of both design and prototyping-in-stages, in an effort to combine
advantages of top-down and bottom-up concepts.
http://en.wikipedia.org/wiki/Spiral_model
2.3.5 The V-Model is a systems development model designed to simplify the

understanding of the complexity associated with developing systems.
62
http://en.wikipedia.org/wiki/V_model
2.3.6 The Rational Unified Process (RUP) is an iterative software development

process framework created by the Rational Software Corporation, a
division of IBM since 2003. RUP is not a single concrete prescriptive
process, but rather an adaptable process framework, intended to be
tailored by the development organizations and software project teams that
will select the elements of the process that are appropriate for their needs.
http://en.wikipedia.org/wiki/Rup
2.3.7 Microsoft Solutions Framework (MSF) is a set of principles, models,

disciplines, concepts, and guidelines for delivering information technology
solutions from Microsoft. MSF is not limited to developing applications only,
it is also applicable to other IT projects like deployment, networking or
infrastructure projects. MSF does not force the developer to use a specific
methodology (Waterfall, Agile) but lets them decide what methodology to
use.
http://en.wikipedia.org/wiki/Microsoft_Solution_Framework
2.3.8 Extreme Programming (XP) is a software engineering methodology

prescribing a set of daily stakeholder practices that embody and encourage
particular XP values. Proponents believe that exercising these practices—
traditional software engineering practices taken to so-called "extreme"
levels—leads to a development process that is more responsive to
customer needs than traditional methods, while creating software of better
quality.
Proponents of Extreme Programming and agile methodologies in general
regard ongoing changes to requirements as a natural, inescapable and
desirable aspect of software development projects; they believe that
adaptability to changing requirements at any point during the project life is
a more realistic and better approach than attempting to define all
requirements at the beginning of a project and then expending effort to
control changes to the requirements. However, XP has been noted for
several potential drawbacks, as compared to more document-based
methodologies, including problems with unstable requirements, no
documented compromises of user conflicts, and lack of an overall design
spec or document.
http://en.wikipedia.org/wiki/Extreme_programming
63
Session 3: Life cycle process models and standards
(IEEE, ISO)
Introduction to CMMI, ISO 9000 standards, Six sigma, ISO/IEC 15504
3.1. Introduction
Standard bodies have introduced several standards for software
development process such that the development procedures, generated
artifacts can be recognized internationally and quality controlled and quality
can be quantified.
3.2.1 Capability Maturity Model Integration (CMMI) in software engineering and

organizational development is a process improvement approach that
provides organizations with the essential elements for effective process
improvement. It can be used to guide process improvement across a
project, a division, or an entire organization. CMMI helps integrate
traditionally separate organizational functions, set process improvement
goals and priorities, provide guidance for quality processes, and provide a
point of reference for appraising current processes.
http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration
3.2.2 ISO 9000 is a family of standards for quality management systems. ISO
9000 is maintained by ISO, the International Organization for
Standardization and is administered by accreditation and certification
bodies. The rules are updated, the time and changes in the requirements
for quality, motivate change.
http://en.wikipedia.org/wiki/ISO_9000
3.2.3 ISO/IEC 15504 also known as SPICE (Software Process Improvement and
Capability Determination) is a "framework for the assessment of
processes" developed by the Joint Technical Subcommittee between ISO
(International Organization for Standardization) and IEC (International
Electrotechnical Commission). ISO/IEC 15504 initially was derived from
process lifecycle standard ISO 12207 and the ideas of many maturity
models like Bootstrap, Trillium and the CMM.
http://en.wikipedia.org/wiki/ISO_15504
64
3.2.4 Six Sigma is a business management strategy, initially implemented by
Motorola, that today enjoys widespread application in many sectors of
industry.
Six Sigma seeks to improve the quality of process outputs by identifying
and removing the causes of defects (errors) and variation in manufacturing
and business processes. It uses a set of quality management methods,
including statistical methods, and creates a special infrastructure of people
within the organization ("Black Belts" etc.) who are experts in these
methods. Each Six Sigma project carried out within an organization follows
a defined sequence of steps and has quantified financial targets (cost
reduction or profit increase).
http://en.wikipedia.org/wiki/Six_Sigma
65
Session 4: Individual software process (model,
definition, measurement, analysis, improvement)
What is individual software process? (Also known as Personal software process)
4.1. Introduction
Every so often, a new methodology is launched onto the software

engineering landscape with all the force of a religious crusade. From its
humble beginnings, Software Process Improvement (SPI), which includes
initiatives such as CMM and ISO 9000, has spread its wings into virtually
every sector of the software engineering community and in the process has
transformed itself from a bag of tools and techniques, into a serious set of
methodologies for enhancing organizational effectiveness and competitive
success. In the latter half of the 1990's, individual SPI methodologies such
as PSP and PIPSI were promulgated as approaches to make the individual
a better software engineer. Essentially they are a bottom up approach
where individual software engineers manage and assess their own work,
as opposed to the delegated practices of large, organization-wide SPI
models.
The PSP (Personal Software Process) was developed at the Software

Engineering Institute (SEI) by Watts Humphrey. It is designed to bring
discipline to the practices of individual software engineers. The PSP
provides students and practicing software engineers with a framework for
measuring and analyzing their development work so that they produce
programs of higher quality and in a more predictable manner. More
specifically the objectives of the PSP are as follows:
To introduce students and engineers to a process-based approach

to developing software
To show students and engineers how to measure, estimate,

schedule, and track their work
To show students and engineers how to improve the quality of

their programs
66
The concepts, structure, and activities of the PSP are described in detail in
the textbook,
“Discipline for Software Engineering”, in which Humphrey characterizes the
purpose and scope of the PSP: “The PSP’s sole purpose is to help you be
a better engineer. ... It can help you plan, better track your performance
precisely, and measure the quality of your products. Whether you design
programs, develop requirements, write documentation, or maintain existing
software, the PSP can help you do better work. ... The PSP is not a magic
answer to all your software problems. Although it can suggest where and
how you can improve, you must make the improvements yourself.”
Humphrey’s book (along with the instructor support materials) is used as

the basis for many courses taught in industry and in academia. While PSP
training includes learning a specific personal process, the point of the
training is to teach process improvement concepts and to give the engineer
an appreciation of the value of a defined process. PSP-trained engineers
are expected to evolve their own processes from what was taught in class -
to make them truly personal processes. This places control of the process
squarely in the hands of the individual who is in the best position to
optimize it.
Although the components of the PSP are not complicated and they are
based on sound engineering principles, both teachers, students, and
engineers have found that learning PSP is a demanding and challenging
activity. PSP training is a significant investment (about 150 hours per
engineer to complete the course). This is because the course is more than
just a class; it is a boot camp. It goes beyond telling the engineers what to
do, by having them use the principles while writing ten programs and
collecting and analyzing data about their performance. In the PSP training,
the engineers convince themselves of what works for them and what
doesn’t so that they can take control of their personal software process.
The PSP provides an incremental approach. It includes seven PSP
processes can be grouped into four process levels (figure 1) that have
following focus:
PSP0 - establish a measured performance baseline
PSP1 - make size, resource, and schedule plans
PSP2 - learn defect and quality management
PSP3 - scale up PSP methods to larger projects
The processes are said to be “defined” since that include precise and
unambiguous procedures for carrying out the process. Each process is
structured into a set of processes phases; each phase has a script that
gives a step-by-step description of the tasks to be completed; and there
are forms and documented standards that are used in carrying out the
67
process tasks. There is also additional guidance and advice on how to
analyze and improve one’s process.
Reporting of actual industrial use data about the effects of the PSP has
been limited by several factors:
Many companies are reluctant to release specific data that

competitors or customers could use to identify actual cost and
defect levels.
Most companies have little or no historical data to compare PSP

data against, so it is difficult to quantify the effects that PSP had on
their costs and schedule.
PSP has not been widely adopted, so there are fewer cases
available to draw from.
4.3 References
4.3.1 Individual Software Process Improvement. Does Europe Need It?

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8B31D7D5D6CC
9A2249E1827FFCC7EE68?doi=10.1.1.18.9532&rep=rep1&type=pdf
4.3.2 Introduction to personal software process

http://books.google.lk/books?id=_g0te-
9WuLYC&dq=Individual+software+process&printsec=frontcover&source=i
n&hl=en&ei=YHkjSp-
xKpzU7AP3iIDEAw&sa=X&oi=book_result&ct=result&resnum=11#PPA5,M
1
4.3.3 Measuring the software process.

http://books.google.lk/books?id=gcA-
S8bK9YoC&dq=Individual+software+process&printsec=frontcover&source
=in&hl=en&ei=YHkjSp-
xKpzU7AP3iIDEAw&sa=X&oi=book_result&ct=result&resnum=13#PPA1,M
1
68
Session 5: Team process (model, definition,
organization, measurement, analysis, improvement)
Introduction to Team Software Process
5.1. Introduction
In combination with the Personal Software Process (PSP), the Team

Software Process (TSP) provides a defined operational process framework
that is designed to help teams of managers and engineers organize and
produce large-scale software projects of sizes beyond several thousands
lines of code (KLOC). The TSP is intended to improve the levels of quality
and productivity of a team's software development project, in order to help
them better meet the cost and schedule commitments of developing a
software system.
The initial version of the TSP was developed by Watts Humphrey in 1996,
and the Technical Report for TSP was published in November 2000 and
sponsored by the U.S. Department of Defense. The book of Watts
Humphrey, "Introduction to the Team Software Process" (Addison Wesley
Professional, Massachusetts, 1999), presents the TSP in detail and, in
particular, focuses on the process of building a software production team,
establishing team goals, distributing team roles, and other teamwork-
related activities.
5.2.1 What Is Team Software Process (TSP)?
The Team Software Process (TSP), along with the Personal Software
Process, helps the high-performance engineer to,
ensure quality software products
create secure software products
improve process management in an organization
Engineering groups use the TSP to apply integrated team concepts to the
development of software-intensive systems. These include,
establishing goals
defining team roles
assessing risks
producing a team plan
69
After the launch, the TSP provides a defined process framework for
managing, tracking and reporting the team's progress.
Using TSP, an organization can build self-directed teams that plan and
track their work, establish goals, and own their processes and plans.
These can be pure software teams or integrated product teams of 3 to 20
engineers.
TSP will help your organization establish a mature and disciplined

engineering practice that produces secure, reliable software.
TSP is also being used as the basis for a new measurement framework for
software acquirers and developers. This effort is the Integrated Software
Acquisition Metrics (ISAM) Project.
The principal elements of the TSP process are shown in the following
figure. Before the members can participate on a TSP team, they must
know how to do discipline work. As shown in this figure, training in the
Personal Software Process (PSP) is required to provide engineers with the
knowledge and skills to use the TSP. PSP training includes learning how to
make detailed plans, gathering and using process data, developing earned
value plans, using earned value to track a project, measuring and
managing product quality, and defining and using operational processes.
Engineers must be trained in these skills before they can participate in TSP
team building or follow the defined TSP process.
70
Session 6: Process tailoring
What is process tailoring?
6.1. Introduction
Tailoring in Software development is the process of extracting a set of

processes, tasks and artifacts from the organizations established
processes, tasks and artifacts so as to best suit a project to achieve its
objectives.
6.2.1 Practices and Guidelines
It is very important that we have a set of tailoring guidelines that will guide
the development teams to let them decide what is best for the projects.
The guidelines must also specify what is Tailor able and what is
mandatory. For example in a software development project if a project
manager says that the project need not maintain a project management
plan then it should be not acceptable as per the tailoring guidelines. So
basically there will be some processes, tasks and artifacts that will have to
be developed and maintained in a software development project.
So these guidelines must take into account multiple aspects before being
released as part of the organization quality management system. These
aspects must look into the current state of process implementation,
customer’s needs and objectives, project characteristics etc.
Organizations that are offerings services for different types of projects like
Full life cycle development, maintenance, QA, Technical support must also
look into coming up with life cycle models for each of these type of
software projects. These life cycle models must go hand in hand with the
Process tailoring guidelines established at the organization level.
The following steps can be considered as some important points that can
help in coming up with the tailoring tasks at the project level.
6.2.2 Steps at project level
6.2.2.1 Identify Project Characteristics

Identify the characteristics of your software project. These characteristics
will be useful in formulating a project strategy and in tailoring processes.
71
6.2.2.2 Formulate a Project Strategy
Based on the characteristics of your project, formulate a strategy by
referring to Process tailoring guidelines that are established at the
organization level.
6.2.2.3 Select a suitable Quality Management System (QMS) process

In QMS, processes must be defined for the different types of projects;
example
Development (Agile, Maintenance, Waterfall etc.)

Maintenance projects
QA Projects
Technical Support Projects
The tailoring guidelines for project management and configuration

management must be made applicable to all projects.
6.2.2.4 Select lifecycle model for the Software development project and tailor
process element accordingly. For each process element, you can decide to
do one of the following:
Implement the process element as per guidelines

Waive the process element
Replace the process element
Add a new process element
Waivers and replacements from the tailoring guidelines and new process
elements not defined in the tailoring guidelines should be highlighted in
Project Management Plan as Deviations and appropriate process must be
followed in getting approvals for the waivers and deviations.
6.3 References
Software process and techniques to tailor the process.

http://www.stsc.hill.af.mil/resources/tech_docs/process_plan/prplp104.htm
l
72
UNIT 05: PROJECT PLANNING
Objective of this unit is to introduce the student the concept of project planning and
its constituents.
Project planning is a discipline for stating how to complete a project within a certain
timeframe, usually with defined stages, and with designated resources.
Session 1: Evaluation and planning
How to evaluate a project and create a plan?
1.1. Introduction
The key to a successful project is in the planning.
Introduction to Step Wise project planning – Software project

Program management and project evaluation – Software project

Creating a project plan is the first thing you should do when undertaking
any kind of project.
Often project planning is ignored in favor of getting on with the work.

However, many people fail to realize the value of a project plan in saving
time, money and many problems.
A project is successful when the needs of the stakeholders have been met.
A stakeholder is anybody directly or indirectly impacted by the project.
73
As a first step it is important to identify the stakeholders in your project. It is
not always easy to identify the stakeholders of a project, particularly those
impacted indirectly. Examples of stakeholders are:
• The project sponsor

• The customer who receives the deliverables
• The users of the project outputs
• The project manager and project team
Once you understand who the stakeholders are, the next step is to
establish their needs. The best way to do this is by conducting stakeholder
interviews. Take time during the interviews to draw out the true needs that
create real benefits. Often stakeholders will talk about needs that aren't
relevant and don't deliver benefits. These can be recorded and set as a
low priority.
The next step once you have conducted all the interviews and have a
comprehensive list of needs is to priorities them. From the prioritized list
create a set of goals that can be easily measured.
Once you have established a clear set of goals they should be recorded in
the project plan. It can be useful to also include the needs and
expectations of your stakeholders.
This is the most difficult part of the planning process completed. It's time to
move on and look at the project deliverables.
1.3. References
Project Planning, a Step by Step Guide

http://www.projectsmart.co.uk/project-planning-step-by-step.html
74
Session 2: Work breakdown structure
What is a Work Breakdown Structure (WBS)
2.1. Introduction
A work breakdown structure (WBS) in project management, is a tool used

to define and group a project's discrete work elements (or tasks) in a way
that helps organize and define the total work scope of the project.
A work breakdown structure element may be a product, data, a service, or

any combination. A WBS also provides the necessary framework for
detailed cost estimating and control along with providing guidance for
schedule development and control. Additionally the WBS is a dynamic tool
and can be revised and updated as needed by the project manager.
Identify project products and activities. – Software project management,

4th edition, Bob Hughes & Mike Cotterell : P 30 – 34
The Work Breakdown Structure is a tree structure, which shows a

subdivision of effort required to achieve an objective; for example a
program, project, and contract. In a project or contract, the WBS is
developed by starting with:
• the end objective and

• successively subdividing it into manageable components
• in terms of size, duration, and responsibility (e.g., systems,
subsystems, components, tasks, subtasks, and work packages)
• Which include all steps necessary to achieve the objective.
The Work Breakdown Structure provides a common framework for the

natural development of the overall planning and control of a contract and is
the basis for dividing work into definable increments from which the
statement of work can be developed and technical, schedule, cost, and
labor hour reporting can be established.
A work breakdown structure permits summing of subordinate costs for

tasks, materials, etc., into their successively higher level “parent” tasks,
75
materials, etc. For each element of the work breakdown structure, a
description of the task to be performed is generated. This technique
(sometimes called a System Breakdown Structure) is used to define and
organize the total scope of a project.
The WBS is organized around the primary products of the project (or
planned outcomes) instead of the work needed to produce the products
(planned actions). Since the planned outcomes are the desired ends of the
project, they form a relatively stable set of categories in which the costs of
the planned actions needed to achieve them can be collected. A well-
designed WBS makes it easy to assign each project activity to one and
only one terminal element of the WBS. In addition to its function in cost
accounting, the WBS also helps map requirements from one level of
system specification to another, for example a requirements cross
reference matrix mapping functional requirements to high level or low level
design documents.
Following diagram depicts a very simple example. A WBS for a

hypothetical banquet.
76
2.2. References
Work breakdown structure

http://www.hyperthot.com/pm_wbs.htm
Work breakdown structure

http://en.wikipedia.org/wiki/Work_breakdown_structure
77
Session 3: Effort estimation
What is effort estimation?
3.1 Introduction
In project management accurate estimates are the basis of sound project

planning.
Estimate effort for each activity. – Software project management, 4th

edition, Bob Hughes & Mike Cotterell : P 34 – 35
Software effort estimation. – Software project management, 4th edition,

Bob Hughes & Mike Cotterell : P 92 – 114
Many processes have been developed to aid engineers in making accurate

estimates, such as
• compartmentalization (i.e., breakdown of tasks),
• parametric estimating,
• structured planning,
• educated assumptions,
• Delphi method
• identifying dependencies,
• examining historical data,
• estimating each task,
• Documenting the results.
Popular estimation processes for software projects include:

• Cocomo
• Proxy Based Estimation (PROBE) (from the Personal Software
Process)
• Wideband Delphi
• The Planning Game (from Extreme Programming)
• Program Evaluation and Review Technique (PERT)
• Event chain methodology
78
It is unrealistic to expect very accurate effort estimates of software
development effort because of the inherent uncertainty in software
development projects, and the complex and dynamic interaction of factors
that impact software development effort use. Still, it is likely that estimates
can be improved because software development effort estimates are
systematically overoptimistic and very inconsistent. Even small
improvements will be valuable because of the large scale of software
development.
Inaccurate estimation of software development effort is one of the most

important reasons of IT-project failures. While too low effort estimates may
lead to project management problems, delayed deliveries, budget overruns
and low software quality, too high effort estimates may lead to lost
business opportunities and inefficient use of resources.
3.3 References
Effort Estimation Tools

http://www.laatuk.com/tools/effort_estimation_tools.html
Estimation (project management)

http://en.wikipedia.org/wiki/Estimation_(project_management)
79
Session 4: Resource allocation
What is Resource Allocation?
4.1. Introduction
The first step in building the project schedule is to identify the resources
required to perform each of the tasks required to complete the project.
Allocate Resources. – Software project management, 4th edition, Bob

Resource allocation. – Software project management, 4th edition, Bob

A resource is any person, item, tool, or service that is needed by the

project that is either scarce or has limited availability.
Many project managers use the terms “resource” and “person”

interchangeably, but people are only one kind of resource. The project
could include computer resources (like shared computer room, mainframe,
or server time), locations (training rooms, temporary office space), services
(like time from contractors, trainers, or a support team), and special
equipment that will be temporarily acquired for the project. Most project
schedules only plan for human resources—the other kinds of resources
are listed in the resource list, which is part of the project plan.
One or more resources must be allocated to each task. To do this, the

project manager must first assign the task to people who will perform it. For
each task, the project manager must identify one or more people on the
resource list capable of doing that task and assign it to them. Once a task
is assigned, the team member who is performing it is not available for other
tasks until the assigned task is completed. While some tasks can be
assigned to any team member, most can be performed only by certain
people. If those people are not available, the task must wait.
4.3 References
Allocate Resources to the Tasks
http://www.stellman-greene.com/aspm/content/view/18/38/
80
Session 5: Task scheduling
Task scheduling links the tasks to be done with the resources that will do them
5.1. Introduction
Scheduling is the process of deciding how to commit resources between

varieties of possible tasks.
Review/Publicize plan. – Software project management, 4th edition, Bob

Activity planning. – Software project management, 4th edition, Bob

5.2.1 Identify Dependencies
Once resources are allocated, the next step in creating a project schedule
is to identify dependencies between tasks. A task has a dependency if it
involves an activity, resource, or work product that is subsequently
required by another task. Dependencies come in many forms: a test plan
can’t be executed until a build of the software is delivered; code might
depend on classes or modules built in earlier stages; a user interface can’t
be built until the design is reviewed. It is the project manager’s
responsibility to work with everyone on the engineering team to identify
these dependencies. The project manager should start by taking the WBS
and adding dependency information to it: each task in the WBS is given a
number, and the number of any task that it is dependent on should be
listed next to it as a predecessor. The following figure shows the four ways
in which one task can be dependent on another.
81
5.2.2 Create the Schedule
The most common form for the schedule to take is a Gantt chart. The
following figure shows an example:
Each task is represented by a bar, and the dependencies between tasks

are represented by arrows. Each arrow either points to the start or the end
of the task, depending on the type of predecessor. The black diamond
between tasks D and E is a milestone, or a task with no duration.
Milestones are used to show important events in the schedule. The black
bar above tasks D and E is a summary task, which shows that these tasks
are two subtasks of the same parent task. Summary tasks can contain
other summary tasks as subtasks.
82
The following figure shows an example of a Gantt chart created in
Microsoft Project 2003:
83
Session 6: Risk management
What is a risk and why manage it?
6.1. Introduction
Risk management is the identification, assessment, and prioritization of

risks followed by coordinated and economical application of resources to
minimize, monitor, and control the probability and/or impact of unfortunate
events. Risks can come from uncertainty in financial markets, project
failures, legal liabilities, credit risk, accidents, natural causes and disasters
as well as deliberate attacks from an adversary. Several risk management
standards have been developed including the Project Management
Institute, the National Institute of Science and Technology, actuarial
societies, and ISO standards. Methods, definitions and goals vary widely
according to whether the risk management method is in the context of
project management, security, engineering, industrial processes, financial
portfolios, actuarial assessments, or public health and safety.
The strategies to manage risk include transferring the risk to another party,
avoiding the risk, reducing the negative effect of the risk, and accepting
some or all of the consequences of a particular risk.
Risk Management. – Software project management, 4th edition, Bob

Hughes & Mike Cotterell : P 146 -172
6.3 References
Risk Management
http://en.wikipedia.org/wiki/Risk_management
84
UNIT 6: SOFTWARE CONFIGURATION
MANAGEMENT
Objective of this unit is to introduce the student the concept of Software

Configuration Management and its constituents.
Change is inevitable when computer software is being built. And because it

happens, it must be controlled effectively. Software configuration management
(SCM) is a set of activities that are designed to control change by identifying the
work products that are likely to change, establishing relationships among them,
defining mechanisms for managing different versions of these work products,
controlling changes that are imposed, and auditing and reporting on the changes
that are made.
Session 1: Revision control
What is a revision and how do you manage it?
1.1. Introduction
A version control system (also known as a Revision Control System) is a

repository of files, often the files for the source code of computer programs,
with monitored access. Every change made to the source is tracked, along
with who made the change, why they made it, and references to problems
fixed, or enhancements introduced, by the change.
Version control systems are essential for any form of distributed,

collaborative development. Whether it is the history of a wiki page or
massive software development project, the ability to track each change as
it was made, and to reverse changes when necessary can make all the
difference between a well managed and controlled process and an
uncontrolled "first come, first serve" system. It can also serve as a
mechanism for due diligence for software projects.
85
In computer software engineering, revision control is any practice which

tracks and provides controls over changes to a project's source code.
Software developers sometimes use revision control software to maintain

documentation and configuration files as well as source code.
In theory, revision control can be applied to any type of information record.

In practice, however, the more sophisticated techniques and tools for
revision control have rarely been used outside software development
circles (though they could actually be of benefit in many other areas).
However, they are beginning to be used for the electronic tracking of
changes to CAD files, supplanting the "manual" electronic implementation
of traditional revision control.
As software is developed and deployed, it is extremely common for

multiple versions of the same software to be deployed in different sites,
and for the software's developers to be working privately on updates.
Bugs and other issues with software are often only present in certain
versions (because of the fixing of some problems and the introduction of
others as the program evolves). Therefore, for the purposes of locating and
fixing bugs, it is vitally important for the debugger to be able to retrieve and
run different versions of the software to determine in which version(s) the
problem occurs. It may also be necessary to develop two versions of the
software concurrently (for instance, where one version has bugs fixed, but
no new features, where the other is where new features are worked on).
Another problem that occurs in large software development projects is that

of multiple developers seeking to work on the program at the same time. If
two developers try to change the same file at the same time, without some
method of managing access the developers may well end up overwriting
each other's work.
Some systems attempt to manage who is allowed to make changes to

different aspects of the program, for instance, allowing changes to a file to
be checked by a designated reviewer before being added.
At the simplest level, users can simply retain multiple copies of the different
versions of the program, and number them appropriately. This simple
approach has been used on many large software projects. Whilst this
method can work, it is inefficient (as many near-identical copies of the
program will be kept around), requires a lot of self-discipline on the part of
developers, and often leads to mistakes. Consequently, systems to
automate some or all of the revision control process have been developed.
86
Most revision control systems use a system called delta compression, in
which only the differences between successive versions of files are
retained, thus allowing the efficient storage of many, many different
versions of files.
Some systems also provide methods for preventing "concurrent access"

problems, by simply locking files so that only one developer has write
access to the central "repository" at once; others, such as CVS, provide
facilities to automatically or semi-automatically merge changes. In the latter
type, the concept of a reserved edit means to explicitly lock a file for
exclusive write access, even though a merging capability exists.
The merits and risks for file locking are hotly debated; while it can provide
some protection against difficult-to-resolve merge conflicts when a user is
making radical changes to many sections of a large file (or group of files)
that is constantly being maintained, if the files are left exclusively locked for
too long, other developers can be tempted to simply bypass the revision
control software and change the files locally anyway; this can lead to more
serious problems.
Some of the more advanced version control tools offer many other
facilities, allowing deeper integration with other tools and software
engineering processes. Plug-ins are often available for IDEs such as
Visual Studio.
In particular the Wikipedia:Page history features of Wikipedia are identical
in concept and practice to the revision control software discussed above,
which was developed for source code control, in the decades before the
inception of Wikipedia.
Popular Version Control Software

* CVS
* Rational Software ClearCase http://www.rational.com
* Microsoft Visual SourceSafe http://msdn.microsoft.com/ssafe
1.3 References
What is version control? Why is it important for due diligence?

http://www.oss-watch.ac.uk/resources/versioncontrol.xml
Revision control
http://en.wikipedia.org/wiki/Version_control
Software Engineering Resources

http://www.rspa.com/spi/SCM.html#version
87
Session 2: Release management
What is a release and how to manage it?
2.1. Introduction
Release management is a software engineering process intended to
oversee the development, testing, deployment and support of software
releases. The practice of release management combines the general
business emphasis of traditional project management with a detailed
technical knowledge of the systems development lifecycle (SDLC) and IT
Infrastructure Library (ITIL) practices.
Release management usually begins in the development cycle with

requests for changes or new features. If the request is approved, the new
release is planned and designed. The new design enters the testing or
quality assurance phase, in which the release is built, reviewed, tested and
tweaked until it is ultimately accepted as a release candidate. The release
then enters the deployment phase, where it is implemented and made
available. Once deployed, the release enters a support phase, where bug
reports and other issues are collected; this leads to new requests for
changes, and the cycle starts all over again. The image below shows this
process.
88
2.2 References
7 Ways to Improve Your Software Release Management

http://www.cio.com/article/440101/7_Ways_to_Improve_Your_Software_Relea
se_Management?page=1
Release Management: Where to Start?

http://www.itsmwatch.com/itil/article.php/11700_3680776_1
89
Session 3: Tool support
A tool is used to make the development process as smooth as possible. What are
the tools used in SCM?
3.1. Introduction
Application lifecycle management is the marriage of business management

to software engineering made possible by tools that facilitate and integrate
requirements management, architecture, coding, testing, tracking, and
release management. As application development has evolved over time,
more and more tools have been introduced. Initially, software development
was supported with individual point tools, and then simple suites of tools
emerged with loose integrations. Now we have modern comprehensive
lifecycle tools that are fully integrated and provide capabilities for most of
the roles in Application lifecycle management.
Mentioned below are some open source tools which have been seen to be
useful in a software configuration management environment
Version Control Tools
Subversion (http://subversion.tigris.org )
This is quickly becoming the open source industry standard for version
control. Subversion provides numerous features and also there is an
enormous amount of support for development tools (Eclipse, NetBeans,
etc) Subversion was developed by many of the original CVS developers
and was designed to address all the things wrong with CVS.
Git (http://git.or.cz/ )
A non-traditional SCM tool but efficient and distributed version control

system. This project was originally created to manage version controlling
LINUX kernels. The main push on Git is to handle large projects more
efficiently.
90
Defect and Enhancement Tracking
JIRA (http://www.atlassian.com/software/jira/ )
JIRA is a customizable bug and issue tracker. JIRA provides custom

workflows, web service interfaces and much more. JIRA is not free, but it is
extremely cheap compared to other tools.
TRAC (http://trac.edgewall.org )
TRAC has an interface to Subversion and also has an integrated wiki.

TRAC also reads wiki markup in the commit comments of Subversion.
TRAC is open source.
Scarab (http://scarab.tigris.org)
Scarab is an open source tool to track issues. Scarab is a Java based
implementation over MySQL. Scarab is highly configurable, and will also
import/export data from other defect tracking tools.
Mantis (http://www.mantisbt.org )
Mantis is a popular open source web based issue tracker. Easily installed
and configurable.
Requirement Tools
OSRMT (http://sourceforge.net/projects/osrmt)
Open Source Requirements Management Tool manages features,

requirements, design, implementation, and testing.
Iterative Build Tools
Cruise Control
CruiseControl was for many years on the forefront of continuous build

integration. CruiseControl has been a favorite by many. There are many
options to the CruiseControl tool, which can all be configured in its xml
configuration file.
Environment Management Tools
SourceForge - (http://sourceforge.net)
The world's largest open source development web site. This environment
allows any open source project to host itself for free on the site.
91
SourceForge also enables developers to communicate efficiently, track
defects, and provides version control.
Build Tools
Ant (http://ant.apache.org)
Ant is a Java XML based build tool that has many built in libraries to
automate builds and deploys. Most development environments have
plugins to Ant, and Ant enjoys widespread support.
Maven (http://maven.apache.org)
Maven is another Java XML based build tool with many built in libraries.
Maven differs in a few aspects from Ant. First Maven is object oriented. A
developer will create a POM file to build code and that file will be inherited
on all subprojects
Other Utilities worth Mentioning
KOSMOS - (http://labs.jboss.com/kosmos)
This product is so useful, if you are using JIRA, Subversion, CruiseControl,

or SourceForge. If you are into high level understandings of where the
code is at any given moment, this tool provides a dashboard to several
version control and defect tracking tools. This tool is a JBoss portlet, so
you will need a JBoss application server to run this app.
3.3. References
Software Configuration Management and Build Tools
http://www.laatuk.com/tools/SCM_tools.html
Comparison of open source configuration management software

http://en.wikipedia.org/wiki/Comparison_of_open_source_configurati
on_management_software
Comparison of revision control software

http://en.wikipedia.org/wiki/Comparison_of_revision_control_softwar
e
Application lifecycle management tools

http://en.wikipedia.org/wiki/Application_lifecycle_management#
ALM_Tools
92
Session 4: Builds
How does software builds take place?
4.1. Introduction
The term software build refers either to the process of converting source
code files into standalone software artifact(s) that can be run on a
computer. One of the most important steps of a software build is the
compilation process where source code files are converted into executable
code.
While for simple programs the process consists of a single file being
compiled, for complex software the source code may consist of many files
and may be combined in different ways to produce many different versions.
The process of building a computer program is usually managed by a build

tool, a program that coordinates and controls other programs. Examples of
such a program are make, ant, maven and SCons. The build utility needs
to compile and link the various files, in the correct order.
Builds are generally related to Software versioning. Software versioning is

the process of assigning either unique version names or unique version
numbers to unique states of computer software. Within a given version
number category (major, minor), these numbers are generally assigned in
increasing order and correspond to new developments in the software. At a
fine-grained level, revision control is often used for keeping track of
incrementally different versions of electronic information, whether or not
this information is actually computer software.
Builds are more manageable and less prone to problems when a few key
practices are observed:
1. Source + tools = product. The only ingredients in a build should be

source files and the tools to which they are input. Given the same
source files and build tools, the resulting product should always be
the same.
93
2. Check in all original sources. When software can't be reliably
reproduced from the same ingredients, chances are the ingredient
list is incomplete. Frequently overlooked ingredients are make
files, setup scripts, build scripts, build instructions, and tool
specifications. All of these are the source you build with.
Remember: source + tools = product.
3. Segregate built objects from original source. Organize your builds

so that the directories containing original source files are not
polluted by built objects. Original source files are those you create
"from an original thought process" with a text editor, an application
generator, or any other interactive tool. Built objects are all the files
that get created during your build process, including generated
source files. Built objects should not go into your source code
directories. Instead, build them into a directory tree of their own.
This segregation allows you to limit the scope of SCM-managed
directories to those that contain only source. It also corrals the files
that tend to be large and/or expendable into one location, and
simplifies disk space management for builds.
4. Use common build tools. Developers, test engineers, and release

engineers should all use the same build tools. Much time is wasted
when a developer cannot reproduce a problem found in testing, or
when the released product varies from what was tested.
Remember: source + tools = product.
5. Build often. Frequent, end-to-end builds with regression testing

("sanity" builds) have two benefits:
a. They reveal integration problems introduced by check-ins

b. They produce link libraries and other built objects that can
be used by developers.
In an ideal world, sanity builds would occur after every check-in,

but in an active codeline it's more practical to do them at intervals,
typically nightly. Every codeline branch should be subject to
regular, frequent, and complete builds and regression testing, even
when product release is in the distant future.
6. Keep build logs and build outputs. For any built object you
produce, you should be able to look up the exact operations (e.g.,
complete compiler flag and link command text) that produced the
last known good version of it. Archive build outputs and logs,
including source file versions (e.g., a label), tool and OS version
info, compiler outputs, intermediate files, built objects, and test
results, for future reference. As large software projects evolve,
components are handed off from one group to another, and the
receiving group may not be in a position to begin builds of new
94
components immediately. When they do begin to build new
components, they will need access to previous build logs in order
to diagnose the integration problems they encounter.
4.2 References
Software versioning
http://en.wikipedia.org/wiki/Software_versioning
Session 5: Software configuration management

processes
What is a SCM process?
5.1. Introduction
A process defines the steps by which you perform a specific task or set of
tasks. An SCM process is the way SCM is performed on your project—
specifically, how an SCM tool is applied to accomplish a set of tasks.
A key mistake most people make is to assume that an SCM tool will, in and
of itself, solve their SCM problems or support their SCM requirements. This
is wrong! The picture will not hang itself if you buy a hammer and nails. It is
not the tool itself that solves a problem, but rather the application of that
tool. How you apply the SCM tool to your development environment is
called the usage model, or SCM process. It is this model or process that
will in part determine how successfully you address your SCM issues.
Effective Software Configuration Management can be defined as stabilizing

the evolution of software products and process at key points in the life
cycle. The focus of SCM includes:
• Identification of Artifacts
• Version Control
• Development Streaming (Branching)
95
• Base lining
• Build Management
• Packaging
• Deployment
• Change Request Management
• Issue Tracking
Identification of Artifacts
Early identification and change control of artifacts and work products is

integral to the project. The configuration manager needs to fully identify
and control changes to all the elements that are required to recreate and
maintain the software product.
Version Control
The primary goal of version control is to identify and manage project

elements as they change over time. The Configuration Manager should
establish a version control library to maintain all lifecycle entities. This
library will ensure that changes (deltas) are controlled at their lowest
atomic level eg documents, source files, scripts and kits etc.
Development Streaming (Branching)
To provide some level of stability and allow fluidity of parallel development

(streaming) it is quite normal for project development to be split into
branches (development groups).
The CM manager has to identify what branches will be required and

ensure they are appropriately set up (eg security etc).
Note: Typically branches include

• Developer Branches
• Release Branches
• Emergency fix Branches (i.e. mirror production)
Base lining
Base lining provides the division with a concise picture of the project
artifacts and relationships at a particular instance in time. It provides an
official foundation on which subsequent work can be based, and to which
only authorized changes can be made.
96
Through base lining (i.e. labeling, tagging) all constituent project
components are aligned, uniquely identifiable and reproducible at both the
atomic level (eg file) and at the higher kit levels.
Reasons for base lining include:

• A baseline supports ease of roll back
• A baseline improves CM managers ability to create change reports
etc
• A baseline supports creation of new parallel branches (e.g. dev
branches)
• A baseline supports troubleshooting and element comparison
• A baseline provides a stable bill of material for the build system
Build Management
The fundamental objective of the build management process is to deliver a

disciplined and automated build process.
Activities to consider include,
• Create automated build scripts (i.e. fetching from repository)

• Enforce base lining before all formal builds (support bill of
materials/traceability)
• Set up stable build machines
Packaging
Typically the packaging process (see next section) will be synonymous

with the build process i.e. the build process will do packaging automatically
after the build is complete.
Primary objectives of packaging are:
• Manageable (i.e. often a single zipped up file or exe)
• Reusable (i.e. Try to avoid need for rebuild)
• Secure (i.e. Packages should be free from malicious or accidental
modification)
Deployment
The configuration manager will typically be involved in the deployment

process. Primary considerations include:
• Ensuring deployment automated (reducing possibility for manual
errors).
• Promoting best practice concepts concept like promotion based
releases (opposed to environmental rebuilds).
97
• Ensuring releases are authorized and appropriate windows
selected for deployment.
• Providing streamlined rollback mechanism in case of problem.
Change Request Management
Change Request management can be described as management of

change/enhancement requests.
Typically the Configuration Manger should set up a repository to manage

these requests and support activities like status tracking, assignment etc.
Issue Tracking
Issue tracking is the formal tacking of problems/defects on your systems or

environments.
Typically the Configuration Manger should set up a repository to track

these problems as they occur, and track their status to eventual closure.
Note: Due to the similarities with production and test defect tracking, it is
not unusual to have a single tool to manage all.
Following process concepts are key to any SCM implementation:
1. Track change packages. Even though each file in a codeline has

its revision history, each revision in its history is only useful in the
context of a set of related files. The question "What other source
files were changed along with this particular change to foo.c?"
can't be answered unless you track change packages, or sets of
files related by a logical change. Change packages, not individual
file changes, are the visible manifestation of software
development. Some SCM systems track change packages for you;
if yours doesn't, write an interface that does.
2. Track change package propagations. One clear benefit of tracking

change packages is that it becomes very easy to propagate logical
changes (e.g., bug fixes) from one codeline branch to another.
However, it's not enough to simply propagate change packages
across branches; you must keep track of which change packages
have been propagated, which propagations are pending, and
which codeline branches are likely donors or recipients of
propagations. Otherwise you'll never be able to answer the
question "Is the fix for bug X in the release Y codeline?" Again,
some SCM systems track change package propagations for you,
whereas with others you'll have to write your own interface to do it.
98
Ultimately, you should never have to resort to "diffing" files to
figure out if a change package has been propagated between
codelines.
3. Distinguish change requests from change packages. "What to do"

and "what was done" are different data entities. For example, a
bug report is a "what to do" entity and a bug fix is a "what was
done" entity. Your SCM process should distinguish between the
two, because in fact there can be a one-to-many relationship
between change requests and change packages.
4. Give everything an owner. Every process, policy, document,

product, component, codeline, branch, and task in your SCM
system should have an owner. Owners give life to these entities by
representing them; an entity with an owner can grow and mature.
Ownerless entities are like obstacles in an ant trail - the ants
simply march around them as if they weren't there.
5. Use living documents. The policies and procedures you implement

should be described in living documents; that is, your process
documentation should be as readily available and as subject to
update as your managed source code. Documents that aren't
accessible are useless; documents that aren't updateable are
nearly so. Process documents should be accessible from all of
your development environments: at your own workstation, at
someone else's workstation, and from your machine at home. And
process documents should be easily updateable, and updates
should be immediately available.
99
100
UNIT 07: PROJECT CONTROL
Once a project is running it is important that the project manager keeps control.
This is achieved by regular reporting of issues, risks, progress and constant
checking of the business case to ensure that the expected benefits will be
delivered and are still valid. All proposed changes should be assessed, logged and
appropriate action taken. A project that is not controlled is out of control.
Session 1: Change control
What is Change control?
1.1 Introduction
Change control is method for implementing only changes that are worth
pursuing, and for preventing unnecessary or overly costly changes from
derailing the project.
Change control – Software project management, 4th edition, Bob Hughes

& Mike Cotterell : P 207 – 209
Change control is essentially an agreement between the project team and

the managers that are responsible for decision-making on the project to
evaluate the impact of a change before implementing it. Many changes
that initially sound like good ideas will get thrown out once the true cost of
the change is known. The potential benefit of the change is written down,
and the project manager works with the team to estimate the potential
impact that the change will have on the project. This gives the organization
all of the information necessary to do a real cost-benefit analysis. If the
benefit of the change is worth the cost, the project manager updates the
plan to reflect the new estimates. Otherwise, the change is thrown out and
the team continues with the original plan.
101
Establish a Change Control Board
The most important part of change control is a change control board

(CCB). There are certain people in the organization who have the power to
change the scope of the project. Usually there is a senior manager or
decision-maker who has the authority to make sweeping changes at will;
sometimes there are several people in this position. For change control to
be effective, these people must be part of the CCB.
In addition, the CCB should contain people from the project team:
• The project manager
• An important stakeholder or user (or someone who understands

and advocates their perspective)
• Someone who understands the effort involved in making the

change (usually, this is a representative from the programming
team)
• Someone who understands the engineering decisions that the

team makes over the course of the project (a design team
member, requirements analyst or, if neither is available, a
programmer who participated in the design of the software)
• Someone who is familiar with the expected functionality of the

software and with the behavior being discussed for each individual
change (typically a tester)
This last person fulfills a very important role in the change control process.
Typically, this user is involved in the tracking of changes and defects in the
product. When a bug is reported, part of their job is to figure out whether it
is a defect (meaning that the software does not behave the way its
specification requires it to behave) or a change (meaning that the software
behaves as designed, but that this behavior is not what the users or
stakeholders need).
Change Control Process
Following table mentions a typical change control process.
Attribute Description
Purpose To control changes by evaluating their impact

before agreeing to implement them.
102
Summary The change control process ensures that the
impact of each change is evaluated before the
decision is made to implement that change. A
change is proposed by anyone evaluating the
software. A change control board (CCB), made
up of the decision-makers, project manager,
stakeholder or user representatives, and selected
team members, and evaluates the change. The
CCB either accepts or rejects the change.
Work Products Input

Issue report in the defect tracking system that
describes the change
Output
Modified issue report that reflects the impact of
the change and the decision on whether or not to
move forward with it
Entry Criteria A change has been discovered, and an issue

report that describes it has been entered into the
defect tracking system.
Basic Course of 1. A CCB member (typically a tester) who is

Events familiar with the expected functionality of the
software reads and understands the issue
report which describes the requested change.
2. The CCB member familiar with the change
meets with the project manager to explain its
scope and significance. Together, they identify
all project team members who will be impacted
by the change, and work with them to evaluate
its impact. The project manager updates the
issue report to reflect the result of that
evaluation.
3. At the next CCB meeting, the project manager
presents the scope and significance of the
change, along with its expected impact. The
CCB discusses the change, and performs a
cost-benefit analysis to determine if its benefits
are worth the cost. The CCB approves the
change.
4. The project manager updates the issue report
to indicate that the change has been approved,
and then updates the project plan to reflect the
change. The team members begin
implementing the change.
Alternative Paths 5. In step 1, if the CCB member does not

understand the change, it can be returned to
the submitter for further explanation. The
submitter may choose to either update the
103
issue report to clarify the change (in which
case the script returns to step 1) or drop it
entirely (in which case the change control
process ends).
6. In step 3, if the CCB determines that the
benefits of the change are not worth the cost,
they can reject it. The change control process
ends, and no changes are made to the project.
The project manager updates the issue report
to reflect the fact that it was rejected.
Exit Criteria The project plan has been updated to reflect the
impact of the change, and work to implement the
change has begun.
1.3 References
Change Control Process

http://www.vidbob.com/qa-info/change-control-process.html
Change Control vs. Change Management: Moving Beyond IT

http://www.itsmwatch.com/itil/article.php/11700_3367151_1
Session 2: Monitoring and reporting
What are the tools used to monitor and report the project changes?
2.1. Project monitoring and reporting changes
1. Change Request Form - This document is used to propose, assess

and approve changes.
2. Change Log - This document is used to record changes and change
actions associated with a project.
3. Issues Log - This document is used to record issues and assign an
owner with a plan to resolve them.
104
4. Risk Log - This document is used to record and grade risks with an
associated action plan to minimize them.
5. Progress Report - This document is used to communicate progress on
a regular basis to the stakeholders of a project.
6. Checkpoint Report - This document is used to provide a detailed report
of progress to date. It lists all completed products, products to be
completed during the next period, requested changes, issues,
deviations from the plan and a summary budget and timescale
position.
Session 3: Measurement and analysis of results
Why is measuring important in Change control?
3.1. Introduction
The purpose of Measurement and Analysis (MA) is to develop and sustain
a measurement capability that is used to support management information
needs.
The Measurement and Analysis process area involves the following:

1. Specifying the objectives of measurement and analysis such that they
are aligned with identified information needs and objectives
2. Specifying the measures, analysis techniques, and mechanism for
data collection, data storage, reporting, and feedback
3. Implementing the collection, storage, analysis, and reporting of the
data
4. Providing objective results that can be used in making informed
decisions, and taking appropriate corrective actions
The integration of measurement and analysis activities into the processes

of the project supports the following:
1. Objective planning and estimating
2. Tracking actual performance against established plans and objectives
3. Identifying and resolving process-related issues
4. Providing a basis for incorporating measurement into additional
processes in the future
105
The staff required to implement a measurement capability may or may not
be employed in a separate organization-wide program. Measurement
capability may be integrated into individual projects or other organizational
functions (e.g., quality assurance).
The initial focus for measurement activities is at the project level. However,
a measurement capability may prove useful for addressing organization-
and/or enterprise-wide information needs. To support this capability, the
measurement activities should support information needs at multiple levels
including the business, organizational unit, and project to minimize re-work
as the organization matures.
Projects may choose to store project-specific data and results in a project-

specific repository. When data are shared more widely across projects, the
data may reside in the organization’s measurement repository.
Measurement and analysis of the product components provided by

suppliers is essential for effective management of the quality and costs of
the project. It is possible, with careful management of supplier agreements,
to provide insight into the data that support supplier-performance analysis.
106
Session 4: Correction and recovery
When the project is not going well who do you call?
4.1. Introduction
Most software development organizations end up with a troubled or failing

project at some point. And there is any number of reasons for project
failure, including ill-defined or inappropriate requirements, poor project
planning and management, uncontrolled quality problems, or inaccurate
estimates.
Case study 1 - Replacing a Legacy System
Problem
A company wanted to replace its legacy core processing system with a

new solution. The organization felt that it was critical to retain the deep
domain knowledge of its staff while transitioning to new technologies. The
Vice President of Product Engineering wanted to ensure the new project
was on the right track and to support the organizational change.
Solution
Software correction & recovery company (SCRC) worked with the client to
build an integrated road map to remove obstacles and reduce risk. In the
initial phase, SCRC helped clarify the project scope, refine the architecture,
develop next-stage comprehensive estimation models, and identify
additional potential risks that might need to be mitigated. Further SCRC
also provided software engineering best practice training on estimation,
facilitated Java training, and provided extensive onsite software
engineering and technical coaching to team members.
With SCRC’s support, the client used a combination of estimation models

to create a more accurate estimate. This revealed that the project could not
provide the urgently needed expedited reporting functionality in a timely
manner. The client decided to charter a separate team to implement the
107
urgent functionality in the legacy system, while keeping the project team
focused on moving to the new technology.
SCRC continued to provide support and assistance to the project team in

numerous ways as the new technology project progressed. Major activities
and deliverables included:
• Architecture workshops to identify major technical questions or risk

and create an action plan to answer them.
• Identification of the software development lifecycle that would best
meet the needs of the project.
• Project training and management coaching as the team moved to
a more agile software development lifecycle.
• Requirements training and coaching as the team decomposed
business requirements into more detailed functional and non-
functional requirements.
• Assistance in prototyping a vertical slice of the system to evaluate
technical risk and answer requirements questions.
• Increment retrospectives to identify lessons learned and mark
incremental course corrections.
Result
SCRC’s early visibility into the issues with transition to a new

technology/platform and the related project estimate allowed the team
to achieve both the most urgent business goals and simultaneously
begin updating the legacy system. SCRC’s legacy lasts through today
as more legacy systems are converted, the opportunity for existing
team members to transition continues to pay loyalty dividends, and
additional SCRC training has been added to address specific needs
over time. SCRC’s vendor and technology agnostic best practice
approaches provided an ideal addition that did not require vendor or
technology changes to be effective, whether in the original project or
follow-on ones that continue to leverage the approaches.
Case study 2 - Jumpstarting Organizational Change
MSNBC wanted to take the organization to the next level of efficiency by

improving its software engineering practices. The Director of Technology
wanted to ensure his staff has input in process, while obtaining
independent 3rd party expertise and input on the highest leverage change
areas.
MSNBC is a leader in breaking news and original journalism. Its

engineering organization supports the needs of immediately breaking news
108
and builds the longer term infrastructure needed to support and expand the
functionality of the site.
Challenge
Upon becoming the Director of Technology at MSNBC, Travis McElfresh
saw an organization undergoing a significant transformation. During his
first year, the organization piloted a number of software engineering best
practices on MSNBC’s largest project including clearly defining the project
scope, engaging the user community early in the project, and actively
managing the feature set and schedule. As the project neared conclusion,
McElfresh felt that it was the perfect time to identify the next steps for
improving the organization.
McElfresh wanted to have an independent analysis of MSNBC’s software

development practices to sanity check his own analysis and expand upon
it. He also wanted to involve his staff via an independent 3rd party so that
he could be confident that he was receiving truly candid input from his
staff. Finally, in addition to observations about strengths and weaknesses
of MSNBC’s technical organization, McElfresh wanted specific, prioritized,
focused recommendations for detailed improvement initiatives and then
support for implementing the initiatives.
Solution
Construx conducted an Organizational Assessment and evaluated the
capabilities of MSNBC’s development organization. They produced a list of
strengths and weaknesses, prioritized by significance. Construx then
worked collaboratively with MSNBC staff to develop a prioritized set of
Improvement Recommendations—matched to MSNBC’s unique strengths,
weaknesses, and organizational culture—that would have a high likelihood
of successful adoption within MSNBC. Following the assessment, Construx
helped MSNBC staff to plan and implement organizational improvement
initiatives. The bulk of the planning occurred during a two-day off-site
planning workshop in which workshop participants assigned owners to
improvement initiatives, defined deliverables, and set specific time lines.
Over the course of the next 18 months, MSNBC reorganized its technology
team into three cross functional teams focused on different parts of its
business. Management and technical staff worked together to implement
numerous software engineering best practice changes including portfolio
management, project management, and improved quality practices.
Throughout this time MSNBC staff attended Construx's best practices
seminars to learn more about how to support organizational change.
Construx also provided support and coaching as MSNBC worked through
these changes.
In late 2006, Construx conducted a Health Check to review the changes

MSNBC had made, identify new focus areas, and provide
recommendations for continued improvement.
109
Result
During Construx's 2007 Health Check, one MSNBC staff commented,
"From fiscal year 2006 to fiscal year 2007, we more than doubled our
project production yield. We have made incredible strides as an
organization in one year." Another staff member commented, "All the
changes were positive ones that have been at least incremental adds to
the whole and at most revolutionary changes critical to success."
McElfresh commented:
“While getting a 2X or 3X return on product development yield is

certainly a remarkable and measurable result, I believe the
program has influenced the team in many other ways that typically
go unspoken. The mechanics of great teamwork are easy to talk
freely about but can be difficult to implement due to personal
biases, insecurities, team history and organization cultural
dynamics. You can watch what happens when a person becomes
self-aware of their strengths and weaknesses. Being empowered
with new knowledge can be energizing and give the necessary
confidence needed in knowing what needs to happen to lead to a
desired change.
“When that phenomenon happens at the team level, a whole

new sense of connectedness, empathy and support happens. The
team works together to identify what changes must happen in
order to ‘win’. Metaphorically, that may mean changing out some
of the team members; it may mean showing up to practice more
frequently and learning new skills. And while the team educates
itself, focuses on improvement, and observes change, they form a
connected and supportive bond. It’s not a mandate handed down
from management. It’s not an action happening to the team from
an external force (e.g. management, HR, execs, etc.). It’s
something the team drives. Having a team go through a self-critical
process, like what we did with Construx, has resulted in a
confident, competent team that now has the addiction and desire
to continue to improve their performance in all areas.”
110
Session 5: Standards of performance
How do we measure the success or failure of a software project?
5.1. Introduction
Software metric is a measure of some property of a piece of software or its

specifications.
Since quantitative methods have proved so powerful in the other sciences,

computer science practitioners and theoreticians have worked hard to
bring similar approaches to software development. Tom DeMarco once
stated, “You can’t control what you can't measure.”
• Metrics need to be linked to an organizational or project objective to

demonstrate if we are achieving what we committed.
• The metric needs to be integrated in the day by day workflow (as much
as possible) in order to avoid having time allocated just to collect data.
• There needs to be a verification that the chosen metrics are covering
different areas that will define if a project reaches the end with or
without success.
• Metrics are like words, they will truly make sense in a set that creates a
sentence, so as much as possible it is necessary to stay away from
over analyzing data provided by one metric.
• It is useless to use a metric that cannot be used to base or define
action plans.
• Target values need to be defined for metrics like performance, once in
order to take corrective actions, the team must be aware of the
expected minimum and upper limit value ranges.
Common software metrics include:

• Code coverage
• Cohesion
• Comment density
• Coupling
• Cyclomatic complexity
• Function point analysis
• Instruction path length
111
• Program load time
• Number of classes and interfaces
• Number of lines of customer requirements.
• Program size
• Robert Cecil Martin’s software package metrics
• Bugs per line of code
• Source lines of code
• Execution time
112

EEI6360 Study Guide

Uploaded by

Copyright:

Available Formats

You might also like

EEI6360 Study Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EEI6360 Study Guide

Uploaded by

Copyright:

Available Formats

Table of Contents

Unit 01: Process Concepts 3

Unit 02: Management Concepts 15

Unit 03: Project personnel and organization 31

Unit 04: Process implementation 59

Unit 05: Project planning 73

Unit 6: Software configuration management 85

Session 1: Software project management definition

Introduction to acronyms and definitions commonly used in Software Project

Software project management is a sub-discipline of project management in

Definition of a project and project management.

o PMI definition: A project is a temporary endeavor undertaken to

o What is project management?

1.2 Required Reading

What is a project - A Guide to the Project Management Body of Knowledge : P 5

Software projects versus other types of project - – Software project management,

What is project management - A Guide to the Project Management Body of

A Guide to the Project Management Body of Knowledge

Introduction to project phases and project life cycle

Project management exists in a broader context that includes program

o Project management context broadly covers the following,

2.2 Required Reading

What is project management context - A Guide to the Project Management

A Guide to the Project Management Body of Knowledge

Introduction to software engineering process infrastructure

Define Software engineering process infrastructure (e.g. personnel, tools,

Define modeling and specification of software processes

o The modeling of the software process refers to the definition of the

o Specific goals and benefits of modeling the software process are,

Ease of understanding and communication: requiring a process

o The software process basically consists of two interrelated processes: the

o Basic process modeling components

Agent or Actor: is an entity that executes a process.

3.2. Required Reading

Software development process:

Identify why software process need to be measured

• How well are we meeting schedules and budgets?

Understand different techniques used for process improvement

Process improvement is a series of actions taken to identify, analyze and

5.1.2. Business Process Improvement (BPI)

5.1.3. Business process reengineering (BPR)

5.1.4. Capability Maturity Model Integration (CMMI)

Purpose of Software review and review techniques

Quality analysis is defined as “Examination of the quality goals of a product

6.1.1. Software review

A software review is "A process or meeting during which a software

6.1.2. Software quality

6.1.3. Software metrics

Software metrics can be classified into three categories: product metrics,

Is a class of problem solving methods aimed at identifying the root causes

6.2. Required Reading

Software quality – Software project management, 4th edition, Bob Hughes

Software review: http://en.wikipedia.org/wiki/Software_review

Software quality: http://en.wikipedia.org/wiki/Software_quality

Software quality metrics overview:

Root cause analysis: http://en.wikipedia.org/wiki/Root_cause_analysis

Session 1: General project management