CCS126

SE2 MIDTERM REVIEWER

PROF. JOEMEN BARRIOS| 2ND SEMESTER | SOFTWARE ENGINEERING 2
________________

RAPID SOFTWARE DEVELOPMENT

Rapid development and delivery is now often the most important requirement
for software systems
* Businesses operate in a fast changing requirement and it is practically
impossible to produce a set of stable software requirements
* Software has to evolve quickly to reflect changing business needs.
* Plan-driven development is essential for some types of system but does not meet
these business needs.
* Agile development methods emerged in the late 1990s whose aim was to radically
reduce the delivery time for working software systems

AGILE DEVELOPMENT
* Program specification, design and implementation are interleaved
* The system is developed as a series of versions or increments with stakeholders
involved in version specification and evaluation
* Frequent delivery of new versions for evaluation
* Extensive tool support (e.g. automated testing tools) used to support
development.
* Minimal documentation – focus on working code

PLAN-DRIVEN AND AGILE DEVELOPMENT

PLAN DRIVEN AND AGILE DEVELOPMENT

PLAN DRIVEN
* A plan-driven approach to software engineering is based around separate
development stages with the outputs to be produced at each of these stages planned
in advance.
* Not necessarily waterfall model – plan-driven, incremental development is
possible
* Iteration occurs within activities.

AGILE DEVELOPMENT
* Specification, design, implementation and testing are inter-leaved and the
outputs from the development process are decided through a process of negotiation
during the software development process.

AGILE METHODS

* Dissatisfaction with the overheads involved in software design methods of the

1980s and 1990s led to the creation of agile methods. These methods:
* Focus on the code rather than the design
 * Are based on an iterative approach to software development
* Are intended to deliver working software quickly and evolve this quickly to
meet changing requirements.
* The aim of agile methods is to reduce overheads in the software process (e.g. by
limiting documentation) and to be able to respond quickly to changing requirements
without excessive rework.

AGILE MANIFESTO
* We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan T
* That is, while there is value in the items on the right, we value the items on
the left more.

THE PRINCIPLES OF AGILE METHOD

PRINCIPLE
DESCRIPTION
CUSTOMER INVOLVEMENT
Customers should be closely involved throughout the development process.
Their role is to provide and prioritize new system requirements and to evaluate
the iterations of the system.
INCREMENTAL DELIVERY
The software is developed in increments with the customer specifying the
requirements to be included in each increment.
PEOPLE NOT PROCESS
The skills of the development team should be recognized and exploited. Team
members should be left to develop their own ways of working without prescriptive
processes.
EMBRACE CHANGE
Expect the system requirements to change and so design the system to
accommodate these changes.
MAINTAIN SIMPLICITY
Focus on simplicity in both the software being developed and in the
development process. Wherever possible, actively work to eliminate complexity from
the system.

AGILE METHOD APPLICABILITY

* Product development where a software company is developing a small or medium-

sized product for sale.
* Virtually all software products and apps are now developed using an agile
approach
* Custom system development within an organization, where there is a clear
commitment from the customer to become involved in the development process and
where there are few external rules and regulations that affect the software.
AGILE DEVELOPMENT TECHNIQUES

EXTREME PROGRAMMING
* A very influential agile method, developed in the late 1990s, that introduced a
range of agile development techniques.
* Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
* New versions may be built several times per day;
* Increments are delivered to customers every 2 weeks;
* All tests must be run for every build and the build is only accepted if tests
run successfully.
THE EXTREME PROGRAMMING RELEASE CYCLE

EXTREME PROGRAMMING PRACTICE (A)

PRINCIPLE OR PRACTICE
DESCRIPTION
INCREMENTAL PLANNING
Requirements are recorded on story cards and the stories to be included in a
release are determined by the time available and their relative priority. The
developers break these stories into development ‘Tasks’. See Figures 3.5 and 3.6.
SMALL RELEASES
The minimal useful set of functionality that provides business value is
developed first. Releases of the system are frequent and incrementally add
functionality to the first release.
SIMPLE DESIGN
Enough design is carried out to meet the current requirements and no more.
TEST-FIRST DEVELOPMENT
An automated unit test framework is used to write tests for a new piece of
functionality before that functionality itself is implemented.
REFACTORING
All developers are expected to refactor the code continuously as soon as
possible code improvements are found. This keeps the code simple and maintainable.

