UKF COLLEGE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CST 309 MANAGEMENT OF SOFTWARE SYSTEMS
MODULE 4
SYLLABUS
Software Project Management Risk management, Managing people, Teamwork. Project Planning, Software
pricing, Plan driven development, Project scheduling, Agile planning. Estimation techniques, COCOMO cost
modelling. Configuration management, Version management, System building, Change management, Release
management, Agile software management SCRUM framework. Kanban methodology and lean approaches.

SOFTWARE PROJECT MANAGEMENT

• Software project management is an essential part of software engineering.

• The success criteria for project management obviously vary from project to project
Goals
1. to deliver the software to the customer at the agreed time
2. to keep overall costs within budget
3. to deliver software that meets the customer’s expectations
4. to maintain a coherent and well functioning development team.
• Software engineering is different from other types of engineering in a no: of ways
1. The product is intangible.
2. Large software projects are often “one off” projects.
3. Software processes are variable and organization specific.
• Factors that affect how software projects are managed are:
1. Company size
2. Software customers
3. Software size
4. Software type
5. Organizational culture
6. Software development processes

PROJECT MANAGEMENT ACTIVITIES

1. Project planning
• Project managers are → responsible for planning, estimating, and scheduling project development and
assigning people to tasks.
2. Risk management →
• Project managers have to assess the risks that may affect a project, monitor these risks, and take action when
problems arise.
3. People management
• Project managers are responsible → for managing a team of people.
• They have to choose people for their team and establish ways of working that lead to effective team
performance.
4. 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.
 5. 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.
• It usually includes cost and schedule estimates

RISK MANAGEMENT

• Risk management is one of the most important jobs for a project manager.
• Risk management involves anticipating risks that might affect the project schedule or the quality of the software
being developed, and then taking action to avoid these risks.
• Risks can be categorized according to type of risk (technical, organizational)
1. Project risks affect the project schedule or resources.
• An example of a project risk is the loss of an experienced system architect.
2. Product risks affect the quality or performance of the software being developed.
• Example of a product risk is the failure of a purchased component to perform as expected.
3. Business risks affect the organization developing or procuring the software.
• For example, a competitor introducing a new product is a business risk.

• For large projects, you should record the results of the risk analysis in a risk register
• For small projects, formal risk recording may not be required, but the project manager should be aware of
them.

1. Risk Identification

o Risk identification is the first stage of the risk management process.

o You should identify possible project, product, and business risks.
o Identify the risks that could pose a major threat to the software engineering process, the software being
developed, or the development organization.
o Risk identification may be a team process in which a team gets together to brainstorm possible risks.
o As a starting point for risk identification, a checklist of different types of risk may be used.

6 types of risk

1. Estimation risks arise from the management estimates → of the resources required to build the system.
2. Organizational risks → arise from the organizational environment where the software is being developed.
3. People risks → are associated with the people in the development team.
4. Requirements risks → come from changes to the customer requirements
5. Technology risks come from the software or hardware →technologies that are used to develop the system.
6. Tools risks → come from the software tools and other support software used to develop the system.

2. Risk Analysis

• Consider each identified risk and make a judgment about the probability and seriousness of that risk.
• It is not possible to make precise, numeric assessment of the probability and seriousness of each risk.
• You should assign the risk to one of a number of bands:
1. The probability of the risk as insignificant, low, moderate, high, or very high.
2. The effects of the risk as
• catastrophic (threaten the survival of the project),
• serious (would cause major delays),
• tolerable (delays are within allowed contingency), or
• insignificant.
• You may then tabulate the results of this analysis process using a table ordered according to the seriousness
of the risk.

3. Risk Planning

• The risk planning process develops strategies to manage the key risks.
• For each risk, take actions that minimize the project risk.
• Collect information while monitoring the project so that emerging problems can be detected before they
become serious.
• In risk planning, you have to ask “what if” questions that consider both individual risks, combinations of risks,
and external factors
1. What if several engineers are ill at the same time?
2. What if an economic downturn leads to budget cuts of 20% for the project?
3. What if the only expert on that open source software leaves?
4. What if the company that supplies and maintains software components goes out of business?
5. What if the customer fails to deliver the revised requirements as predicted?

