BCSE301L SOFTWARE
ENGINEERING
Dr.D.KAVITHA
SCOPE
VIT, CHENNAI
Introduction To Software Project Management
Planning, Scope, Work break-down structure, Milestones, Deliverables,
Cost and Estimates - (Human Resources, Time-scale, Costs), Risk
Management, RMMM Plan, CASE TOOLS, Agile Project Management,
Managing team dynamics and communication, Metrics and
Measurement.
Software Project Planning
• A Software Project is the complete methodology of
programming advancement from requirement gathering to
testing and support, completed by the execution procedures, in
a specified period to achieve intended software product.
Need of Software Project Management
The most significant is that the underlying technology changes
and advances so generally and rapidly that experience of one
element may not be connected to the other one. All such
business and ecological imperatives bring risk in software
development; hence, it is fundamental to manage software
projects efficiently.
Software Project Manager
• Software manager is responsible for planning and scheduling project
development. They manage the work to ensure that it is completed
to the required standard. They monitor the progress to check that the
event is on time and within budget. The project planning must
incorporate the major issues like size & cost estimation scheduling,
project monitoring, personnel selection evaluation & risk
management. To plan a successful software project, we must
understand:
• Scope of work to be completed
• Risk analysis
• The resources mandatory
• The project to be accomplished
• Record of being followed
• Software Project planning starts before technical work start. The
various steps of planning activities are:
The size is the crucial parameter for the estimation of other activities. Resources requirement are
required based on cost and development time. Project schedule may prove to be very useful for
controlling and monitoring the progress of the project. This is dependent on resources &
development time.
Work break-down structure
• Dividing complex projects to simpler and manageable tasks is the process
identified as Work Breakdown Structure (WBS).
• Usually, the project managers use this method for simplifying the project
execution. In WBS, much larger tasks are broken down to manageable
chunks of work. These chunks can be easily supervised and estimated.
• WBS is not restricted to a specific field when it comes to application. This
methodology can be used for any type of project management.
Following are a few reasons for creating a WBS in a project:
• Accurate and readable project organization.
• Accurate assignment of responsibilities to the project team.
• Indicates the project milestones and control points.
• Helps to estimate the cost, time and risk.
• Illustrate the project scope, so the stakeholders can have a better
understanding of the same.
Construction of a WBS
• Identifying the main deliverables of a project is the starting
point for deriving a work breakdown structure.
• This important step is usually done by the project managers and
the subject matter experts (SMEs) involved in the project. Once
this step is completed, the subject matter experts start breaking
down the high-level tasks into smaller chunks of work.
• In the process of breaking down the tasks, one can break them
down into different levels of detail. One can detail a high-level
task into ten sub-tasks while another can detail the same highlevel task into 20 sub-tasks.
• Therefore, there is no hard and fast rule on how you should breakdown a task
in WBS. Rather, the level of breakdown is a matter of the project type and the
management style followed for the project.
• In general, there are a few "rules" used for determining the smallest task
chunk. In "two weeks" rule, nothing is broken down smaller than two weeks
worth of work.
• This means, the smallest task of the WBS is at least two-week long. 8/80 is
another rule used when creating a WBS. This rule implies that no task should
be smaller than 8 hours of work and should not be larger than 80 hours of
work.
• One can use many forms to display their WBS. Some use tree structure to
illustrate the WBS, while others use lists and tables. Outlining is one of the
easiest ways of representing a WBS.
example is an outlined WBS:
There are many design goals for WBS. Some important goals are as follows:
•Giving visibility to important work efforts.
•Giving visibility to risky work efforts.
•Illustrate the correlation between the activities and deliverables.
•Show clear ownership by task leaders.
WBS Diagram
• In a WBS diagram, the project scope is graphically expressed. Usually the
diagram starts with a graphic object or a box at the top, which represents
the entire project. Then, there are sub-components under the box.
• These boxes represent the deliverables of the project. Under each
deliverable, there are sub-elements listed. These sub-elements are the
activities that should be performed in order to achieve the deliverables.
• Although most of the WBS diagrams are designed based on the deliveries,
some WBS are created based on the project phases. Usually, information
technology projects are perfectly fit into WBS model.
• Therefore, almost all information technology projects make use of WBS.
• In addition to the general use of WBS, there is specific objective for
deriving a WBS as well. WBS is the input for Gantt charts, a tool that is
used for project management purpose.
• Gantt chart is used for tracking the progression of the tasks derived by
WBS.
Gantt chart
• The efficiency of a work breakdown structure can determine the
success of a project.
• The WBS provides the foundation for all project management
work, including, planning, cost and effort estimation, resource
allocation, and scheduling.
• Therefore, one should take creating WBS as a critical step in the
process of project management.
Milestones
• A milestone is a specific point in time within a project lifecycle
used to measure the progress of a project toward its ultimate
goal. In project management, milestones are used as signal
posts for significant events, decision points, or deliverables
such as:
• The project’s start date
• Project end date
• Submission of a customer report
• Need for an external review or approval
• Every Software Project needs to have these Milestones
1. Project Scope
• The first and foremost milestone is defining the project’s scope. It has
been observed that this is one of the steps that can either take
months or be done within a week, depending on the software type
and end goals. In any case, it is essential to have all the requirements
from the software in a well-organized manner, whether in a simple
word document or received by the customer in a voice note.
• The important thing is to extract only the most important details from
the client’s requirements in this step and move forward to step 2.
2.
Quantify the Project Scope/ Requirements
• In general, quantifying means calculating or measuring something in
numbers. However, quantifying a project scope here means verifying
and validating the requirements.
• You need to have specific details for the end goal of the custom
software that you need to build.
• Once the project scope is quantified and passed through several
refining filters, it is ready to shift to the third milestone.
3.
Set the Development Deliverables
• Any custom development company must set the development deliverables
right after their project scope is quantified. This also means that the final
requirements and tentative deadlines may be decided here.
• Without having the deliverables ready, you will not be able to move any
further in project management.
4. Start the Development
• software development should start at this stage. This is also, by the way,
the middle of the milestones. Therefore, all the planned requirements,
quantified ideas, set deliverables, and end goals must be considered
continuously during this phase.
• This phase also requires constant monitoring and feedback to ensure that
the development progress aligns well with the project scope.
5.
More Feedback and Quality Assurance
• Once the development process reaches the end, more and more
feedback will be needed. This is also the phase where the quality
assurance team will also be interfering. Although quality assurance is
not to be done only at the last stages, it usually works best after
collecting substantial feedback for the developers and other
collaborators.
6. Test the User Acceptance
• This is the phase where the project manager will ensure that the
developed custom software is viable and user-acceptable. User
acceptance testing involves several aspects, such as running the
software and testing it for the tasks it has to perform.
• In simple words, the custom software needs to be thoroughly
checked for its performance from the customer’s point of view.
7. Project Delivery
• You might wonder what the last one could be if we discuss delivering
the project at the second to the previous milestone.
• There is always room for improvement in any project development.
And in the case of custom software, this room can be pretty
significant. That’s why it is important to include the revisions phase in
these essential milestones.
8. Revisions
• As already discussed above, this is the phase where you don’t need to
be overwhelmed by the number of revisions required by the client.
• All you need to do is take every aspect one at a time.
• The best way to deal with the client’s requested changes is to make
one change and then get it verified. Thinking about making and
delivering all the changes simultaneously can cause further problems.
It can consume more time before the final delivery of the project.
Deliverable
A tangible output of human effort provided by a developer to a customer.
Software engineering examples are:
• Project plan
• User manual
• Executable code module
• Design document
• Code listing.
• A deliverable may be composed of multiple smaller deliverables. It may be
either an outcome to be achieved or an output to be provided.
• A deliverable differs from a project milestone in that a milestone is a
measurement of progress toward an output, whereas the deliverable is the
output delivered to a customer or sponsor.
• For a typical project, a milestone might be the completion of a product
design, while the deliverable might be the technical diagram or detailed
design report of the product.
Cost and Estimates
• Several estimation procedures have been developed and are
having the following attributes in common.
1.Project scope must be established in advanced.
2.Software metrics are used as a support from which evaluation is
made.
3.The project is broken into small PCs which are estimated
individually.
To achieve true cost & schedule estimate, several option arise.
4.Delay estimation
5.Used symbol decomposition techniques to generate project cost
and schedule estimates.
6.Acquire one or more automated estimation tools.
Uses of Cost Estimation
1.During the planning stage, one needs to choose how many
engineers are required for the project and to develop a
schedule.
2.In monitoring the project's progress, one needs to access
whether the project is progressing according to the procedure
and takes corrective action, if necessary.
Cost Estimation Models
• A model may be static or dynamic. In a static model, a single
variable is taken as a key element for calculating cost and time.
In a dynamic model, all variable are interdependent, and there
is no basic variable.
Static, Single Variable Models: When a model makes use of single variables to calculate
desired values such as cost, time, efforts, etc. is said to be a single variable model. The most
common equation is:
C=aLb
Where
C = Costs
L= size
a and b are constants
• The Software Engineering Laboratory established a model
called SEL model, for estimating its software production. This
model is an example of the static, single variable model.
E=1.4L0.93
DOC=30.4L0.90
D=4.6L0.26
Where
E= Efforts (Person Per Month)
DOC=Documentation (Number of Pages)
D = Duration (D, in months)
L = Number of Lines per code
• Static, Multivariable Models: These model depends on
several variables describing various aspects of the software
development environment. In some model, several
variables(user participation, customer oriented changes,
memory constraints) are needed to describe the software
development process, and selected equation combined these
variables to give the estimate of time & cost. These models are
called multivariable models.
• WALSTON and FELIX develop the models at IBM provide the
following equation gives a relationship between lines of source
code and effort:
E=5.2L0.91
In the same manner duration of development is given by
D=4.1L0.36
• Example: Compare the Walston-Felix Model with the SEL
model on a software development expected to involve 8 personyears of effort.
1.Calculate the number of lines of source code that can be
produced.
2.Calculate the duration of the development.
3.Calculate the productivity in LOC/PY
4.Calculate the average manning
Solution:
• The amount of manpower involved (E) = 8PY
=96personsmonths
• (a)Number of lines of source code can be obtained by reversing
equation to give:
E=1.4L0.93
L = (96/1.4)1⁄0.93=94264 LOC
Multi variable
E=5.2L0.91
Bringing L to left and E to right
L = (96/5.2)1⁄0.91=24632 LOC
(b)Duration in months can be calculated by means of equation
Single variable
D = 4.6 L0.26
= 4.6 (94.264)0.26 = 15 months
For multi variable
D = 4.1 L0.36
= 4.1 (24.632)0.36 = 13 months
• (c) Productivity is the lines of code produced per persons/month
(year)
• (d)Average manning is the average number of persons required
per month in the project
COCOMO Model
Boehm proposed COCOMO (Constructive Cost Estimation
Model) in 1981.COCOMO is one of the most generally used
software estimation models in the world. COCOMO predicts the
efforts and schedule of a software product based on the size of
the software.
The necessary steps in this model are:
1.Get an initial estimate of the development effort from evaluation
of thousands of delivered lines of source code (KLOC).
2.Determine a set of 15 multiplying factors from various attributes
of the project.
3.Calculate the effort estimate by multiplying the initial estimate
with all the multiplying factors i.e., multiply the values in step1
and step2.
• The initial estimate (also called nominal estimate) is determined by an
equation of the form used in the static single variable models, using KLOC
as the measure of the size. To determine the initial effort Ei in personmonths the equation.
Ei=a*(KLOC)b
The value of the constant a and b are depends on the project type.
In COCOMO, projects are categorized into three types:
1.Organic
2.Semidetached
3.Embedded
1.Organic: A development project can be treated of the organic type, if the
project deals with developing a well-understood application program, the
size of the development team is reasonably small(2-50 kloc), and the team
members are experienced in developing similar methods of
projects. Deadline is flexible.Examples of this type of projects are simple
business systems, simple inventory management systems, and data
processing systems.
2. Semidetached: A development project can be treated with
semidetached type if the development consists of a mixture of
experienced and inexperienced staff. Team members may have
finite experience in related systems but may be unfamiliar with
some aspects of the order being developed. Suitable for(50300kloc) deadline is fixed and it can be relaxed. Example of
Semidetached system includes developing a new operating
system (OS), a Database Management System (DBMS), and
complex inventory management system.
3. Embedded: A development project is treated to be of an
embedded type, if the software being developed is strongly
coupled to complex hardware over 300 kloc and deadline is
fixed. For Example: ATM, Air Traffic control.
According to Boehm, software cost estimation should be done through three
stages:
1.Basic Model
2.Intermediate Model
3.Detailed Model
1.Basic COCOMO Model: The basic COCOMO model provide an accurate size of
the project parameters. The following expressions give the basic COCOMO
estimation model:
Effort=a1*(KLOC)a2 PM
Tdev=b1*(efforts)b2 Months
Where,
• KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
• a1,a2,b1,b2 are constants for each group of software products,
• Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed
in person months (PMs).
Estimation of development effort
For the three classes of software products, the formulas for
estimating the effort based on the code size are shown below:
• Organic: Effort = 2.4(KLOC) 1.05 PM
• Semi-detached: Effort = 3.0(KLOC) 1.12 PM
• Embedded: Effort = 3.6(KLOC) 1.20 PM
Estimation of development time
• For the three classes of software products, the formulas for
estimating the development time based on the effort are given
below:
• Organic: Tdev = 2.5(Effort) 0.38 Months
• Semi-detached: Tdev = 2.5(Effort) 0.35 Months
• Embedded: Tdev = 2.5(Effort) 0.32 Months
Project
a1
a2
b1
b2
Organic
2.4
1.05
2.5
0.38
Semidetached
3.0
1.12
2.5
0.35
Embedded
3.6
1.20
2.5
0.32
Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort
and development time for each of the three model i.e., organic, semi-detached &
embedded.
Solution: The basic COCOMO equation takes the form:
Effort=a1*(KLOC)a2b2PM
Tdev=b1*(efforts) Months
Estimated Size of project= 400 KLOC
(i)Organic Mode
E = 2.4 * (400)1.05 0.38 = 1295.31 PM
D = 2.5 * (1295.31)
= 38.07 PM
(ii)Semidetached Mode
E = 3.0 * (400)1.12 0.35
=2462.79 PM
D = 2.5 * (2462.79)
=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 0.32
= 4772.81 PM
D = 2.5 * (4772.8)
= 38 PM
Example2: A project size of 200 KLOC is to be developed.
Software development team has average experience on similar
type of projects. The project schedule is not very tight. Calculate
the Effort, development time, average staff size, and productivity
of the project.
Solution: The semidetached mode is the most appropriate
mode, keeping in view the size, schedule and experience of
development time.
Hence
E=3.0(200)1.12
=1133.12PM
D=2.5(1133.12)0.35 =29.3PM
P = 176 LOC/PM
Intermediate Model: The basic Cocomo model considers that the effort is
only a function of the number of lines of code and some constants
calculated according to the various software systems. The intermediate
COCOMO model recognizes these facts and refines the initial estimates
obtained through the basic COCOMO model by using a set of 15 cost
drivers based on various attributes of software engineering.
Classification of Cost Drivers and their attributes:
(i) Product attributes • Required software reliability extent
• Size of the application database
• The complexity of the product
(ii) Hardware attributes • Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time
(iii) Personnel attributes • Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
(iv)Project attributes • Use of software tools
• Application of software engineering methods
• Required development schedule
Intermediate COCOMO equation:
E=ai (KLOC) bi*EAF
D=ci (E)di
Project
ai
bi
ci
di
Organic
3.2
1.05
2.5
0.38
Semidetache
d
3.0
1.12
2.5
0.35
Embedded
2.8
1.20
2.5
0.32
Detailed COCOMO Model: Detailed COCOMO incorporates all
qualities of the standard version with an assessment of the cost
drivers. The detailed model uses various effort multipliers for each
cost driver property. In detailed cocomo, the whole software is
differentiated into multiple modules, and then we apply COCOMO in
various modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
1.Planning and requirements
2.System structure
3.Complete structure
4.Module code and test
5.Integration and test
6.Cost Constructive model
The effort is determined as a function of program estimate, and a set
of cost drivers are given according to every phase of the software
lifecycle.
Functional Point (FP) Analysis
• Allan J. Albrecht initially developed function Point Analysis in 1979 at
IBM and it has been further modified by the International Function
Point Users Group (IFPUG). FPA is used to make estimate of the
software project, including its testing in terms of functionality or
function size of the software product. However, functional point
analysis may be used for the test estimation of the product. The
functional size of the product is measured in terms of the function
point, which is a standard of measurement to measure the software
application.
Objectives of FPA
• The basic and primary purpose of the functional point analysis is to
measure and provide the software application functional size to the
client, customer, and the stakeholder on their request. Further, it is
used to measure the software project development along with its
maintenance, consistently throughout the project irrespective of the
tools and the technologies.
Following are the points regarding FPs
• 1. FPs of an application is found out by counting the number
and types of functions used in the applications. Various
functions used in an application can be put under five types, as
shown in Table:
Types of Examples
FP Attributes
Measurements Parameters
1.Number of External Inputs(EI)
Input screen and tables
2. Number of External Output (EO)
Output screens and reports
3. Number of external inquiries (EQ)
Prompts and interrupts.
4. Number of internal files (ILF)
Databases and directories
5. Number of external interfaces (EIF)
Shared databases and shared routines.
All these parameters are then individually assessed for complexity.
The FPA functional units are shown in Fig:
• 2. FP characterizes the complexity of the software system and
hence can be used to depict the project time and the manpower
requirement.
• 3. The effort required to develop the project depends on what
the software does.
• 4. FP is programming language independent.
• 5. FP method is used for data processing systems, business
systems like information systems.
• 6. The five parameters mentioned above are also known as
information domain characteristics.
• 7. All the parameters mentioned above are assigned some
weights that have been experimentally determined and are
shown in Table
Measurement Parameter
Low
Average
High
1. Number of external 3
inputs (EI)
4
6
2. Number of external 4
outputs (EO)
5
7
3. Number of external 3
inquiries (EQ)
4
6
4. Number of internal 7
files (ILF)
10
15
5. Number of external 5
interfaces (EIF)
7
10
Risk
"risk" is a problem that could cause some loss or threaten the progress of
the project, but which has not happened yet.
• These potential issues might harm cost, schedule or technical success of
the project and the quality of our software device, or project team morale.
• Risk Management is the system of identifying addressing and eliminating
these problems before they can damage the project.
Risk Management
• A software project can be concerned with a large variety of risks. In order
to be adapt to systematically identify the significant risks which might affect
a software project, it is essential to classify risks into different classes. The
project manager can then check which risks from each class are relevant
to the project.
• There are three main classifications of risks which can affect a software
project:
1.Project risks
2.Technical risks
3.Business risks
1. Project risks: Project risks concern differ forms of budgetary,
schedule, personnel, resource, and customer-related problems. A
vital project risk is schedule slippage. Since the software is
intangible, it is very tough to monitor and control a software
project. It is very tough to control something which cannot be
identified.
2. Technical risks: Technical risks concern potential method,
implementation, interfacing, testing, and maintenance issue. It
also consists of an ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and
technical obsolescence. Most technical risks appear due to the
development team's insufficient knowledge about the project.
3. Business risks: This type of risks contain risks of building an
excellent product that no one need, losing budgetary or
personnel commitments, etc.
Other risk categories
1. Known risks: Those risks that can be uncovered after careful
assessment of the project program, the business and technical
environment in which the plan is being developed, and more
reliable data sources (e.g., unrealistic delivery date)
2. Predictable risks: Those risks that are hypothesized from
previous project experience (e.g., past turnover)
3. Unpredictable risks: Those risks that can and do occur, but
are extremely tough to identify in advance.
Principle of Risk Management
1.Global Perspective: In this, we review the bigger system
description, design, and implementation. We look at the chance
and the impact the risk is going to have.
2.Take a forward-looking view: Consider the threat which may
appear in the future and create future plans for directing the
next events.
3.Open Communication: This is to allow the free flow of
communications between the client and the team members so
that they have certainty about the risks.
4.Integrated management: In this method risk management is
made an integral part of project management.
5.Continuous process: In this phase, the risks are tracked
continuously throughout the risk management paradigm.
Risk Management Activities
Risk management consists of three main activities, as
shown in fig:
Risk Assessment
• The objective of risk assessment is to division the risks in the
condition of their loss, causing potential. For risk assessment, first,
every risk should be rated in two methods:
• The possibility of a risk coming true (denoted as r).
• The consequence of the issues relates to that risk (denoted as s).
• Based on these two methods, the priority of each risk can be
estimated:
p=r*s
Where p is the priority with which the risk must be controlled, r is the
probability of the risk becoming true, and s is the severity of loss
caused due to the risk becoming true.
If all identified risks are set up, then the most likely and damaging risks
can be controlled first, and more comprehensive risk assessment
methods can be designed for these risks.
Risk Identification: The project organizer needs to anticipate the risk in the
project as early as possible so that the impact of risk can be reduced by
making effective risk management planning.
• A project can be of use by a large variety of risk. To identify the significant
risk, this might affect a project. It is necessary to categories into the
different risk of classes.
• There are different types of risks which can affect a software project:
1.Technology risks: Risks that assume from the software or hardware
technologies that are used to develop the system.
2.People risks: Risks that are connected with the person in the
development team.
3.Organizational risks: Risks that assume from the organizational
environment where the software is being developed.
4.Tools risks: Risks that assume from the software tools and other support
software used to create the system.
5.Requirement risks: Risks that assume from the changes to the customer
requirement and the process of managing the requirements change.
6.Estimation risks: Risks that assume from the management estimates of
the resources required to build the system
Risk Analysis: During the risk analysis process, you have to
consider every identified risk and make a perception of the
probability and seriousness of that risk.
• There is no simple way to do this. You have to rely on your
perception and experience of previous projects and the
problems that arise in them.
• It is not possible to make an exact, the numerical estimate of
the probability and seriousness of each risk. Instead, you
should authorize the risk to one of several bands:
1.The probability of the risk might be determined as very low (010%), low (10-25%), moderate (25-50%), high (50-75%) or very
high (+75%).
2.The effect of the risk might be determined as catastrophic
(threaten the survival of the plan), serious (would cause
significant delays), tolerable (delays are within allowed
contingency), or insignificant.
Risk Control
• It is the process of managing risks to achieve desired outcomes.
After all, the identified risks of a plan are determined; the project
must be made to include the most harmful and the most likely risks.
Different risks need different containment methods. In fact, most
risks need ingenuity on the part of the project manager in tackling
the risk.
• There are three main methods to plan for risk management:
1.Avoid the risk: This may take several ways such as discussing with
the client to change the requirements to decrease the scope of the
work, giving incentives to the engineers to avoid the risk of human
resources turnover, etc.
2.Transfer the risk: This method involves getting the risky element
developed by a third party, buying insurance cover, etc.
3.Risk reduction: This means planning method to include the loss
due to risk. For instance, if there is a risk that some key personnel
might leave, new recruitment can be planned.
• Risk Leverage: To choose between the various methods of
handling risk, the project plan must consider the amount of
controlling the risk and the corresponding reduction of risk. For
this, the risk leverage of the various risks can be estimated.
• Risk leverage is the variation in risk exposure divided by the
amount of reducing the risk.
• Risk leverage = (risk exposure before reduction - risk
exposure after reduction) / (cost of reduction)
• 1. Risk planning: The risk planning method considers each of
the key risks that have been identified and develop ways to
maintain these risks.
• For each of the risks, you have to think of the behavior that you
may take to minimize the disruption to the plan if the issue
identified in the risk occurs.
Risk Monitoring: Risk monitoring is the method that your assumption
about the product, process, and business risks has not changed.
Project Scheduling
• Project-task scheduling is a significant project planning activity. It
comprises deciding which functions would be taken up when. To
schedule the project plan, a software project manager wants to do
the following:
1.Identify all the functions required to complete the project.
2.Break down large functions into small activities.
3.Determine the dependency among various activities.
4.Establish the most likely size for the time duration required to
complete the activities.
5.Allocate resources to activities.
6.Plan the beginning and ending dates for different activities.
7.Determine the critical path. A critical way is the group of activities
that decide the duration of the project.
Personnel Planning
• Personnel Planning deals with staffing. Staffing deals with the
appoint personnel for the position that is identified by the
organizational structure.
It involves:
• Defining requirement for personnel
• Recruiting (identifying, interviewing, and selecting candidates)
• Compensating
• Developing and promoting agent
RMMM Plan
• The RMMM PLAN documents all work performed as part of risk analysis and used by
the project manager as part of the overall project plan
• Some software teams do not develop a formal RMMM document, rather each risk is
documented individually using a Risk information sheet (RIS)
• In most cases, RIS is maintained using a database system.
• So Creation and information entry, priority ordering, searches and other analysis
may be accomplished easily.
• RMMM - Mitigation, Monitoring, and Management
• An effective strategy for dealing with risk must consider three issues
• Risk mitigation is a problem avoidance activity
• Risk monitoring is a project tracking activity
• Risk management includes contingency plans that risk will occur
Risk Mitigation
• Risk mitigation (avoidance) is the primary strategy and is achieved through a plan
• For Ex., Risk of high staff turnover
• To mitigate this risk, you would develop a strategy for reducing turnover.
• The possible steps to be taken are:
• Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, and
competitive job market)
• Mitigate those causes that are under your control before the project starts
• Once the project commences, assume turnover will occur and develop techniques to ensure continuity
when people leave
• Organize project teams so that information about each development activity is widely dispersed
• Define work product standards and establish mechanisms to be sure that all models and documents
are developed in a timely manner
• Conduct peer reviews of all work (so that more than one person is “up to speed”).
• Assign a backup staff member for every critical technologist
Risk Monitoring
• The project manager monitors factors that may provide an indication of whether the
risk is becoming more or less likely.
• In the case of high staff turnover, the general attitude of team members based on
project pressures, the degree to which the team has jelled, inter-personal
relationships among team members, potential problems with compensation and
benefits, and the availability of jobs within the company and outside it are all
monitored.
• In addition to monitoring these factors, a project manager should monitor the
effectiveness of risk mitigation steps.
• The project manager should monitor work products carefully to ensure that each can
stand on its own and that each imparts information that would be necessary if a
newcomer were forced to join the software team somewhere in the middle of the
project.
Risk Management
• Risk management and contingency planning assumes that mitigation efforts
have failed and that the risk has become a reality.
• If the mitigation strategy has been followed, backup is available, information
is documented, and knowledge has been dispersed across the team.
• In addition, you can temporarily refocus resources (and readjust the project
schedule) to those functions that are fully staffed, enabling newcomers who
must be added to the team to “get up to speed.” Those individuals who are
leaving are asked to stop all work and spend their last weeks in “knowledge
transfer mode.”
CASE Tools
CASE stands for Computer Aided Software Engineering. It means,
development and maintenance of software projects with help of
various automated software tools.
• CASE tools are set of software application programs, which are
used to automate SDLC activities. CASE tools are used by
software project managers, analysts and engineers to develop
software system.
• There are number of CASE tools available to simplify various
stages of Software Development Life Cycle such as Analysis
tools, Design tools, Project management tools, Database
Management tools, Documentation tools are to name a few.
• Use of CASE tools accelerates the development of project to
produce desired result and helps to uncover flaws before
moving ahead with next stage in software development.
Components of CASE Tools
• CASE tools can be broadly divided into the following parts
based on their use at a particular SDLC stage:
• Central Repository - CASE tools require a central repository,
which can serve as a source of common, integrated and
consistent information. Central repository is a central place of
storage where product specifications, requirement documents,
related reports and diagrams, other useful information
regarding management is stored. Central repository also serves
as data dictionary.
• CASE tools can be grouped together if they have similar functionality,
process activities and capability of getting integrated with other tools.
Scope of Case Tools
• The scope of CASE tools goes throughout the SDLC.
• Case Tools Types
• Now we briefly go through various CASE tools
Diagram tools
• These tools are used to represent system components, data and control
flow among various software components and system structure in a
graphical form. For example, Flow Chart Maker tool for creating state-ofthe-art flowcharts.
Process Modeling Tools
• Process modeling is method to create software process model, which is
used to develop the software. Process modeling tools help the managers
to choose a process model or modify it as per the requirement of software
product. For example, EPF Composer
Project Management Tools
• These tools are used for project planning, cost and effort estimation,
project scheduling and resource planning. Managers have to strictly
comply project execution with every mentioned step in software
project management. Project management tools help in storing and
sharing project information in real-time throughout the organization.
For example, Creative Pro Office, Trac Project, Basecamp.
Documentation Tools
• Documentation in a software project starts prior to the software
process, goes throughout all phases of SDLC and after the
completion of the project.
• Documentation tools generate documents for technical users and
end users. Technical users are mostly in-house professionals of the
development team who refer to system manual, reference manual,
training manual, installation manuals etc. The end user documents
describe the functioning and how-to of the system such as user
manual. For example, Doxygen, DrExplain, Adobe RoboHelp for
documentation.
Analysis Tools
• These tools help to gather requirements, automatically check for any
inconsistency, inaccuracy in the diagrams, data redundancies or erroneous
omissions. For example, Accept 360, Accompa, CaseComplete for requirement
analysis, Visible Analyst for total analysis.
Design Tools
• These tools help software designers to design the block structure of the software,
which may further be broken down in smaller modules using refinement
techniques. These tools provides detailing of each module and interconnections
among modules. For example, Animated Software Design
Configuration Management Tools
• An instance of software is released under one version. Configuration
Management tools deal with –
• Version and revision management
• Baseline configuration management
• Change control management
• CASE tools help in this by automatic tracking, version management and release
management. For example, Fossil, Git, Accu REV.
Change Control Tools
• These tools are considered as a part of configuration
management tools. They deal with changes made to the
software after its baseline is fixed or when the software is first
released. CASE tools automate change tracking, file
management, code management and more. It also helps in
enforcing change policy of the organization.
Programming Tools
• These tools consist of programming environments like IDE
(Integrated Development Environment), in-built modules library
and simulation tools. These tools provide comprehensive aid in
building software product and include features for simulation
and testing. For example, Cscope to search code in C, Eclipse.
Prototyping Tools
• Software prototype is simulated version of the intended software
product. Prototype provides initial look and feel of the product and
simulates few aspect of actual product.
• Prototyping CASE tools essentially come with graphical libraries. They
can create hardware independent user interfaces and design. These
tools help us to build rapid prototypes based on existing information.
In addition, they provide simulation of software prototype. For
example, Serena prototype composer, Mockup Builder.
Web Development Tools
• These tools assist in designing web pages with all allied elements like
forms, text, script, graphic and so on. Web tools also provide live
preview of what is being developed and how will it look after
completion. For example, Fontello, Adobe Edge Inspect, Foundation
3, Brackets.
Quality Assurance Tools
• Quality assurance in a software organization is monitoring the
engineering process and methods adopted to develop the software
product in order to ensure conformance of quality as per
organization standards. QA tools consist of configuration and
change control tools and software testing tools. For example,
SoapTest, AppsWatch, JMeter.
Maintenance Tools
• Software maintenance includes modifications in the software
product after it is delivered. Automatic logging and error reporting
techniques, automatic error ticket generation and root cause
Analysis are few CASE tools, which help software organization in
maintenance phase of SDLC. For example, Bugzilla for defect
tracking, HP Quality Center.
Agile Project Management
• Agile project management is an interactive approach to manage
software development. The agile project management focuses
on continuous releases and covers customer feedback with
every iteration.
• Traditionally the agile project management is classified into two
frameworks:
scrum
and
kanban.
The
scrum
framework
focused
fixed-length
project
iterations,
whereas kanban framework focused on continuous releases.
After competition of project first iteration (or steps) project
management activity immediately moves on to the next.
History of Agile Project Management
• Agile project management is rapidly rising in the 21st century. It
is used for software development projects and other IT
initiatives.
• However, from the mid-20th century, the concept of continuous
development has taken various forms. For example, there was
James Martin's Rapid Iterative Production Prototyping
(RIPP), an approach that served as the premise for the 1991
book Rapid Application Development (RAD).
• The agile project management framework which has emerged
in most recent years is known as Scrum. This methodology
features works on the development team to create a product
backlog. It also creates a prioritized list of the features,
functionalities, and fixes required to deliver a successful
software system. The scrum team offers the pieces of a task in
rapid increments.
How Agile Project Management works
• The agile project management calls for teams to regularly evaluate cost
and time as they move through their work. They use velocity, burnup and
burndown charts to measure their work, rather than Gantt charts and
project milestones to track progress.
• The agile team practices to continuous development and continuous
integration using technology that automates steps to speed up the release
and use of products.
• The presence and participation of the project manager are not required in
agile project management. Although the presence of the project manager
is essential for success under the traditional (waterfall model) project
delivery. The role of the project manager is to distribute task among team
members. However, the project manager is not obsolete in agile project
management, and many organizations use them in a large, more complex
project. The organization mostly places them in the project coordinator
role.
• Agile Project Management demands that team members know how to
work in this new agile methodology. The team member must be able to
coordinate with each other, as well as with users.
What is Scrum?
• Scrum is a framework that helps agile teams to work together. Using it, the
team members can deliver and sustain the complex product. It encourages the
team to learn through practice, self-organize while working on the problem. Scum
is a work done through the framework and continuously shipping values to
customers.
• It is the most frequent software that is used by the development team. Its
principle and lessons can be applied to all kinds of teamwork. Its policy and
experiences is a reason of popularity of Scrum framework. The Scrum describes
a set of tools, meetings, and roles that help the teams structure. It also manages
the work done by the team
The framework
• Scrum and agile are not the same thing because Scrum focused on continuous
improvement, which is a core foundation of agile. Scrum framework focuses on
ongoing getting work done.
• What are sprints?
• With scrum, a product is built in a series of repetition called sprints. It breaks
down big complex projects into bite-size pieces. It makes projects more
manageable, allows teams to ship high quality, work faster, and more frequently.
The sprints give them more flexibility to adapt to the changes.
• Sprints are a short, time-boxed period for Scrum team that works
to complete a set amount of work. Sprints are the core
component of Scrum and agile methodology. The right sprints will
help our agile team to ship better software.
What is sprint plan?
• Sprint plan is an action in Scrum that kicks off the sprint. The primary purpose of
sprint plan is to define what can deliver in the sprint. It also focuses on how the
work will be achieved. It is done in combination with the whole Scrum team
members.
• The sprint is a set of the period where all the work to be done. Before we start the
development, we have to set up the sprint. We need to describe how long time is
required to achieve the sprint goal and where we are going to start.
Factors affecting Sprint planning
• The What: The product owner describes the goal of the sprint and the backlog
items which contribute to achieve that goal.
• The How: Agile development team plans its necessary work on how to achieve
and deliver the sprint goal.
• The Who: The product owner defines the goal based on the value that the
customers seek. And the developer needs to understand how they can or cannot
deliver that goal.
• The Inputs: The product backlog provides the list of input stuff that could
potentially be part of the current sprint. The team looks over the existing work
done in incremental ways.
• The Outputs: The critical outcome of sprint planning is to meet described team
goal. The product set the goal of sprint and how they will start working towards
the goal.
What is the product backlog?
A product backlog is a registered list of work for the
development team. It is driven from the roadmap and its
requirements. The essential task is represented at the top of
the product backlog so that the team member knows what to
deliver first. The developer team doesn't work through the
backlog from the product owner's side and product owner
doesn't push the work to the developer team. The developer
team pulls work from the product backlog.
Backlog starts with the two "R"s
The fundamental product backlog is provided by a
team's roadmap and requirements. Roadmap repetition
breaks down into several epics, and each epic will have several
requirements and user stories.
The product owner organizes each of the customer stories into
a single list. This story is organized for the development team.
The product owner chooses to deliver first complete epic.
The factors that influence a product owner's prioritization
• Priority of customer
• Importance of getting feedback
• Relative implementation difficulty
• Symbiotic relationships between work items
What is Kanban?
• Kanban is a popular framework which is used to implement agile software
development. It takes real time communication of capacity and complete
transparency of work. The work items are represented in a kanban board
visually, allowing team members to see the state of every piece of work at
any time.
Boards
• The kanban board is the agile project management tool that designed the
necessary visualized work, limited work-in-progress, and maximizes flow
(or efficiency). It uses cards, columns, and provides continuous
improvement to help technology and service teams who commit the right
amount of work and get it done.
Elements of a kanban board
1.Visual Signals: The kanban board is a visual card (stickies, tickets, or otherwise).
Kanban team write their projects and work items onto cards, usually per person
each card. For agile teams, each card could encapsulate into one user story. Once
the board completed, this visual team helps team members and stock members
quickly to understand what the team is working.
2.Columns: The column represents the specific activities that compose a "workflow"
together. The card flows through a workflow until its completion. The workflow may
be a simple as "To Do," "In Progress," "Complete," or much more complicated.
3.Work in progress (WIP) Limits: The work in progress limits are the maximum
number of cards which can be in one column. This is at any given time. It gives the
alert signal that you committed too much work.
4.Commitment point: Kanban teams also maintain a backlog for their board. This
is where the customers and team member put ideas for projects that the team can
pick up. The team members pick up plans when they are ready. The committed
point is a movement where the design is picked up by the team, and work starts
on the project.
5.Delivery point: It is the end point of a kanban team's workflow. Mostly the delivery
point for every team is when the product and services are handed to the customer.
• Kanban vs Scrum board
• The following are the differences between Kanban and Scrum
board:
Kanban
Scrum
Kanban is an ongoing process.
Scrum sprints have a start and stop dates
Kanban has no formal roles.
Role is clearly defined of each team in the scrum
(product owner, development team, and scrum
master). Both teams are self-organized.
A kanban board is used throughout the lifecycle of Scrum board is cleared and recycled after each
a project
sprint.
This board is more flexible with regards to tasks This board has the number of tasks and a strict
and timing. Its task can be reprioritized, reassigned, deadline to complete them.
or updated as needed.
Managing team dynamics and communication
• Define your team’s goal
• Share experiences and knowledge.
• Practice good communication and collaboration.
• Generate an energizing and positive work culture.
• Set individual expectations for team members.
• Make the troubleshooting process faster.
• Maintain a proper schedule.
Metrics and Measurement
• Software metrics is a standard of measure that contains many
activities which involve some degree of measurement. It can be
classified into three categories: product metrics, process metrics, and
project metrics.
• Product metrics: describe the characteristics of the product such as
size, complexity, design features, performance, and quality level.
• Process metrics :can be used to improve software development and
maintenance. Examples include the effectiveness of defect removal
during development, the pattern of testing defect arrival, and the
response time of the fix process.
• Project metrics :Project metrics are the metrics used by the project
manager to check the project's progress. Data from the past projects
are used to collect various metrics, like time and cost; these
estimates are used as a base of new software.The project manager
will check its progress from time-to-time and will compare the effort,
cost, and time with the original effort, cost and time.
Scope of Software Metrics
• Software metrics contains many activities which include the following
−
• Cost and effort estimation
• Productivity measures and model
• Data collection
• Quantity models and measures
• Reliability models
• Performance and evaluation models
• Structural and complexity metrics
• Capability – maturity assessment
• Management by metrics
• Evaluation of methods and tools