EXTREME PROGRAMMING PRACTICE (B)

PAIR PROGRAMMING
Developers work in pairs, checking each other’s work and providing the
support to always do a good job.
COLLECTIVE OWNERSHIP
The pairs of developers work on all areas of the system, so that no islands
of expertise develop and all the developers take responsibility for all of the
code. Anyone can change anything.
CONTINUOUS INTEGRATION
As soon as the work on a task is complete, it is integrated into the whole
system. After any such integration, all the unit tests in the system must pass.
SUSTAINABLE PACE
Large amounts of overtime are not considered acceptable as the net effect is
often to reduce code quality and medium term productivity
ON-SITE CUSTOMER
A representative of the end-user of the system (the customer) should be
available full time for the use of the XP team. In an extreme programming process,
the customer is a member of the development team and is responsible for bringing
system requirements to the team for implementation.

XP AND AGILE PRINCIPLES

* Incremental development is supported through small, frequent system releases.
* Customer involvement means full-time customer engagement with the team.
* People not process through pair programming, collective ownership and a process
that avoids long working hours.
* Change supported through regular system releases.
* Maintaining simplicity through constant refactoring of code.

INFLUENTIAL XP PRACTICES
* Extreme programming has a technical focus and is not easy to integrate with
management practice in most organizations.
Consequently, while agile development uses practices from XP, the method as
originally defined is not widely used.
* Key practices
* User stories for specification
* Refactoring
* Test-first development
* Pair programming

USER STORIES FOR REQUIREMENT

* In XP, a customer or user is part of the XP team and is responsible for making
decisions on requirements.
* User requirements are expressed as user stories or scenarios.
* These are written on cards and the development team break them down into
implementation tasks. These tasks are the basis of schedule and cost estimates.
* The customer chooses the stories for inclusion in the next release based on their
priorities and the schedule estimates.

TEST FIRST DEVELOPMENT

* Testing is central to XP and XP has developed an approach where the program is

tested after every change has been made.
* XP testing features:
* Test-first development.
* Incremental test development from scenarios.
* User involvement in test development and validation.
* Automated test harnesses are used to run all component tests each time that a
new release is built.

TEST DRIVEN DEVELOPMENT

* Writing tests before code clarifies the requirements to be implemented.
* Tests are written as programs rather than data so that they can be executed
automatically. The test includes a check that it has executed correctly.
* Usually relies on a testing framework such as Junit.
* All previous and new tests are run automatically when new functionality is added,
thus checking that the new functionality has not introduced errors.

CUSTOMER INVOLVEMENT
* The role of the customer in the testing process is to help develop acceptance
tests for the stories that are to be implemented in the next release of the system.
* The customer who is part of the team writes tests as development proceeds. All
new code is therefore validated to ensure that it is what the customer needs.
* However, people adopting the customer role have limited time available and so
cannot work full-time with the development team. They may feel that providing the
requirements was enough of a contribution and so may be reluctant to get involved
in the testing process.

TEST AUTOMATION
* Test automation means that tests are written as executable components before the
task is implemented
* These testing components should be stand-alone, should simulate the submission
of input to be tested and should check that the result meets the output
specification. An automated test framework (e.g. Junit) is a system that makes it
easy to write executable tests and submit a set of tests for execution.
* As testing is automated, there is always a set of tests that can be quickly and
easily executed
* Whenever any functionality is added to the system, the tests can be run and
problems that the new code has introduced can be caught immediately.

PROBLEMS WITH TEST FIRST DEVELOPMENT

* Programmers prefer programming to testing and sometimes they take short cuts when
writing tests. For example, they may write incomplete tests that do not check for
all possible exceptions that may occur.
* Some tests can be very difficult to write incrementally. For example, in a
complex user interface, it is often difficult to write unit tests for the code that
implements the ‘display logic’ and workflow between screens.
* It is difficult to judge the completeness of a set of tests. Although you may
have a lot of system tests, your test set may not provide complete coverage.

PAIR PROGRAMMING
* Pair programming involves programmers working in pairs, developing code together.
* This helps develop common ownership of code and spreads knowledge across the
team.
* It serves as an informal review process as each line of code is looked at by more
than 1 person.
* It encourages refactoring as the whole team can benefit from improving the system
code.