Risk management strategies fall into 3 categories:

1. Avoidance strategies --- Following these strategies → means that the probability that the risk will arise is
reduced.
2. Minimization strategies → Following these strategies means that the impact of the risk is reduced.
3. Contingency plans → Following these strategies means that you are prepared for the worst and have a
strategy in place to deal with it.

4. Risk Monitoring

• Risk monitoring is the process of checking that your assumptions about the product, process, and business
risks have not changed.
• You should regularly assess each of the identified risks to decide whether or not that risk is becoming more or
less probable.
•
• You should also think about whether or not the effects of the risk have changed.
•
• You should monitor risks regularly at all stages in a project.
•
• At every management review, you should consider and discuss each of the key risks separately.
•
• You should decide if the risk is more or less likely to arise and if the seriousness and
 consequences of the risk have changed.

MANAGING PEOPLE

• The people working in a software organization are its greatest assets.

• It is expensive to recruit and retain good people.
• Software managers have to ensure that the engineers working on a project are as productive as possible.
• Software engineers often have strong technical skills but may lack the softer skills that enable them to motivate
and lead a project development team
• As a project manager, you should be aware of the potential problems of people management and should try to
develop people management skills.

Motivating People:

• As a project manager, you need to motivate the people who work with you so that they will contribute to
the best of their abilities.
• In practice, motivation means organizing work and its environment to encourage people to work as
effectively as possible.
• To provide this encouragement, you should understand a little about what motivates people.
• People are motivated by satisfying their needs
• These needs are arranged in a series of levels, as shown in Figure.

 The lower levels represent fundamental needs for food, sleep, and so on
 Safety need represent the need to feel secure in an environment.
 Social need is concerned with the need to feel part of a social grouping.
 Esteem need represents the need to feel respected by others.

1. To satisfy social needs,

 you need to give people time to meet their coworkers and provide places for them to meet.
 This is relatively easy when all of the members of a development team work in the same place.
 Social networking systems and teleconferencing can be used for remote communications.

2. To satisfy esteem needs,

 you need to show people that they are valued by the organization.
 Public recognition of achievements is a simple and effective way of doing this.
 TEAMWORK

• As it is impossible for everyone in a large group to work together on a single problem, large teams are usually
split into a number of smaller groups.
• Each group is responsible for developing part of the overall system.
• The best size for a software engineering group is 4 to 6 members
• They should never have more than 12 members.
• When groups are small, communication problems are reduced.
• Putting together a group that has the right balance of technical skills, experience, and personalities is a critical
management task.

3 factors that have the biggest effect on team working are:

1. The people in the group (Selecting group members)
2. The way the group is organized (Group organizations)
3. Technical and managerial communications (Group communications)

1. Selecting Group Members:

• A manager or team leader’s job is to create a cohesive group and organize that group so that they work
effectively.
• This task involves selecting a group with the right balance of technical skills and personalities.
• People who are motivated by the work are likely to be the strongest technically.
• People who are interaction oriented help facilitate communications within the group.
• The project manager has to control the group so that individual goals do not take precedence over
organizational and group objectives.

2. Group Organization

• The way a group is organized affects the group’s decisions, the ways information is exchanged, and the
interactions between the development group and external project stakeholders.
• Project managers are often responsible for selecting the people in the organization
• Getting the best possible people in this process is very important as poor selection decisions may be a serious
risk to the project.

3. Group Communications:

