CS 335 Software Engineering

Lecture Day 3 20211108

Lecturer: Ireneus Kagashe, Ph.D.

2021/2022
BCEITIII

CS 335 1
 Software Maintenance
• The IEEE Standard for Software Maintenance (IEEE 1219) gave the definition for
software maintenance as “The process of modifying a software system or
component after delivery to correct faults, improves performance or other
attributes, or adapt to a changed environment.”
• The IEEE/EIA 12207 Standard defines maintenance as modification to code and
associated documentation due to a problem or the need for improvement.

CS 335 2
 Maintenance Process
• Maintenance process/cycle:
• modification requests are logged and tracked,
• the impact of proposed changes are determined,
• code and other software artifacts are modified,
• testing is conducted, and
• a new version of the software product is released.
• Maintainers can learn from the developer´s knowledge of the software

CS 335 3
 Need for Maintenance
• Maintenance must be performed in order to:
• Correct faults.
• Improve the design.
• Implement enhancements.
• Interface with other systems.
• Adapt programs so that different hardware, software, system features, and
telecommunications facilities can be used.
• Migrate legacy software.
• Retire software

CS 335 4
 Tasks of a Maintainer
• The maintainer does the following functions:
• Maintain control over the software´s day-to-day functions.
• Maintain control over software modification.
• Perfecting existing functions.
• Preventing software performance from degrading to unacceptable levels.

CS 335 5
 Maintenance Costs
• Maintenance consumes a major share of software life cycle financial resources.
• Studies and surveys have shown that “over 80% of the maintenance effort is used
for non-corrective actions.

CS 335 6
 Categories of Maintenance
• Maintenance can be categorized into the following:
• Corrective maintenance
• Adaptive maintenance
• Perfective maintenance
• Preventive maintenance

CS 335 7
 Categories of Maintenance
• Corrective maintenance:
• Reactive modification of a software product performed after delivery to correct
discovered problems.
• Adaptive maintenance:
• Modification of a software product performed after delivery to keep a software
product usable in a changed or changing environment.
• Perfective maintenance:
• Modification of a software product after delivery to improve performance or
maintainability.
• Preventive maintenance:
• Modification of a software product after delivery to detect and correct latent
faults in the software product before they become effective faults.
CS 335 8
 Categories of Maintenance
• The distribution of maintenance activities:

CS 335 9
 Key to Effective Maintenance
• The key to effective maintenance lies in development.
• Higher quality less (corrective) maintenance
• Anticipating changes less (adaptive and perfective) maintenance
• Better tuning to user needs less (perfective) maintenance
• Less code less maintenance

CS 335 10
 Major causes of maintenance problems
• Some of the major factors which causes problem in maintenance are:
• Unstructured code
• Insufficient domain knowledge
• Insufficient documentation

CS 335 11
Unit III: Software Project Management

CS 335 12
Unit III: Software Project Management

CS 335 13
What is a project?
• Definition:
• A project is a temporary, unique and progressive attempt or endeavor made to
produce some kind of a tangible or intangible result (a unique product, service,
benefit, competitive advantage, etc.).
• A project is a planned activity that involves non-routine tasks and has a clearly
defined beginning and an end.
• It is planned to achieve a particular aim.
• The aim of a project is to attain its objective and then terminate.

CS 335 14
What is a project?
• Project characteristics:
• Temporary – a project has a definite beginning and a definite end.
• Deliverables – a project creates unique deliverables, i.e. products, services, or
results.
• Progressive Elaboration – a project is always developed in steps and
continuing by increments

CS 335 15
What is a project?
Projects vs. Operations
• Operations are ongoing and repetitive, while projects are temporary and unique.
• A project is a means of organizing some activities that cannot be addressed within
the normal operational limits.

CS 335 16
Software Project Management (SPM)
• SPM is concerned with activities involved in ensuring that software is delivered
on time and on schedule and in accordance with the requirements of the
organizations developing and procuring the software.

CS 335 17
Needs for and Goals of SPM
• Needs for SPM
• SPM is needed because software development is always subject to budget and
schedule constraints that are set by the organization developing the software.
• Goals of SPM
• to deliver the software to the customer at the agreed time;
• to keep overall costs within budget;
• to deliver software that meets the customer’s expectations;
• to maintain a coherent and well-functioning development team.

CS 335 18
SPM vs Other Types of PM
• 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 from previous projects. Therefore,
difficult to anticipate problems.
• Software processes are variable and organization specific.
• We cannot reliably predict when a particular software process is likely to lead to
development problems because different companies use quite different
software development processes.

CS 335 19
 SPM Activities