* In pair programming, programmers sit together at the same computer to develop the
software.
* Pairs are created dynamically so that all team members work with each other
during the development process.
* The sharing of knowledge that happens during pair programming is very important
as it reduces the overall risks to a project when team members leave.
* Pair programming is not necessarily inefficient and there is some evidence that
suggests that a pair working together is more efficient than 2 programmers working
separately.

AGILE PROJECT MANAGEMENT

* The principal responsibility of software project managers is to manage the
project so that the software is delivered on time and within the planned budget for
the project.
* The standard approach to project management is plan-driven. Managers draw up a
plan for the project showing what should be delivered, when it should be delivered
and who will work on the development of the project deliverables.
* Agile project management requires a different approach, which is adapted to
incremental development and the practices used in agile methods.

SCRUM

* Scrum is an agile method that focuses on managing iterative development rather

than specific agile practices.
* There are three phases in Scrum.
* The initial phase is an outline planning phase where you establish the general
objectives for the project and design the software architecture.
* This is followed by a series of sprint cycles, where each cycle develops an
increment of the system.
* The project closure phase wraps up the project, completes required
documentation such as system help frames and user manuals and assesses the lessons
learned from the project.

SCRUM TERMINOLOGY (A)

SCRUM TERM
DEFINITION
DEVELOPMENT TEAM
A self-organizing group of software developers, which should be no more than
7 people. They are responsible for developing the software and other essential
project documents.
POTENTIALLY SHIPPABLE PRODUCT INCREMENT
The software increment that is delivered from a sprint. The idea is that this
should be ‘potentially shippable’ which means that it is in a finished state and no
further work, such as testing, is needed to incorporate it into the final product.
In practice, this is not always achievable.
PRODUCT BACKLOG
This is a list of ‘to do’ items which the Scrum team must tackle. They may be
feature definitions for the software, software requirements, user stories or
descriptions of supplementary tasks that are needed, such as architecture
definition or user documentation.
PRODUCT OWNER
An individual (or possibly a small group) whose job is to identify product
features or requirements, prioritize these for development and continuously review
the product backlog to ensure that the project continues to meet critical business
needs. The Product Owner can be a customer but might also be a product manager in a
software company or other stakeholder representative.
SCRUM TERMINOLOGY (B)

SCRUM TERM
DEFINITION
SCRUM
A daily meeting of the Scrum team that reviews progress and prioritizes work
to be done that day. Ideally, this should be a short face-to-face meeting that
includes the whole team.
SCRUM MASTER
The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she is
responsible for interfacing with the rest of the company and for ensuring that the
Scrum team is not diverted by outside interference. The Scrum developers are
adamant that the ScrumMaster should not be thought of as a project manager. Others,
however, may not always find it easy to see the difference.
SPRINT
A development iteration. Sprints are usually 2-4 weeks long.
VELOCITY
An estimate of how much product backlog effort that a team can cover in a
single sprint. Understanding a team’s velocity helps them estimate what can be
covered in a sprint and provides a basis for measuring improving performance.

SCRUM SPRINT CYCLE

SCRUM SPRINT CYCLE

* Sprints are fixed length, normally 2–4 weeks.

* The starting point for planning is the product backlog, which is the list of work
to be done on the project.
* The selection phase involves all of the project team who work with the customer
to select the features and functionality from the product backlog to be developed
during the sprint.

THE SPRINT CYCLE

* Once these are agreed, the team organize themselves to develop the software.
* During this stage the team is isolated from the customer and the organization,
with all communications channelled through the so-called ‘Scrum master’.
* The role of the Scrum master is to protect the development team from external
distractions.
* At the end of the sprint, the work done is reviewed and presented to
stakeholders. The next sprint cycle then begins.
TEAMWORK IN SCRUM
* The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the
backlog of work to be done, records decisions, measures progress against the
backlog and communicates with customers and management outside of the team.
* The whole team attends short daily meetings (Scrums) where all team members share
information, describe their progress since the last meeting, problems that have
arisen and what is planned for the following day.
* This means that everyone on the team knows what is going on and, if problems
arise, can re-plan short-term work to cope with them.