• It is absolutely essential that group members communicate effectively and efficiently with each other and with
other project stakeholders.
1. Group size As a group gets bigger, it → gets harder for members to communicate effectively.
• The number of one way communication links is n * (n −1), where n is the group size.
2. Group structure → People in informally structured groups communicate more effectively than people in
groups with a formal, hierarchical structure.
3. Group composition →
• People with the same personality may clash, and, as a result, communications can be inhibited.
4. The physical work environment → The organization of the workplace is a major factor in facilitating or
inhibiting communications.
5. The available communication channels → There are many different forms of communication—face to face,
email messages, formal documents, telephone, and technologies such as social networking and wikis.
 PROJECT PLANNING

Project planning involves

• break down the work into parts
• assign them to project team members,
• anticipate problems that might arise, and
• prepare tentative solutions to those problems.

The project plan, which is created at the start of a project and updated as the project progresses, is used to
show how the work will be done and to assess progress on the project.

Planning stages

• At the proposal stage, when you are bidding for a contract to develop or provide a software system.
• You need a plan at this stage to help you decide if you have the resources to complete the work and to work
out the price that you should quote to a customer.
• During the project startup phase, when you have to plan who will work on the project, how the project will be
broken down into increments, how resources will be allocated across your company, and so on.

SOFTWARE PRICING

• The price of a software system developed for a customer is simply the cost of development plus profit for the
developer.
• When calculating a price, you take broader organizational, economic, political, and business considerations
into account .
• You need to think about organizational concerns, the risks associated with the project, and the type of contract
that will be used
 Pricing to win

• It means that a company has some idea of the price that the customer expects to pay and makes a bid for the
contract based on the customer’s expected price.
• This may seem unethical but it does have advantages for both the customer and the system provider

PLAN DRIVEN DEVELOPMENT

• Plan-driven or plan-based development is an approach to software engineering where the development process
is planned in detail.
• A project plan is created that
• records the work to be done,
• who will do it,
• the development schedule, and
• the work products.

 Plan-driven development is the “traditional” way of managing large software development projects
 Managers use the plan to support project decision making and as a way of measuring progress.
 The problem with plan-driven development is that early decisions have to be revised because of changes to
the environments in which the software is developed and used.

Project Plans

 Introduction: Briefly describes the objectives of the project and sets out the constraints
 Project organization: Describes the way in which the development team is organized, the people involved,
and their roles in the team.
 Risk analysis: Describes possible project risks and the risk reduction strategies that are proposed.
 Hardware and software resource requirements: Specifies the hardware and software required to carry out
the development. If hardware has to be purchased, estimates of the prices and the delivery schedule may be
included.
 Work breakdown: Sets out the breakdown of the project into activities and identifies the inputs to and the
outputs from each project activity.
 Project schedule: Shows the dependencies between activities, the estimated time required to reach each
milestone, and the allocation of people to activities.
 Monitoring and reporting mechanisms: Defines the management reports that should be produced, when
these should be produced, and the project monitoring mechanisms to be used.

Planning Process

• Project planning is an iterative process that starts when you create an initial project plan during the project
startup phase.
• Plan changes are inevitable.
• As more information about the system and the project team becomes available during the project, you should
regularly revise the plan to reflect requirements, schedule, and risk changes.
Risk Mitigation

• If there are serious problems with the development work that are likely to lead to significant delays, you need
to initiate risk mitigation actions to reduce the risks of project failure.
• In conjunction with these actions, you also have to re-plan the project.
• A new schedule of when work should be completed also has to be established and agreed to with the customer.

PROJECT SCHEDULING

 Project scheduling is the process of deciding how the work in a project will be organized as separate tasks,
and when and how these tasks will be executed.
 You estimate the calendar time needed to complete each task and the effort required, and you suggest who
will work on the tasks that have been identified.
 You also have to estimate the hardware and software resources that are needed to complete each task.

Project Scheduling Activities

 Scheduling in plan-driven projects involves breaking down the total work involved in a project into separate
tasks and estimating the time required to complete each task.

Schedule Presentation

• Project schedules may simply be documented in a table or spreadsheet showing the tasks, estimated effort,
duration, and task dependencies.

Two types of visualization are commonly used:

