EEI6360 Study Guide
EEI6360 Study Guide
EEI6360 Study Guide
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.
1.1. Introduction
3
Managing stakeholders with differing needs and
expectations.
Managing identified requirements.
What is a project – Software project management, 4th edition, Bob Hughes & Mike
Cotterell : P 2
1.3 SAQ
Exercise 1.1 : Software project management, 4th edition, Bob Hughes & Mike
Cotterell : P 2
1.4 References
Software project management, 4th edition, Bob Hughes & Mike Cotterell
4
Session 2: Project management context
2.1. Introduction
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)
2.3 References
6
Session 3: Software development process
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.
7
Common roles is SW development
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.
9
Session 4: Measurement and analysis of software
processes
4.1. Introduction
Rationale behind measuring the software processes are driven by the need
to identify,
4.2 References
http://www.martinig.ch/ae/process.php?id=7
10
Session 5: Software engineering process improvement
(individual, team)
5.1. Introduction
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.
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)
6.1. Introduction
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.
13
6.1.4. Root cause analysis (RCA).
6.3. References
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.
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
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.
2.1. Introduction
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.3. References
17
Session 3: Project management roles
3.1. Introduction
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.
Test Designer
Decides what tests should be
automated vs. manual and
creates automations.
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.)
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.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.
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.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.
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.
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.
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:
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
27
Session 4: Enterprise/Organizational management
structure
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.
28
Session 5: Software management types (acquisition,
project, development, maintenance, risk)
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.
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.
5.3 References
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.
1.1. Introduction
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
32
Session 2: Formal/informal communication
2.1. Introduction
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.
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.2. Dispersed and virtual teams – Software project management, 4th edition,
Bob Hughes & Mike Cotterell : P 249 - 253
34
Session 3: Project staffing
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;
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
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?
Manage project team: Tools and techniques - A Guide to the Project Management
Body of Knowledge: P 217 – 219
36
To improve organizational performance via improving the
performance of individual contributors. Two key questions
should be posed:
37
Monitoring the scheme - ensuring it does not fall into disuse,
following up on training/job exchange etc. recommendations,
reminding managers of their responsibilities.
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
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.
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
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
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.
Always start on time; this respects those who showed up on time and
reminds late-comers that the scheduling is serious.
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.
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.)
If you have new attendees who are not used to your meetings, you might
review each ground rule.
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.
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.
41
In a round-table approach, quickly have each participant indicate how they
think the meeting is going.
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
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)
5.3. References
Managing meetings:
http://managementhelp.org/grp_skll/meetings/meetings.htm
42
Session 6: Building and motivating teams
6.1. Introduction
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'.
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.
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.
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 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:
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
46
fullest extent. At the same time work will become more meaningful and
challenging through self-motivation.
• exploitative-authoritative;
• benevolent-authoritative;
• consultative;
• participative.
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.
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".
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:
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.
49
More contemporary 'persuaders' used by advertising and marketing people
include:
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.
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.
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
Reference: http://www.accel-team.com/motivation/index.html
52
Session 7: Conflict resolution
7.1. Introduction
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:
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
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.
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.
• 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.
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;
• 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.
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.
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.
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.
• 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
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.
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.
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.
1.1. Introduction
59
associated products, e.g., project plans, design documents, code, test
cases, and user manuals."
60
Session 2: Life cycle models (agile, heavyweight,
waterfall, spiral, V-Model)
2.1. Introduction
61
The waterfall model – Software project management, 4th edition, Bob
Hughes & Mike Cotterell : P 75 – 76
2.3 References
http://en.wikipedia.org/wiki/Agile_software_development
http://ausweb.scu.edu.au/aw04/papers/edited/balbo/
http://en.wikipedia.org/wiki/Waterfall_software_development
http://en.wikipedia.org/wiki/Spiral_model
62
http://en.wikipedia.org/wiki/V_model
http://en.wikipedia.org/wiki/Rup
http://en.wikipedia.org/wiki/Microsoft_Solution_Framework
http://en.wikipedia.org/wiki/Extreme_programming
63
Session 3: Life cycle process models and standards
(IEEE, ISO)
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.
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)
4.1. Introduction
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.”
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:
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:
PSP has not been widely adopted, so there are fewer cases
available to draw from.
4.3 References
68
Session 5: Team process (model, definition,
organization, measurement, analysis, improvement)
5.1. Introduction
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.
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 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
6.1. Introduction
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.
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.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:
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
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.
1.1. Introduction
Creating a project plan is the first thing you should do when undertaking
any kind of project.
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:
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
74
Session 2: Work breakdown structure
2.1. Introduction
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.
76
2.2. References
77
Session 3: Effort estimation
3.1 Introduction
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.
3.3 References
79
Session 4: 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.
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
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:
82
The following figure shows an example of a Gantt chart created in
Microsoft Project 2003:
83
Session 6: Risk management
6.1. Introduction
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.
6.3 References
Risk Management
http://en.wikipedia.org/wiki/Risk_management
84
UNIT 6: SOFTWARE CONFIGURATION
MANAGEMENT
1.1. Introduction
85
1.2. Required Reading
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).
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.
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.
1.3 References
Revision control
http://en.wikipedia.org/wiki/Version_control
87
Session 2: Release management
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.
88
2.2 References
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
Mentioned below are some open source tools which have been seen to be
useful in a software configuration management environment
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/ )
90
Defect and Enhancement Tracking
JIRA (http://www.atlassian.com/software/jira/ )
TRAC (http://trac.edgewall.org )
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)
Cruise Control
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
KOSMOS - (http://labs.jboss.com/kosmos)
3.3. References
Software Configuration Management and Build Tools
http://www.laatuk.com/tools/SCM_tools.html
92
Session 4: Builds
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.
Builds are more manageable and less prone to problems when a few key
practices are observed:
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.
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
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.
• Identification of Artifacts
• Version Control
• Development Streaming (Branching)
95
• Base lining
• Build Management
• Packaging
• Deployment
• Change Request Management
• Issue Tracking
Identification of Artifacts
Version Control
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.
Build Management
Packaging
Deployment
97
• Ensuring releases are authorized and appropriate windows
selected for deployment.
• Providing streamlined rollback mechanism in case of problem.
Issue Tracking
Note: Due to the similarities with production and test defect tracking, it is
not unusual to have a single tool to manage all.
98
Ultimately, you should never have to resort to "diffing" files to
figure out if a change package has been propagated between
codelines.
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.
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.
101
Establish a Change Control Board
In addition, the CCB should contain people from the project team:
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).
Attribute Description
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.
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
What are the tools used to monitor and report the project changes?
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.
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.
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.
106
Session 4: Correction and recovery
4.1. Introduction
Problem
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.
107
urgent functionality in the legacy system, while keeping the project team
focused on moving to the new technology.
Result
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.
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.
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:
110
Session 5: Standards of performance
5.1. Introduction
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