SCRUM BENEFITS
* The product is broken down into a set of manageable and understandable chunks.
* Unstable requirements do not hold up progress.
* The whole team have visibility of everything and consequently team communication
is improved.
* Customers see on-time delivery of increments and gain feedback on how the product
works.
* Trust between customers and developers is established and a positive culture is
created in which everyone expects the project to succeed.

DISTRIBUTED SCRUM

PRACTICAL PROBLEM WITH AGILE METHOD

* The informality of agile development is incompatible with the legal approach to
contract definition that is commonly used in large companies.
* Agile methods are most appropriate for new software development rather than
software maintenance. Yet the majority of software costs in large companies come
from maintaining their existing software systems.
* Agile methods are designed for small co-located teams yet much software
development now involves worldwide distributed teams.

CONTRACTUAL ISSUE
* Most software contracts for custom systems are based around a specification,
which sets out what has to be implemented by the system developer for the system
customer.
* However, this precludes interleaving specification and development as is the norm
in agile development.
* A contract that pays for developer time rather than functionality is required.
* However, this is seen as a high risk my many legal departments because what
has to be delivered cannot be guaranteed.

AGILE METHODS AND SOFTWARE MAINTENANCE

* Most organizations spend more on maintaining existing software than they do on
new software development. So, if agile methods are to be successful, they have to
support maintenance as well as original development.
* Two key issues:
* Are systems that are developed using an agile approach maintainable, given the
emphasis in the development process of minimizing formal documentation?
* Can agile methods be used effectively for evolving a system in response to
customer change requests?
* Problems may arise if original development team cannot be maintained.

AGILE MAINTENANCE
* Key problems are:
* Lack of product documentation
* Keeping customers involved in the development process
* Maintaining the continuity of the development team
* Agile development relies on the development team knowing and understanding what
has to be done.
* For long-lifetime systems, this is a real problem as the original developers will
not always work on the system.

AGILE AND PLAN DRIVEN METHODS

* Most projects include elements of plan-driven and agile processes. Deciding on
the balance depends on:
* Is it important to have a very detailed specification and design before moving
to implementation? If so, you probably need to use a plan-driven approach.
* Is an incremental delivery strategy, where you deliver the software to
customers and get rapid feedback from them, realistic? If so, consider using agile
methods.
* How large is the system that is being developed? Agile methods are most
effective when the system can be developed with a small co-located team who can
communicate informally. This may not be possible for large systems that require
larger development teams so a plan-driven approach may have to be used.

AGILE PRINCIPLES AND ORGANIZATIONAL PRACTICE

PRINCIPLE
PRACTICE
CUSTOMER INVOLVEMENT
This depends on having a customer who is willing and able to spend time with
the development team and who can represent all system stakeholders. Often, customer
representatives have other demands on their time and cannot play a full part in the
software development.
Where there are external stakeholders, such as regulators, it is difficult to
represent their views to the agile team.
EMBRACE CHANGE
Prioritizing changes can be extremely difficult, especially in systems for
which there are many stakeholders. Typically, each stakeholder gives different
priorities to different changes.
INCREMENTAL DELIVERY
Rapid iterations and short-term planning for development does not always fit
in with the longer-term planning cycles of business planning and marketing.
Marketing managers may need to know what product features several months in advance
to prepare an effective marketing campaign.
MAINTAIN SIMPLICITY
Under pressure from delivery schedules, team members may not have time to
carry out desirable system simplifications.
PEOPLE NOT PROCES
Individual team members may not have suitable personalities for the intense
involvement that is typical of agile methods, and therefore may not interact well
with other team members.
AGILE AND PLAN-BASED FACTORS

SYSTEM ISSUES
* How large is the system being developed?
* Agile methods are most effective a relatively small co-located team who can
communicate informally.
* What type of system is being developed?
* Systems that require a lot of analysis before implementation need a fairly
detailed design to carry out this analysis.
* What is the expected system lifetime?
* Long-lifetime systems require documentation to communicate the intentions of
the system developers to the support team.
* Is the system subject to external regulation?
* If a system is regulated you will probably be required to produce detailed
documentation as part of the system safety case.

PEOPLE AND TEAMS

* How good are the designers and programmers in the development team?
* It is sometimes argued that agile methods require higher skill levels than
plan-based approaches in which programmers simply translate a detailed design into
code.
* How is the development team organized?
* Design documents may be required if the team is distributed.
* What support technologies are available?
* IDE support for visualisation and program analysis is essential if design
documentation is not available.