• Calendar-based bar charts show who is responsible for each activity, the expected elapsed time, and when
the activity is scheduled to begin and end. Bar charts are also called Gantt charts, after their inventor, Henry
Gantt
• Activity networks show the dependencies between the different activities making up a project.

Milestones and deliverables:

• Milestone is a logical end to a stage of the project where the progress of the work can be reviewed.
• Each milestone should be documented by a brief report (often simply an email) that summarizes the work
done and whether or not the work has been completed as planned.
• Some activities create project deliverables—outputs that are delivered to the software customer
• Usually, the deliverables that are required are specified in the project contract, and the customer’s view of the
 project’s progress depends on these deliverables.
• Milestones and deliverables are not the same thing.
• Milestones are short reports that are used for progress reporting,
• Deliverables are more substantial project outputs

AGILE PLANNING

 Agile methods of software development are iterative approaches where the software is developed and
delivered to customers in increments.
 Unlike plan-driven approaches, the functionality of these increments is not planned in advance but is decided
during the development.

Stages:

1. Release planning, which looks ahead for several months and decides on the features that should be included
in a release of a system. Release planning involves selecting and refining the stories that will reflect the features
to be implemented in a release of a system and the order in which the stories should be implemented. The
customer has to be involved in this process.
2. Iteration planning, which has a shorter term outlook and focuses on planning the next increment of a
system. This usually represents 2 to 4 weeks of work for the team.

Approaches:

Story Based Planning:

• The basis of the planning game is a set of user stories that cover all of the functionality to be included in the
final system.
• The team members read and discuss the stories and rank them based on the amount of time they think it will
take to implement the story.

Agile Planning Difficulties

• A major difficulty in agile planning is that it relies on customer involvement and availability.
• This involvement can be difficult to arrange, as customer representatives have to prioritize other work

Agile Planning Applicability:

• Agile planning works well with small, stable development teams that can get together and discuss the stories
to be implemented. However, where teams are large and/or geographically distributed, or when team
membership changes frequently, it is practically impossible for everyone to be involved in the collaborative
planning that is essential for agile project management.
 ESTIMATION TECHNIQUES

• Two types of techniques can be used for making estimates:

• Experience based techniques:
• Algorithmic cost modeling

Experience based techniques:

• Experience-based techniques rely on the manager’s experience of past projects and the actual effort expended
in these projects
• Typically, you identify the deliverables to be produced in a project and the different software components or
systems that are to be developed.
• You document these in a spreadsheet, estimate them individually, and compute the total effort required.
• It usually helps to get a group of people involved in the effort estimation and to ask each member of the group
to explain their estimate.
• The difficulty with experience-based techniques is that a new software project may not have much in common
with previous projects.
• Software development changes very quickly, and a project will often use unfamiliar techniques such as web
services, application system configuration, or HTML5.
• If you have not worked with these techniques, your previous experience may not help you to estimate the
effort required, making it more difficult to produce accurate costs and schedule estimates

Algorithmic cost Modelling:

• Algorithmic cost modeling uses a mathematical formula to predict project costs based on estimates of the
project size, the type of software being developed, and other team, process, and product factors.
• Effort = A * Size ^B * M
• A: a constant factor, which depends on local organizational practices and the type of software that is developed.
• Size: an assessment of the code size of the software
• B: represents the complexity of the software and usually lies between 1 and 1.5.
• M: product and development attributes

Two key problems:

1. It is practically impossible to estimate Size accurately at an early stage in a project, when only the
specification is available.
2. Estimates vary from one person to another, depending on their background and experience of the type of
system that is being developed.

COCOMO COST MODELLING

• The best known algorithmic cost modeling technique

• This model was derived by collecting data from a large number of software projects of different sizes.
• These data were analyzed to discover the formulas that were the best fit to the observations.
• COCOMO II is a freely available model that is supported with opensource tools.
• COCOMO II was developed from earlier COCOMO (Constructive Cost Modeling) cost estimation models.
 The submodels that are part of the COCOMO II model are:
1. An application composition model
2. An early design model
3. A reuse model
4. A post architecture model

1. The application composition model

 The application composition model was introduced into COCOMO II to support the estimation of effort
required for prototyping projects

• PM: the effort estimate in person months.

• NAP: the total number of application points in the delivered system.
• %reuse: an estimate of the amount of reused code in the development.
• PROD: the application point productivity.

2. The early design model

This model may be used during the early stages of a project, before a detailed architectural design for the system
is available.

 PERS: personnel capability

 PREX: personnel experience
 RCPX: product reliability and complexity
 RUSE: reuse required
 PDIF: platform difficulty
 SCED: schedule
 FSIL: support facilities

3. The reuse model

 To estimate the effort required to integrate reusable or generated code.
 ESLOC: the equivalent number of lines of new source code.
 ASLOC: an estimate of the number of lines of code in the reused components that have to be changed.


 AT: the percentage of reused code that can be modified automatically.
 AAM: an Adaptation Adjustment Multiplier that reflects the additional effort required to reuse
 components.

4. The post architecture level

 It is used when you have an initial architectural design for the system.

CONFIGURATION MANAGEMENT

• Configuration management (CM) is concerned with the policies, processes, and tools for managing changing
software systems.

• The configuration management of a software system product involves four closely related activities:
1. Version control: This involves keeping track of the multiple versions of system components and ensuring that
changes made to components by different developers do not interfere with each other.
2. System building: This is the process of assembling program components, data, and libraries, then compiling and
linking these to create an executable system.
3. Change management: This involves keeping track of requests for changes to delivered software from customers
and developers, working out the costs and impact of making these changes, and deciding if and when the changes
should be implemented.
4. Release management: This involves preparing software for external release and keeping track of the system
versions that have been released for customer use.

Multi – version system

• For large systems, there is never just one “working” version of a system; there are always several versions of
the system at different stages of development.
• Several teams may be involved in the development of different system versions.
 VERSION MANAGEMENT

• Version management is the process of keeping track of different versions of software components and the
systems in which these components are used.
• It also involves ensuring that changes made by different developers to these versions do not interfere with each
other.
• In other words, version management is the process of managing code lines and baselines.

Code lines and baselines

 A codeline is a sequence of versions of source code, with later versions in the sequence derived from earlier versions.
 Code lines normally apply to components of systems so that there are different versions of each component.
 A baseline is a definition of a specific system.
 The baseline identifies the libraries used, configuration files, and other system information

Version Control Systems

Version control (VC) systems identify, store, and control access to the different versions of components.
1. Centralized systems, where a single master repository maintains all versions of the software components that are
being developed.
2. Distributed systems, where multiple versions of the component repository exist at the same time. Git is a widely
used example of a distributed VC system.

Key features of Version Control Systems

1. Version and release identification:

• Managed versions of a component are assigned unique identifiers when they are submitted to the system.
• These identifiers allow different versions of the same component to be managed, without changing the
component name.
2. Change history recording:
• The VC system keeps records of the changes that have been made to create a new version of a component
from an earlier version.
3. Independent development:
• Different developers may be working on the same component at the same time.
• The version control system keeps track of components that have been checked out for editing and ensures that
changes made to a component by different developers do not interfere.
4. Project support: A version control system may support the development of several projects, which share
components.
5. Storage management: Rather than maintain separate copies of all versions of a component, the version control
system may use efficient mechanisms to ensure that duplicate copies of identical files are not maintained.

SYSTEM BUILDING

• System building is the process of creating a complete, executable system by compiling and linking the
system components, external libraries, configuration files, and other information.
• System building involves assembling a large amount of information about the software and its operating
environment
Build System functionality

 Build script generation: The build system should analyze the program that is being built, identify dependent
components, and automatically generate a build script
 Version control system integration: The build system should check out the required versions of components
from the version control system.
 Minimal recompilation: The build system should work out what source code needs to be recompiled and set
up compilations if required.
 Executable system creation: The build system should link the compiled object code files with each other and