• Project planning
• Planning, estimating and scheduling project development and assigning people to
tasks.
• Risk management
• Assess the risks that may affect a project, monitor these risks, and take action when
problems arise.
• People management
• Choose work teams and establish ways of working that lead to effective team
performance.
• Reporting
• Reporting on the progress of a project to customers and to the managers of the
company developing the software.

CS 335 20
 SPM Activities
• Proposal writing
• Writing a proposal (describing the objectives of the project and how it will be carried
out) to win a contract to carry out an item of work.

CS 335 21
Project Planning
• Project planning involves:
• breaking down the work into parts
• assign the work to project team members
• anticipate problems that might arise and
• prepare tentative solutions to those problems.
• The project plan is used to communicate how the work will be done to the
project team and customers, and to help assess progress on the project.
• A project plan is created to record the work to be done, who will do it, the
development schedule, and the work products.

CS 335 22
Planning Stages
• At the proposal stage, during bidding for a contract to develop or provide a
software system. Will be re-worked later
• During the project startup phase, 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, etc.
• Periodically throughout the project, when you modify your plan due to the
experience gained and information from monitoring the progress of the work.

CS 335 23
Pros and Cons of Planning
• Advantages of planning:
• Early planning allows organizational issues (e.g. availability of staff, other
projects, etc.) to be taken into account before the project starts.
• Disadvantages of planning:
• Many early decisions have to be revised because of changes to the environment
in which the software is to be developed and used.

CS 335 24
Project Plan Sections
• Introduction: Briefly describes the objectives of the project and sets out the
constraints (e.g., budget, time) that affect the management of the project.
• Project organization: How the development team is organized, the people
involved, and their roles in the team.
• Risk analysis: Describes possible project risks, the likelihood of these risks arising,
and the risk reduction strategies (to be discussed) that are proposed.
• Hardware and software resource requirements: Specifies the hardware and
support 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. (To be
discussed later)

CS 335 25
Project Plan Sections …
• Project schedule: Shows the dependencies between activities, the estimated
time required to reach each milestone, and the allocation of people to activities.
(Scheduling will be discussed later)
• Monitoring and reporting mechanisms: Defines the management reports that
should be produced, when to be produced, and the project monitoring
mechanisms to be used.

CS 335 26
The planning process
• Project planning is an iterative process.
• Plan changes are unavoidable due to:
• Availability of more info about the system and project team
• Requirement, schedule, and risk changes
• Changing business goals

CS 335 27
The planning process

• Constraints are like required delivery date, staff available, budget, available tools, etc.
• Milestones are points in the schedule against which you can assess progress, for example, the
handover of the system for testing. They identify when one or multiple groups of activities have
been completed thus implying that a notable point has been reached in the project.
• Deliverables are tangible work products that are delivered to the customer, for example, a
requirements document for the system.
CS 335 28
Project scheduling
• 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.
• Scheduling process:
• Estimate the calendar time needed to complete each task, the effort required
and who will work on the tasks that have been identified.
• Estimate the resources needed to complete each task.
• Tasks duration: 1 week – 8 weeks.
• Task longer than 8 weeks should be split into subtasks for project planning and
scheduling.
• An initial project schedule is usually created during the project startup phase.

CS 335 29
Project scheduling suggested steps
• Identify all the major activities that need to be carried out to complete the
project.
• Break down each activity into tasks (smallest unit of work activities).
• Determine the dependency among different tasks.
• Establish the estimates for the time durations necessary to complete the tasks.
• Represent the information in the form of an activity network.
• Determine task starting and ending dates from the activity network.
• Determine the critical path. A critical path is a chain of tasks that determines the
duration of the project. (More on this later)
• Allocate resources to tasks.

CS 335 30
Project scheduling

CS 335 31
 Project scheduling – Building Blocks
• Activities
• Project activities are the basic planning elements for project scheduling.
• Each activity has:
• a duration in calendar days or months;
• an effort estimate showing the number of person-days or person-months to
complete the work; a deadline by which the activity should be complete; and
• a defined endpoint, which might be a document, the holding of a review meeting,
the successful execution of all tests, or the like.

CS 335 32
 Project scheduling – Building Blocks
• Milestones and deliverables
• Milestones
• These are logical ends to stages of the project where the progress of the work can be
reviewed.
• Milestones may be associated with a single task or with groups of related activities.
• Deliverables
• These are work products that are delivered to the customer. E.g., a requirements
document.
• Duration
• Time taken (in days) to complete project tasks/activities.