ORGANIZATIONAL ISSUES
* Traditional engineering organizations have a culture of plan-based development,
as this is the norm in engineering.
* Is it standard organizational practice to develop a detailed system
specification?
* Will customer representatives be available to provide feedback of system
increments?
* Can informal agile development fit into the organizational culture of detailed
documentation?

IBM AGILITY AT SCALE MODEL

MULTI-TEAM SCRUM
Role replication
* Each team has a Product Owner for their work component and ScrumMaster.
Product architects
* Each team chooses a product architect and these architects collaborate to design
and evolve the overall system architecture.
Release alignment
* The dates of product releases from each team are aligned so that a demonstrable
and complete system is produced.
Scrum of Scrums
* There is a daily Scrum of Scrums where representatives from each team meet to
discuss progress and plan work to be done.

KEY POINTS
* Agile methods are incremental development methods that focus on rapid software
development, frequent releases of the software, reducing process overheads by
minimizing documentation and producing high-quality code.
* Agile development practices include
* User stories for system specification
* Frequent releases of the software,
* Continuous software improvement
* Test-first development
* Customer participation in the development team.
* Scrum is an agile method that provides a project management framework.
* It is centred round a set of sprints, which are fixed time periods when a
system increment is developed.
* Many practical development methods are a mixture of plan-based and agile
development.
* Scaling agile methods for large systems is difficult.
* Large systems need up-front design and some documentation and organizational
practice may conflict with the informality of agile approaches.

PROJECT MANAGEMENT

SOFTWARE PROJECT MANAGEMENT

* Concerned with activities involved in ensuring that software is delivered on time
and on schedule and in accordance with the requirements of the organisations
developing and procuring the software.
* Project management is needed because software development is always subject to
budget and schedule constraints that are set by the organisation developing the
software.

SUCCESS CRITERIA
* Deliver the software to the customer at the agreed time.
* Keep overall costs within budget.
* Deliver software that meets the customer’s expectations.
* Maintain a coherent and well-functioning development team.
SOFTWARE MANAGEMENT DISTINCTIONS

The product is intangible.

* Software cannot be seen or touched. Software project managers cannot see progress
by simply looking at the artefact that is being constructed.
Many software projects are 'one-off' projects.
* Large software projects are usually different in some ways from previous
projects. Even managers who have lots of previous experience may find it difficult
to anticipate problems.
Software processes are variable and organization specific.
* We still cannot reliably predict when a particular software process is likely to
lead to development problems.

FACTORS INFLUENCING PROJECT MANAGEMENT

* Company size
* Software customers
* Software size
* Software type
* Organizational culture
* Software development processes
* These factors mean that project managers in different organizations may work in
quite different ways.

UNIVERSAL MANAGEMENT ACTIVITIES

Project planning
* Project managers are responsible for planning. estimating and scheduling project
development and assigning people to tasks.
* Covered in Chapter 23.
Risk management
* Project managers assess the risks that may affect a project, monitor these risks
and take action when problems arise.
People management
* Project managers have to choose people for their team and establish ways of
working that leads to effective team performance.

MANAGEMENT ACTIVITIES

Reporting
* Project managers are usually responsible for reporting on the progress of a
project to customers and to the managers of the company developing the software.
Proposal writing
* The first stage in a software project may involve writing a proposal to win a
contract to carry out an item of work. The proposal describes the objectives of the
project and how it will be carried out.

RISK MANAGEMENT
* Risk management is concerned with identifying risks and drawing up plans to
minimise their effect on a project.
* Software risk management is important because of the inherent uncertainties in
software development.
* These uncertainties stem from loosely defined requirements, requirements
changes due to changes in customer needs, difficulties in estimating the time and
resources required for software development, and differences in individual skills.
* You have to anticipate risks, understand the impact of these risks on the
project, the product and the business, and take steps to avoid these risks.

RISK CLASSIFICATION

There are two dimensions of risk classification

* The type of risk (technical, organizational, ..)
* what is affected by the risk:
* Project risks affect schedule or resources;
* Product risks affect the quality or performance of the software being
developed;
* Business risks affect the organisation developing or procuring the software.