with other required files
 Test automation: Some build systems can automatically run automated tests using test automation tools such
as JUnit.
 Reporting: The build system should provide reports about the success or failure of the build and the tests that
have been run.
 Documentation generation: The build system may be able to generate release notes about the build and
system help pages.

System Platforms:

 The development system , which includes development tools such as compilers and source code editors.
 The build server : This is used to build definitive, executable versions of the system.
 The target environment , which is the platform on which the system executes.
 This may be the same type of computer that is used for the development and build systems.

CHANGE MANAGEMENT

 Organizational needs and requirements change during the lifetime of a system, bugs have to be repaired, and
systems have to adapt to changes in their environment.
 Change management is intended to ensure that the most urgent and cost- effective changes are prioritized.
 Change management is the process of analyzing the costs and benefits of proposed changes, approving those
changes that are cost-effective, and tracking which components in the system have been changed

Factors in change analysis:

 The consequences of not making the change:
 When assessing a change request, you have to consider what will happen if the change is not implemented.
  If the change is associated with a reported system failure, the seriousness of failure has to be taken into account

Benefits of the change

 Will the change benefit many users of the system, or will it only benefit the change proposer?
 The number of users affected by the change: If only a few users are affected, then the change may be assigned
a low priority.
 The costs of making the change: If making the change affects many system components and/or takes a lot of
time to implement, then the change may be rejected
 The product release cycle: If a new version of the software has just been released to customers, it may make
sense to delay implementation of the change until the next planned release.

RELEASE MANAGEMENT

• A system release is a version of a software system that is distributed to customers.

• For mass-market software, it is usually possible to identify two types of release:
• major releases, which deliver significant new functionality, and
• minor releases, which repair bugs and fix customer problems that have been reported.

Release components:
 configuration files defining how the release should be configured for particular installations;
■ data files, such as files of error messages in different languages, that are needed successful system operation;
■ an installation program that is used to help install the system on target hardware;
■ electronic and paper documentation describing the system;
■ packaging and associated publicity that have been designed for that release.

Factors affecting system release planning:

KANBAN METHODOLOGY

• KAN is a word for “card” in Japanese.

• BAN is a word for “signal”.
• KANBAN means signal card.
• Each card contains a small amount of work, say a story to develop and some clarifying testable examples.
• The kanban method consists of principles, practices, kanban boards and kanban cards.
KANBAN BOARD

• The heart of the Kanban method is the Kanban board

• Phases of the project are divided into columns.
• The kanban board represents the overall project and is usually broken up into three columns: to do, in progress
and done.

KANBAN CARD

• Each kanban card is filled with information related to that task, such as its name and a short description.
• Task will be assigned to the team member, who is responsible for executing the task by the deadline.

KANBAN COLUMNS

• Columns reside on the board are a way to break up the different stages in the project workflow.
• Tasks progress from one column to the next, until the task is completed, so its an indicator of current status of
a task .

KANBAN SWIMLANES

• The key component that will enable you to visualize the whole process on a single board
• Horizontal lanes help to separate different work items, activities, teams, services, etc.

Kanban Board/ Card/Columns

 LEAN APPROACHES

7 Lean Development Principles

The seven Lean principles are:
• Eliminate waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole
1. Eliminate waste

• Unnecessary code or functionality

• Starting more than can be completed:
• Delay in the software development process:
• Unclear or constantly changing requirements:
• Slow or ineffective communication:
• Partially done work:
• Defects and quality issues

2. Build quality in

• Every team wants to build quality into their work

3. Defer Commitment

• It does not mean that teams should be flaky or irresponsible about their decision making.

4. Respect for people

• It applies to every aspect of the way Lean teams operate, from how they communicate, handle conflict, hire

5. Deliver fast

• Every team wants to deliver fast, to put value into the hands of the customer as quickly as possible.

6. Optimize the whole

• Suboptimization is a serious issue in software development.

7. Create knowledge