CS 335 33
Project scheduling – Building Blocks
• Efforts
• These are person-days taken to work on project tasks/activities.
• Sum of the individual number of days each person spends in the project.
• (Note: person-time is the time in ”time” required for one person to complete a
task.)
• Task
• Smallest unit of work activities.
• Obtained through breakdown of activities systematically by using the work
breakdown structure technique
• Task Dependencies
• If T2 is dependent on task T1 it means that task T1 has to be completed before
T2 starts.

CS 335 34
Work Breakdown Structure (WBS)
• Definition:
• “A deliverable-oriented hierarchical decomposition of the work to be executed
by the project team to accomplish the project objectives and create the required
deliverables”
• “A work breakdown structure defines all the work or activities a project needs to
accomplish, organized into multiple levels, and displayed graphically.”   
• Used to hierarchically decompose a set of activities into sub activities.
• In the hierarchy of WBS, tasks are the lowest levels
• In most projects three levels are enough.

CS 335 35
Work Breakdown Structure (WBS)
• Two types of WBS:
• Deliverable-based WBS
• Phase-Based WBS
• The most common and preferred approach is the Deliverable-Based approach.
• The main difference between the two approaches are the Elements identified in
the first Level of the WBS.

CS 335 36
Deliverable-Based Work Breakdown Structure
• A Deliverable-Based WBS demonstrates the relationship between the project
deliverables (i.e., products, services or results) and the scope (i.e., work to be
executed).
• WBS describes deliverables and not activities hence nouns are used. E.g. “car
body” (a deliverable), not “welding steel” (an activity).
• In deliverable-based WBS, the Level 1 Elements are summary deliverable
descriptions.
• The Level 2 Elements in each Leg of the WBS are all the unique deliverables
required to create the respective Level 1 deliverable.
• The following Figure is an example of a Deliverable-Based WBS for the
construction of a house.

CS 335 37
Deliverable-Based Work Breakdown Structure

CS 335 38
Deliverable-Based Work Breakdown Structure
• Bicycle WBS Example.
• The numbers indicates
duration or resources to
complete each task
• “100% rule” - the sum of the
work at each “child” level
must be 100% of the work at
the “parent” level

CS 335 39
Phase-Based Work Breakdown Structure
• In phase-based WBS the Level 1 elements are typical phases of a project.
• The Level 2 Elements are the unique deliverables in each phase.
• Regardless of the type of WBS, the lower Level Elements are all deliverables.
• Notice that Elements in different Legs have the same name.
• A Phase-Based WBS requires work associated with multiple elements be divided
into the work unique to each Level 1 Element.
• A WBS Dictionary is created to describe the work in each Element.
• The following figure shows a typical phase-based WBS for the construction of a
house

CS 335 40
Phase-Based Work Breakdown Structure

CS 335 41
Work Breakdown Structure (WBS) - Formats
• WBS can be represented in two formats:
• Outline (indented format)
• Graphical Tree (Organizational Chart)

CS 335 42
Work Breakdown Structure (WBS) - Formats
Numbering in WBS
• WBS uses a decimal numbering system

CS 335 43
WBS – Graphical/Chart Format Example

CS 335 44
WBS – Outline Format Example

CS 335 45
Creating a WBS: Steps
• GATHER CRITICAL DOCUMENTS
• Identify content containing project deliverables, such as Scope Statement and
Project Management Plan (PMP).
• IDENTIFY KEY TEAM MEMBERS
• Identify the appropriate project team members.
• Analyze the documents and identify the deliverables.
• DEFINE LEVEL 1 ELEMENTS
• Define the Level 1 Elements i.e. summary deliverable descriptions that must
capture 100% of the project scope.
• Verify 100% of scope is captured (the 100% Rule).

CS 335 46
Creating a WBS: Steps
• DECOMPOSE (BREAKDOWN) ELEMENTS
• Break the Level 1 deliverables into unique lower Level deliverables.
• Continue breaking down the work until the work covered in each Element is
managed by a single individual or organization.
• Ensure that all Elements are mutually exclusive.
• Ask the question, would any additional decomposition make the project more
manageable? If the answer is “no”, the WBS is done.
• CREATE WBS DICTIONARY
• The WBS Dictionary is a narrative description of the work covered in each
Element in the WBS.
• The lowest Level Elements in the WBS are called Work Packages.
• The descriptions should include information such as, boundaries, milestones,
risks, owner, costs, etc.
CS 335 47
Creating a WBS: Steps
• CREATE GANTT CHART SCHEDULE
• Decompose the Work Packages to activities as appropriate.
• Export or enter the WBS into a Gantt chart for further scheduling and project
tracking.

CS 335 48