EXAMPLE OF PROJECT, PRODUCT, AND BUSINESS RISKS

Risk
Affects
Description
Staff turnover
Project
Experienced staff will leave the project before it is finished.
Management change
Project
There will be a change of organizational management with different
priorities.
Hardware unavailability
Project
Hardware that is essential for the project will not be delivered on schedule.
Requirements change
Project and product
There will be a larger number of changes to the requirements than
anticipated.
Specification delays
Project and product
Specifications of essential interfaces are not available on schedule.
Size underestimate
Project and product
The size of the system has been underestimated.
CASE tool underperformance
Product
CASE tools, which support the project, do not perform as anticipated.
Technology change
Business
The underlying technology on which the system is built is superseded by new
technology.
Product competition
Business
A competitive product is marketed before the system is completed.

THE RISK MANAGEMENT PROCESS

Risk identification
* Identify project, product and business risks;
Risk analysis
* Assess the likelihood and consequences of these risks;
Risk planning
* Draw up plans to avoid or minimise the effects of the risk;
Risk monitoring
* Monitor the risks throughout the project;

RISK IDENTIFICATION
* May be a team activities or based on the individual project manager’s experience.
* A checklist of common risks may be used to identify risks in a project
* Technology risks.
* Organizational risks.
* People risks.
* Requirements risks.
* Estimation risks.
EXAMPLE OF DIFFERENT RISK TYPES

Risk type
Possible risks
Estimation
The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)
Organizational
The organization is restructured so that different management are responsible
for the project. (6)
Organizational financial problems force reductions in the project budget. (7)
People
It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Requirements
Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Technology
The database used in the system cannot process as many transactions per
second as expected. (1)
Reusable software components contain defects that mean they cannot be reused as
planned. (2)
Tools
The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)

RISK ANALYSIS
* Assess probability and seriousness of each risk.
* Probability may be very low, low, moderate, high or very high.
* Risk consequences might be catastrophic, serious, tolerable or insignificant.
RISK TYPES AND EXAMPLES

Risk
Probability
Effects
Organizational financial problems force reductions in the project budget (7).
Low
Catastrophic
It is impossible to recruit staff with the skills required for the project
(3).
High
Catastrophic
Key staff are ill at critical times in the project (4).
Moderate
Serious
Faults in reusable software components have to be repaired before these
components are reused. (2).
Moderate
Serious
Changes to requirements that require major design rework are proposed (10).
Moderate
Serious
The organization is restructured so that different management are responsible
for the project (6).
High
Serious
The database used in the system cannot process as many transactions per
second as expected (1).
Moderate
Serious

Risk
Probability
Effects
The time required to develop the software is underestimated (12).
High
Serious
Software tools cannot be integrated (9).
High
Tolerable
Customers fail to understand the impact of requirements changes (11).
Moderate
Tolerable
Required training for staff is not available (5).
Moderate
Tolerable
The rate of defect repair is underestimated (13).
Moderate
Tolerable
The size of the software is underestimated (14).
High
Tolerable
Code generated by code generation tools is inefficient (8).
Moderate
Insignificant
RISK PLANNING

* Consider each risk and develop a strategy to manage that risk.

Avoidance strategies
* The probability that the risk will arise is reduced;
Minimization strategies
* The impact of the risk on the project or product will be reduced;
Contingency plans
* If the risk arises, contingency plans are plans to deal with that risk;

WHAT IF QUESTION
* What if several engineers are ill at the same time?
* What if an economic downturn leads to budget cuts of 20% for the project?
* What if the performance of open-source software is inadequate and the only expert
on that open source software leaves?
* What if the company that supplies and maintains software components goes out of
business?
* What if the customer fails to deliver the revised requirements as predicted?

STRATEGIES TO RISK MANAGEMENT

Risk
Strategy
Organizational financial problems
Prepare a briefing document for senior management showing how the project is
making a very important contribution to the goals of the business and presenting
reasons why cuts to the project budget would not be cost-effective.
Recruitment problems
Alert customer to potential difficulties and the possibility of delays;
investigate buying-in components.
Staff illness
Reorganize team so that there is more overlap of work and people therefore
understand each other’s jobs.
Defective components
Replace potentially defective components with bought-in components of known
reliability.
Requirements changes
Derive traceability information to assess requirements change impact;
maximize information hiding in the design.
Organizational restructuring
Prepare a briefing document for senior management showing how the project is
making a very important contribution to the goals of the business.

Database performance
Investigate the possibility of buying a higher-performance database.
Underestimated development time
Investigate buying-in components; investigate use of a program generator.

RISK MONITORING
* Assess each identified risks regularly to decide whether or not it is becoming
less or more probable.
* Also assess whether the effects of the risk have changed.
* Each key risk should be discussed at management progress meetings.

RISK INDICATORS

Risk type
Potential indicators
Estimation
Failure to meet agreed schedule; failure to clear reported defects.
Organizational
Organizational gossip; lack of action by senior management.
People
Poor staff morale; poor relationships amongst team members; high staff
turnover.
Requirements
Many requirements change requests; customer complaints.
Technology
Late delivery of hardware or support software; many reported technology
problems.
Tools
Reluctance by team members to use tools; complaints about CASE tools; demands
for higher-powered workstations.

MANAGING PEOPLE
* People are an organisation’s most important assets.
* The tasks of a manager are essentially people-oriented. Unless there is some
understanding of people, management will be unsuccessful.
* Poor people management is an important contributor to project failure.

PEOPLE MANAGEMENT FACTOR

Consistency
* Team members should all be treated in a comparable way without favourites or
discrimination.
Respect
* Different team members have different skills and these differences should be
respected.
Inclusion
* Involve all team members and make sure that people’s views are considered.
Honesty
* You should always be honest about what is going well and what is going badly in a
project.

MOTIVATING PEOPLE
* An important role of a manager is to motivate the people working on a project.
* Motivation means organizing the work and the working environment to encourage
people to work effectively.
* If people are not motivated, they will not be interested in the work they are
doing. They will work slowly, be more likely to make mistakes and will not
contribute to the broader goals of the team or the organization.
* Motivation is a complex issue, but it appears that there are different types of
motivation based on:
* Basic needs (e.g. food, sleep, etc.);
* Personal needs (e.g. respect, self-esteem);
* Social needs (e.g. to be accepted as part of a group).
HUMAN NEEDS HIERARCHY

NEED SATISFACTION
* In software development groups, basic physiological and safety needs are not an
issue.
Social
* Provide communal facilities;
* Allow informal communications e.g. via social networking
Esteem
* Recognition of achievements;
Appropriate rewards.
Self-realization
* Training - people want to learn more;
* Responsibility.

COMMENTS ON CASE STUDY

* If you don’t sort out the problem of unacceptable work, the other group members
will become dissatisfied and feel that they are doing an unfair share of the work.
* Personal difficulties affect motivation because people can’t concentrate on their
work. They need time and support to resolve these issues, although you have to make
clear that they still have a responsibility to their employer.
* Alice gives Dorothy more design autonomy and organizes training courses in
software engineering that will give her more opportunities after her current
project has finished.

PERSONALITY TYPES
* The needs hierarchy is almost certainly an over-simplification of motivation in
practice.
* Motivation should also take into account different personality types:
* Task-oriented people, who are motivated by the work they do. In software
engineering.
* Interaction-oriented people, who are motivated by the presence and actions of co-
workers.
Self-oriented people, who are principally motivated by personal success and
recognition.

PERSONALITY TYPES
Task-oriented.
* The motivation for doing the work is the work itself;
Self-oriented.
* The work is a means to an end which is the achievement of individual goals - e.g.
to get rich, to play tennis, to travel etc.;
Interaction-oriented
* The principal motivation is the presence and actions of co-workers. People go to
work because they like to go to work.

MOTIVATION BALANCE

* Individual motivations are made up of elements of each class.

* The balance can change depending on personal circumstances and external events.
* However, people are not just motivated by personal factors but also by being part
of a group and culture.
* People go to work because they are motivated by the people that they work with.

TEAMWORK
* Most software engineering is a group activity
* The development schedule for most non-trivial software projects is such that
they cannot be completed by one person working alone.
* A good group is cohesive and has a team spirit. The people involved are motivated
by the success of the group as well as by their own personal goals.
* Group interaction is a key determinant of group performance.
* Flexibility in group composition is limited
* Managers must do the best they can with available people.

GROUP COHESIVENESS
* In a cohesive group, members consider the group to be more important than any
individual in it.
* The advantages of a cohesive group are:
* Group quality standards can be developed by the group members.
* Team members learn from each other and get to know each other’s work;
Inhibitions caused by ignorance are reduced.
* Knowledge is shared. Continuity can be maintained if a group member leaves.
* Refactoring and continual improvement is encouraged. Group members work
collectively to deliver high quality results and fix problems, irrespective of the
individuals who originally created the design or program.

THE EFFECTIVENESS OF A TEAM

The people in the group

* You need a mix of people in a project group as software development involves
diverse activities such as negotiating with clients, programming, testing and
documentation.
The group organization
* A group should be organized so that individuals can contribute to the best of
their abilities and tasks can be completed as expected.
Technical and managerial communications
* Good communications between group members, and between the software engineering
team and other project stakeholders, is essential.

SELECTING GROUP MEMBERS

* A manager or team leader’s job is to create a cohesive group and organize their
group so that they can work together effectively.
* This involves creating a group with the right balance of technical skills and
personalities, and organizing that group so that the members work together
effectively.
ASSEMBLING A TEAM
* May not be possible to appoint the ideal people to work on a project
* Project budget may not allow for the use of highly-paid staff;
* Staff with the appropriate experience may not be available;
* An organisation may wish to develop employee skills on a software project.
* Managers have to work within these constraints especially when there are
shortages of trained staff.

GROUP COMPOSITION
* Group composed of members who share the same motivation can be problematic
* Task-oriented - everyone wants to do their own thing;
* Self-oriented - everyone wants to be the boss;
* Interaction-oriented - too much chatting, not enough work.
* An effective group has a balance of all types.
* This can be difficult to achieve software engineers are often task-oriented.
* Interaction-oriented people are very important as they can detect and defuse
tensions that arise.

GROUP ORGANIZATION

* The way that a group is organized affects the decisions that are made by that
group, the ways that information is exchanged and the interactions between the
development group and external project stakeholders.
* Key questions include:
* Should the project manager be the technical leader of the group?
* Who will be involved in making critical technical decisions, and how will
these be made?
* How will interactions with external stakeholders and senior company management
be handled?
* How can groups integrate people who are not co-located?
* How can knowledge be shared across the group?

GROUP ORGANIZATION
* Small software engineering groups are usually organised informally without a
rigid structure.
* For large projects, there may be a hierarchical structure where different groups
are responsible for different sub-projects.
* Agile development is always based around an informal group on the principle that
formal structure inhibits information exchange

INFORMAL GROUPS
* The group acts as a whole and comes to a consensus on decisions affecting the
system.
* The group leader serves as the external interface of the group but does not
allocate specific work items.
Rather, work is discussed by the group as a whole and tasks are allocated according
to ability and experience.
This approach is successful for groups where all members are experienced and
competent.

GROUP COMMUNICATIONS
* Good communications are essential for effective group working.
* Information must be exchanged on the status of work, design decisions and changes
to previous decisions.
* Good communications also strengthens group cohesion as it promotes understanding.

GROUP COMMUNICATIONS
Group size
* The larger the group, the harder it is for people to communicate with other group
members.
Group structure
* Communication is better in informally structured groups than in hierarchically
structured groups.
Group composition
* Communication is better when there are different personality types in a group and
when groups are mixed rather than single sex.
The physical work environment
* Good workplace organisation can help encourage communications.

KEY POINTS
* Good project management is essential if software engineering projects are to be
developed on schedule and within budget.
* Software management is distinct from other engineering management. Software is
intangible. Projects may be novel or innovative with no body of experience to guide
their management. Software processes are not as mature as traditional engineering
processes.
* Risk management involves identifying and assessing project risks to establish the
probability that they will occur and the consequences for the project if that risk
does arise. You should make plans to avoid, manage or deal with likely risks if or
when they arise.
* People management involves choosing the right people to work on a project and
organizing the team and its working environment.
* People are motivated by interaction with other people, the recognition of
management and their peers, and by being given opportunities for personal
development.
* Software development groups should be fairly small and cohesive. The key factors
that influence the effectiveness of a group are the people in that group, the way
that it is organized and the communication between group members.
* Communications within a group are influenced by factors such as the status of
group members, the size of the group, the gender composition of the group,
personalities and available communication channels.