Unit 3

SOFTWARE ENGINEERING
UNIT-III
School of CSA
Dr.Hemanth.K.S
UNIT -3: [13 HOURS]
Agile Implementation and Managing Software Products:

AGILE development.
Managing Software Products:
Project Management Concepts,
Project Estimation and Scheduling,
Risk Management,
Maintenance and Re-engineering.
AGILE DEVELOPMENT
What is Agile?
Able to move quickly and easily
Software Engineering
Agile is an approach to project management that leans heavily on

short time frames, adaptability, and iteration.
AGILE DEVELOPMENT
What is Agile?
• Agile is an ability to adapt or to create and respond to

change.
• It basically means to understand the changes and uncertainty

in the environment and adapt itself accordingly.
• Keeping this thought in mind, the software developers build

Agile to overcome the drawbacks of other software
development models.
AGILE DEVELOPMENT
AGILE BENEFITS
Consistently the top reasons why companies and organizations adopt agile are to:
• Accelerate software delivery.

• Better manage changing priorities.
• Increase productivity.
The top benefits realized are the ability to:
• Manage changing priorities.

• Increase project visibility.
• Align business and IT.
AGILE DEVELOPMENT
AGILE BENEFITS
The Agile process is a methodology that emphasizes collaboration, flexibility, and continuous
improvement. Here are some of the benefits of using an Agile process:
• Increased Flexibility
• Enhanced Collaboration
• Faster Time-to-Market
• Increased Customer Satisfaction
• Greater Transparency
AGILE DEVELOPMENT
Effective (rapid and adaptive) response to change

Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work performed
Yielding …
Rapid, incremental delivery of software
The agile process forces the development team to focus on software itself rather than
design and documentation.
AGILE DEVELOPMENT
AGILITY AND COST OF CHANGE
AGILE DEVELOPMENT
Agility Principles
1. Customer satisfaction: Customers need to be satisfied with the quick delivery of the product at the
earliest.
2. Welcome change: Even if the change is late in the development process, it needs to be addressed
and handled as soon as possible.
3. Deliver frequently: The focus must be on the continuous delivery of software in a shorter
timescale.
4. Work together: Business units and developers need to work in tandem throughout the project
lifespan.
5. Motivated team: The projects need to have motivated team members. They must also be trusted
to get the work done.
6. Face-to-face: Conversations that take place face-to-face have maximum efficiency and
AGILE DEVELOPMENT
Agility Principles
Working software: The primary measure of progress is evaluated based on the working software
created.
Constant pace: The agile process is greatly beneficial when it comes to sustainable development.
Good design: Focusing on technological excellence and good design can significantly affect agility.
Simplicity: The amount of work not being done needs to be reduced via simpler processes.
Self-organized: Self-organized teams end up providing the best architectures, designs, and
requirements.
Reflection and adjustment: The effectiveness can be significantly improved by regular reflection on it,
by the team.
AGILE DEVELOPMENT
Key Agile Concepts
• User Stories: The team divides the work into functional units known as "user stories" in consultation with
the client or product owner. Each user story must add something valuable to the final product.
• Daily Meeting: The team meets every day at the same time to update everyone on the information
necessary for coordination:
• Personas: When the project requires it, the team creates in-depth, fabricated biographies of hypothetical
users of the intended product.
• Team: A small group of individuals assigned to the same project or effort, almost all of whom work full-
time, is referred to as a "team" in the Agile context.
AGILE DEVELOPMENT
Key Agile Concepts
• Incremental Development: Agile teams prefer to use an incremental development strategy, which in an
Agile setting means that each iteration of the product improves on the one before it by including user-
visible functionality.
• Iterative development: Agile projects intentionally permit "repeating" software development activities
and the potential for "revisiting" the same work products, known as iterative development.
• Milestone Retrospective: After a project has been running for a while, the team dedicates one to three
days to examine the key moments.
AGILE DEVELOPMENT
How Does Agile Work?
Here is the working of Agile -
• Define the project: The team, along with the customer, defines the project's goals, objectives, and
requirements.
• Create a backlog: A backlog is a prioritized list of tasks that need to be completed. The customer, product
owner, and the team work together to create the backlog.
• Plan the sprint: The team plans the sprint by selecting the highest-priority tasks from the backlog and
determining how much work can be completed in the upcoming sprint.
• Execute the sprint: The team works on completing the tasks planned for the sprint, with daily meetings to
check progress and address any issues.
AGILE DEVELOPMENT
How Does Agile Work?
Here is the working of Agile -
• Review and demo: At the end of the sprint, the team demonstrates the completed work to the customer
and gets feedback.
• Retrospect: The team retrospects on the sprint, discussing what went well, what didn't, and what can be
improved for the next sprint.
• Repeat: The process is repeated for each sprint until the project is completed. The product is incrementally
developed and delivered to the customer in small chunks.
• Continuously improve: Agile methodologies focus on continuous improvement. The team reflects on its
progress and makes adjustments as necessary to improve processes, tools, and communication for the next
sprint.
AGILE DEVELOPMENT
How is Agile Different?
Agile is different from traditional project management
methodologies in several ways:
• Agile prioritizes flexibility and continuous improvement

over following a strict plan. Agile methodologies are
designed to be adaptive and responsive to changing
requirements and priorities.
• Agile emphasizes collaboration between teams,
customers, and stakeholders and encourages open
communication and transparency throughout the project
lifecycle.
• Agile uses short iterations called sprints to manage and
track progress, with regular reviews and assessments to
ensure that the project stays on track.
AGILE DEVELOPMENT
How is Agile Different?
Agile is different from traditional project management methodologies in several ways:
• Agile encourages the delivery of working software early and often rather than waiting until the end of the
project to deliver a final product.
Overall, Agile approaches focus on continuous delivery and improvement, adaptability and customer
involvement. In contrast, traditional project management approaches focus more on following a plan and
sticking to a budget and schedule.
AGILE DEVELOPMENT
When Should You Use Agile Project Management?
• Agile is a project management approach that is better suited for ongoing projects and projects
where specific details are unclear from the beginning because of its core principles, which
include continuous delivery, iteration, adaptability, and short time frames, among others.
• Therefore, an Agile approach is a good choice for a project lacking precise constraints,
deadlines, or resources.
AGILE DEVELOPMENT
AGILE DEVELOPMENT
What is SCRUM ?
• Scrum is a popular framework that enables teams to work together. Based on Agile principles, Scrum
enables the development, delivery, and sustenance of complex projects.
• It enables teams to hypothesize how they think something works, try it out, learn and reflect from
their experiences, and make appropriate changes.
AGILE DEVELOPMENT
SCRUM Principles
• Small working teams used to maximize communication and minimize overhead

• Process must be adaptable to both technical and business challenges to ensure best produced
• Process yields frequent increments that can be inspected, adjusted, tested, documented &
built on
• Development work and people performing it are partitioned into clean, low coupling partitions
• Testing and documentation is performed as the product is built
• Ability to declare the product done whenever required
AGILE DEVELOPMENT
SCRUM PROCESS
Step1: Create a Scrum project
The list of tasks that needs to be done in the project is called a product backlog.
Step 2: Create user stories or tasks in the backlog
• User stories describe the work items from the user's perspective in a non-technical language.
• Once the user stories are created, we can prioritize them in the backlog.
Step 3: Create a Sprint
• In Scrum, the team forecast to complete a set of user stories in a fixed time duration called a
sprint. The optimal time mostly we set for a sprint is for two weeks.
AGILE DEVELOPMENT
SCRUM PROCESS
Step4: Hold the Sprint Planning Meeting

The first meeting to start the sprint is called a Sprint planning meeting.
The product owner, scrum master, and the entire team members attend it to discuss the sprint goal
and stories in the prioritized product backlog.
Step 5 : Hold the Daily Standup Meetings

Daily standup meetings inspect the progress of the Sprint goal and how progress is trending towards
work completion in the sprint backlog.
AGILE DEVELOPMENT
SCRUM PROCESS
Step 6 : View the Burndown Chart

A graphical representation of how quickly the team is working through customers' user stories is called
the Burndown chart. It estimates the actual and estimated amount of work to be done in a sprint.
Step 7: Hold the Sprint Review Meeting

• Sprint reviews take place at the end of the sprint and are specially designed for gathering actionable
feedback on what the team has completed.
• Also, referred to as demos, which shows the overall work to the team and inspects the roadmap for
the product.
AGILE DEVELOPMENT
SCRUM PROCESS
Step 8: Hold the Sprint Retrospective Meeting

Sprint retrospectives are used to inspect and improvements to be performed in the next sprint. Sprint
retrospectives occur before the next sprint planning and after the Sprint review.
AGILE DEVELOPMENT
Scrum
framework
AGILE DEVELOPMENT
SCRUM
Advantages
• Quicker release
• Increased project control
• Greater ability to incorporate changes at any time
• Improved progress visibility and control
• Higher productivity
• Lower costs
• Higher customer satisfaction
AGILE DEVELOPMENT
SCRUM
Disadvantages
• The chances of project failure are high if individuals aren't very committed or cooperative.
• Daily meetings sometimes frustrate team members.
• The Scrum framework in large teams is challenging
• Mostly suited for small teams that have great cohesion and understanding.
• If a member of the team leaves the process during development, it has a negative impact on the project
development.
• With no deadline to deliver the product, it leads to scope creep
AGILE DEVELOPMENT
Extreme Programming (XP)
What is Extreme Programming?
• XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop
a software.
• Extreme Programming is one of the Agile software development methodologies
• It shares all Agile principles including strong customer involvement in the software
development process, good communication inside of the teams, and iterative cycles of
development.
AGILE DEVELOPMENT
AGILE DEVELOPMENT
1. XP Design
• Follows the KIS principle (KEEP IT SIMPLE)
• Encourage the use of CRC cards
• Encourages “refactoring”—an iterative refinement of the internal program design
2. XP Coding
• Recommends the construction of a unit test for a store before coding commences
• Encourages “pair programming”
3. XP Testing
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and excuted to assess customer visible
functionality
AGILE DEVELOPMENT
• Applications of Extreme Programming (XP): Some of the projects that are suitable to
develop using XP model are given below:
• Small projects: XP model is very useful in small projects consisting of small teams as face to
face meeting is easier to achieve.
• Projects involving new technology or Research projects: This type of projects face
changing of requirements rapidly and technical problems. So XP model is used to complete
this type of projects.
AGILE DEVELOPMENT
Advantages
• Save costs and time

• Reduces the risks
• Simplicity
• process is visible and accountable.
• Constant feedback
• Working software faster
AGILE DEVELOPMENT
Disadvantages
• Some specialists say that Extreme Programming is focused on the code rather than on
design.
• This methodology does not measure code quality assurance
• It may cause defects in the initial code.
• XP is not the best option if programmers are separated geographically.

AGILE DEVELOPMENT
Comparison of Agile model
PROJECT MANAGEMENT CONCEPTS
Why Do Major Engineering Undertakings Often Fail?
Poor planning: One of the biggest reasons why software engineering projects fail is because of
poor planning.
Lack of communication: Effective communication is crucial for the success of any project, and
this is particularly true for software engineering projects. When team members don't
communicate effectively, mistakes can be made, requirements can be misinterpreted, and
problems can go unnoticed until it's too late to fix them.
Technical challenges: Software engineering projects can be extremely complex, and there are
often technical challenges that need to be overcome.
Why Do Major Engineering Undertakings Often Fail?
Changing requirements: It's not uncommon for requirements to change during the course of a
software engineering project.
Poor project management: Effective project management is essential for the success of any
software engineering project. This includes managing budgets, schedules, resources, and risks. If
project management is poor, it can lead to delays, cost overruns, and other problems.
Lack of testing: Testing is a critical part of any software engineering project. Without proper
testing, bugs and other issues can go undetected, leading to problems down the line.
Unrealistic expectations: Finally, it's not uncommon for software engineering projects to fail
because of unrealistic expectations.
Effective Software management encompasses three main areas:
• People
• Problem
• Process People Problem
Process
People
❖ The Players -- It is important to recognize the different categories of people involved in a large
software project.
❖ Senior Managers - who define business issues.

❖ Project Managers - who plan, motivate, organize and control the practitioners
❖ Practitioners - who deliver the technical skill that are necessary to engineer the project
❖ Customers - who specify the requirements
❖ End users - who interact with the software once it is released.
People
Team Leadership -- A Critical Item
❖ The Problem
❖ The best programmers often make poor team leaders.
❖ Different skills are required.
❖ Technical leadership model

❖ Motivation - The ability to encourage technical people to produce to their best ability.
❖ Organization - The ability to mold existing processes that will enable the initial concept to be
translated into reality.
❖ Ideas and Innovation - The ability to invite creativeness even within a set of restrictions.
People
Team Organizational Models
❖ Democratic decentralized (DD). -- Does not have a defined leader. “Task Coordinators” are
appointed to assure that a particular job is to be executed. These are later replaced by other
“Task Coordinators” as new tasks arise.
❖ Controlled decentralized (CD) -- Has a defined leader who coordinates tasks, and secondary
leaders who carry out subtasks. Problem solving is done by the group, implementation is done by
subgroups.
❖ Controlled Centralized (CC) - Top-level problem solving and team coordination managed by the
team leader. The communication between the leader and members is vertical.
People
Project Features Impacting Organization
• Difficulty of problem to be solved.

• Expected size of the resultant program.
• The time the team will remain together.
• The degree to which the problem can be modularized.
• The required quality and reliability of the system.
• The rigidity of the delivery date.
• The degree of communication required for the project.
People
Other Underlying Organizational Factors
• Matrix model
❖The organization has divisions organized by skills, e.g., engineering, safety and mission
assurance (SMA), human factors, etc.
❖Projects “rent” people from the divisions, as needed.
• Issues
❖ Who evaluates person for raises?
❖ Independence of reporting for safety & quality issues?
❖ Who is boss?
People
How Do We Communicate?
Informally - Good phone/electronic service, a clear definition of group interdependencies and good
relationships help encourage communication
Meetings - Regular project meetings help alleviate minor misunderstandings
Workbook - a formal project workbook must be started from the beginning
People
Project Coordination techniques
Formal, impersonal approaches - software engineering documents and deliverables, technical memos,
project milestones, schedules and control tools
Formal interpersonal procedures - quality assurance activities - reviews and design and code inspections
Informal, interpersonal procedures - group meetings

Electronic communication - Email, bulletin boards, web sites, extension and video conferences
Interpersonal network - discussions with those outside of the project.
People
A Study on the Impact of
Coordination Techniques
The Problem
Must first determine project scope.

• Context - How does this software to be built fit into the larger system? What
constraints are imposed as a result of this?
• Information objectives - What customer-visible objects are produced from the
software? What data objects are necessary for input?
• Function and performance - What functions or actions does the software perform to
transform the output?
• The stability, or lack thereof, of the project requirements is a major factor in project
management
The Process
❖Select a software engineering model.
❖ Project framework.
❖ Customer communication.
❖ Planning -- determine resources, time line & other info.
❖ Risk analysis -- assess technical and management risks
❖ Engineering -- build one or more representations of the product.
❖ Construction and release -- construct, test, install and provide user support.
❖ Customer evaluation -- obtain feedback on product

Typical activities
• Review the customer request.
• Plan and schedule a formal, facilitated meeting with the customer.
• Conduct research to define proposed solutions.
• Prepare a “working document” and meeting agenda.
• Conduct meeting with customer.
• Jointly develop mini-specs for the product.
• Review each mini-spec for correctness, lack of ambiguity.
• Assemble the mini-specs into a scoping document.
• Review the scoping document with all concerned.
• Modify the scoping document as required.
Summary
• Software project management is an umbrella activity that continues throughout the life cycle of the
system.
• Software management includes people, the problem, and the process.
• The most critical element in all software system projects is the people. The team can have an number
of structures that effect the way work is accomplished.
• However, complete, consistent problem definition and an effective process are also essential
ingredients.
SOFTWARE PROJECT ESTIMATION
Software project estimation is the process of predicting the time, effort, and resources required to
complete a software development project.
Accurate estimation is essential for effective project planning, resource allocation, and budgeting.
Even though an estimation is not the final software cost but just a ballpark range of the project –
it’s essential to be as accurate as possible. To be transparent and fair, an estimate should take into
consideration the following points but doesn’t have to be limited to them:
• Tasks – the details of what needs to be done

• Resources – what human resources are available
• Rate – cost to time ratio, the payment currency, and discounts
• Duration – how long will the project take to complete
• Third-party services – what additional services are necessary for completing the project
The four basic steps in Software Project Estimation are −
• Estimate the size of the development product.

• Estimate the effort in person-months or person-hours.
• Estimate the schedule in calendar months.
• Estimate the project cost in agreed currency.
The objective of software project planning is to provide a framework that enables the
manager to make reasonable estimates of resources, cost, and schedule.
The plan must be adapted and updated as the project proceeds.

Task Set for Project Planning 5. Estimate cost and effort.

1. Establish project scope. a. Decompose the problem.
2. Determine feasibility. b. Develop two or more estimates using size,
3. Analyze risks function points, process tasks, or use cases.
4. Define required resources. c. Reconcile the estimates.
a. Determine required human resources. 6. Develop a project schedule.
b. Define reusable software resources. a. Establish a meaningful task set.
c. Identify environmental resources. b. Define a task network.
c. Use scheduling tools to develop a time-line chart.
d. Define schedule tracking mechanisms.
RESOURCES
Software cost and effort estimation will never be an exact science. Too many variables—
human, technical, environmental, political—can affect the ultimate cost of software and
effort applied to develop it.
To achieve reliable cost and effort estimates, a number of options arise
1. Delay estimation until late in the project (obviously, we can achieve 100 percent
accurate estimates after the project is complete!).
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project cost and effort
estimates.
4. Use one or more empirical models for software cost and effort estimation.
DECOMPOSITION TECHNIQUES
• Software project estimation is a form of problem solving, and in most cases, the
problem to be solved (i.e., developing a cost and effort estimate for a software project) is
too complex to be considered in one piece.
• For this reason, it is must to decompose the problem, recharacterizing it as a set of

smaller (and hopefully, more manageable) problems.
Software Sizing
The accuracy of a software project estimate is predicated on a number of things:
1. the degree to which you have properly estimated the size of the product to be built;
2. the ability to translate the size estimate into human effort, calendar time, and dollars
3. the degree to which the project plan reflects the abilities of the software team; and
4. the stability of product requirements and the environment that supports the software
engineering effort.
Software Sizing
Project estimate is only as good as the estimate of the size of the work to be accomplished,
sizing represents your first major challenge as a planner.
In the context of project planning, size refers to a quantifiable outcome of the software
project.
If a direct approach is taken, size can be measured in lines of code (LOC).
If an indirect approach is chosen, size is represented as function points (FP).

Problem-Based Estimation
Precise estimation is difficult. So, make three estimates: optimistic, most likely, and
pessimistic. Then combine as:
EV=(Sopt + 4Sm + Spess)/6

An example
• user interface and control facilities
• 2-D geometric analysis 3-D opt = 4600
• 3-D geometirc analysis 3-D m. likely = 6900
• database management 3-D pess. = 8600
• computer graphics display => (4600+4*6900+8600)/6
• peripheral control = 6800
• design analysis models
An Example of LOC-Based Estimation
• Suppose 620 LOC/PM, and $8,000/PM, based upon historical data. Then,
Est. Cost = 33,200*$8,000/620 = $421,000
An Example of FP-Based Estimation
Decomposition for FP-based

estimation focuses on
information domain values
rather than software
functions.
Each of the complexity weighting factors is estimated, and the value

adjustment factor is computed as described
An Example of FP-Based Estimation
The organizational average productivity

for systems of this type is 6.5 FP/pm.
Based on a burdened labor rate of
$8000 per month, the cost per FP is
approximately $1230.
Based on the FP estimate and the
historical productivity data, the total
estimated project cost is $461,000 and
the estimated effort is 58 person-
months.
An Example of Process-Based Estimation
• The most common technique for estimating a project

is to base the estimate on the process that will be
used.
• That is, the process is decomposed into a relatively
small set of tasks and the effort required to
accomplish each task is estimated.
Based on an average burdened labor rate of $8000 per month, the total estimated
project cost is $368,000 and the estimated effort is 46 person-months. If desired,
labor rates could be associated with each framework activity or software engineering task and
computed separately.
Estimation with Use Cases
Use cases provide a software team with insight into software scope and requirements. However,
developing an estimation approach with use cases is problematic for the following reasons.
• Use cases are described using many different formats and styles—there is no standard form.
• Use cases represent an external view (the user’s view) of the software and can therefore be written at
many different levels of abstraction.
• Use cases do not address the complexity of the functions and features that are described.
• Use cases can describe complex behavior (e.g., interactions) that involve many functions and features.
Estimation with Use Cases
Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of
$8000 per month, the cost per line of code is approximately $13. Based on the use-case estimate and
the historical productivity data, the total estimated project cost is $552,000 and the estimated effort
is 68 person/months.
EMPIRICAL ESTIMATION MODELS
• Empirical estimation is a technique or model in which empirically derived formulas are used for
predicting the data that are a required and essential part of the software project planning step.
• These techniques are usually based on the data that is collected previously from a project and also based
on some guesses, prior experience with the development of similar types of projects, and assumptions.
• It uses the size of the software to estimate the effort.

The Structure of Estimation Models
A typical estimation model is derived using regression analysis on data collected from past software
projects. The overall structure of such models takes the form
E =A+ Bx(ev)C
A, B, and C are empirically derived constants, E is effort in person-months,
Some examples and ev is the estimation variable
E = 5.2×(KLOC)0.91 Walston-Felix Model
E = 5.5 + 0.73×(KLOC)1.16 Bailey-Basili Model
E = 3.2×(KLOC)1.05 Boehm simple model
E = 5.288×(KLOC)1.047 Doty model for KLOC > 9
E = -13.39 + 0.0545×FP Albrecht & Gaffney
E = 60.62 + 7.728×10-8FP3 Kemerer Model
E = 585.7 + 15.12×FP Albrecht & Gaffney
The COCOMO II Model (COnstructive COst MOdel)
• The original COCOMO model became one of the most widely used and discussed
software cost estimation models in the industry.
• It has evolved into a more comprehensive estimation model, called COCOMOII.

COCOMO II is actually a hierarchy of estimation models that address the following areas:
• Application composition model. Used during the early stages of software engineering, when prototyping
of user interfaces, consideration of software and system interaction, assessment of performance, and
evaluation of technology maturity are paramount.
• Early design stage model. Used once requirements have been stabilized and basic software architecture
has been established.
• Post-architecture-stage model. Used during the construction of the software
Like all estimation models for software, the COCOMO II models require sizing information. Three different
sizing options are available as part of the model hierarchy: object points, function points, and lines of
source code.
The COCOMO II application composition model uses object points. The object point is an indirect
software measure that is computed using counts of the number of
(1) Screens (at the user interface),
(2) Reports, and
(3) Components likely to be required to build the application.
The object point count is then determined by multiplying the original number of object instances by the
weighting factor in the figure and summing to obtain a total object point count.
When component-based development or general software reuse is to be applied, the percent of reuse
(%reuse) is estimated and the object point count is adjusted:
NOP = (object points) X [(100 - %reuse)/100]
where NOP is defined as new object points.

To derive an estimate of effort based on the computed NOP value, a “productivity rate” must be derived
PROD = NOP / person-month
For different levels of developer experience and development environment maturity.
Once the productivity rate has been determined, an estimate of project effort is computed using
Estimated effort = NOP/ PROD
In more advanced COCOMO II models,12 a variety of scale factors, cost drivers, and adjustment procedures
are required.
THE MAKE/BUY DECISION
In many software application areas, it is often more cost effective to acquire rather than develop computer
software.
Software engineering managers are faced with a make/ buy decision that can be further complicated by a
number of acquisition options:
(1) software may be purchased (or licensed) off-the-shelf,

(2) “full-experience” or “partial-experience” software components may be acquired and
then modified and integrated to meet specific needs, or
(3) Software may be custom built by an outside contractor to meet the purchaser’s
specifications.
In the final analysis, the make/buy decision is made based on the following conditions:
(1) Will the delivery date of the software product be sooner than that for internally
developed software?
(2) Will the cost of acquisition plus the cost of customization be less than the cost of
developing the software internally?
(3) Will the cost of outside support (e.g., a maintenance contract) be less than the cost of
internal support? These conditions apply for each of the acquisition options.
Decision Tree
decision tree for a software based system X. In this case, the software engineering
organization can
(1) build system X from scratch,
(2) reuse existing partial-experience components to construct the system,
(3) buy an available software product and modify it to meet local needs,or
(4) contract the software development to an outside vendor.
Expected cost = (path probability)i * (estimated path cost)i

where i is the decision tree path.
For the build path,

Expected costbuild 0.30 ($380K) 0.70 ($450K) $429K
The expected costs for these paths are
Expected cost
reuse 0.40 ($275K) 0.60 [0.20 ($310K) 0.80 ($490K)] $382K
Expected cost buy 0.70 ($210K) 0.30 ($400K) $267K
Expected cost contract 0.60 ($350K) 0.40 ($500K) $410K
PROJECT SCHEDULING AND TRACKING
What is it?
• Selected an appropriate process model,
• identified the software engineering tasks that have to be performed,
• estimated the amount of work and the number of people, know the deadline, you’ve even
considered the risks.
Now it’s time to connect the dots.
That is, to create a network of software engineering tasks that will enable to get the job done on
time.
Once the network is created, have to assign responsibility for each task, make sure it gets done,
and adapt the network as risks become reality. In a nutshell, that’s software project scheduling
and tracking.
Basic problem -- Software is almost always late
• An unrealistic deadline established

• Changing customer requirements
• An honest underestimate of the amount of effort and/or the number of resources that will be required
to do the job.
• Predictable and/or unpredictable risks that were not considered when the project commenced.
• Technical difficulties that could not have been foreseen in advance.
• Human difficulties that could not have been foreseen in advance.
• Miscommunication among project staff that results in delays.
• A failure by project management to recognize that the project is falling behind schedule and a lack of
action to correct the problem.
An approach to unrealistic deadlines -- project redefinition
• Perform detailed estimate based on previous projects
• Use incremental process to deliver critical functionality on time
• Meet with customer (which may be upper management)
• Offer incremental
Basic Principles
• Compartmentalization
• Identify task interdependencies
• Allocate time for each task
• Develop feasible schedule
• Define responsibilities
• Define outcomes
• Define milestones
Relation Between People vs. Effort
• Adding people to a project increases communication requirements

Recall the software equation -- E=[LOC * B0.333/P]3 * (1/t4), where
E = effort in person months
t = project duration in months
B = “special skills factor” For KLOC (5, 15) use 0.16, for KLOC > 70, use B = 0.39
P = “productivity parameter”
Decreasing the time to complete the project requires more people, but look at the
exponential nature of the relationship!
Effort distribution -- often as little as 10% goes into coding.

DEFINING A TASK SET FOR THE SOFTWARE PROJECT
In order to develop a project schedule, a task set must be distributed on the project time line. The task
set will vary depending upon the project type and the degree of rigor with which the software team
decides to do its work.
• Types of projects
– Concept development
– New application development projects
– Application enhancement projects
– Application maintenance projects
– Reengineering projects There can be a progression through these kinds of projects
These can be approached with different levels of rigor:
• casual
• Structured
• Strict
• Quick Reaction
Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort.
• Program evaluation and review technique (PERT) and the critical path method (CPM) are two project
scheduling methods that can be applied to software development.
• Both techniques are driven by information already developed in earlier project planning activities:
estimates of effort, a decomposition of the product function, the selection of the appropriate process
model and task set, and decomposition of the tasks that are selected.
• Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the
project work breakdown structure (WBS), are defined for the product as a whole or for individual
functions.
Both PERT and CPM provide quantitative tools that allow you to
(1) determine the critical path—the chain of tasks that determines the duration of the project,
(2) Establish “most likely” time estimates for individual tasks by applying statistical models, and
(3) calculate “boundary times” that define a time “window” for a particular task.
Time-Line Charts
When creating a software project schedule, you begin with a set of tasks (the work breakdown structure). If
automated tools are used, the work breakdown is input as task network or task outline. Effort, duration, and
start date are then input for each task. In addition, tasks may be assigned to specific individuals.
time-line chart, also called a Gantt chart, is generated. A time-line chart can be developed for the
entire project.
Time-Line Charts
Time-Line Charts
Tracking can be accomplished in a number of different ways:

• Conducting periodic project status meetings in which each team member reports progress and problems
• Evaluating the results of all reviews conducted throughout the software engineering process
• Determining whether formal project milestones have been accomplished by the scheduled date
• Comparing the actual start date to the planned start date for each project task listed in the resource tab
• Meeting informally with practitioners to obtain their subjective assessment of progress to date and
problems on the horizon
• Using earned value analysis to assess progress quantitatively In reality, all of these tracking techniques are
used by experienced project managers.
RISK MANAGEMENT
What is it?
Risk analysis and management are actions that help a software team to understand and manage
uncertainty. Many problems can plague a software project. A risk is a potential problem—it might happen,
it might not. But, regardless of the outcome, it’s a really good idea to identify it, assess its probability of
occurrence, estimate its impact, and establish a contingency plan should the problem actually occur.
RISK MANAGEMENT
Reactive Risk Strategy: A reactive risk strategy involves responding to risks after they occur. In
this approach, organizations or individuals take actions to mitigate or address risks once they
have already materialized. Reactive strategies are often characterized by a "firefighting"
mentality, where efforts are focused on containing and minimizing the negative impacts of risks.
Proactive Risk Strategy: On the other hand, a proactive risk strategy involves anticipating and
addressing risks before they occur. This approach emphasizes preventive measures and proactive
planning to minimize the likelihood and potential impacts of risks. Proactive strategies aim to
identify and assess risks in advance, implement preventive controls, and develop contingency
plans to effectively manage and mitigate risks.
RISK MANAGEMENT
SOFTWARE RISKS
• Software risks refer to potential threats or uncertainties associated with the development, deployment,
and operation of software systems.
• These risks can arise from various factors, including technical complexities, inadequate planning, human
errors, external dependencies, or changing requirements.
• Managing software risks is crucial to ensure the successful delivery of software projects and the reliable
operation of software systems.
RISK MANAGEMENT
SOFTWARE RISKS
Some common types of software risks include:
Technical Risks: These risks are related to technical challenges and complexities in software development.
They may include issues with software architecture, integration problems, performance bottlenecks,
security vulnerabilities, or compatibility issues.
Requirements Risks: Risks associated with requirements include incomplete, ambiguous, or changing
requirements. Inadequate understanding of user needs and expectations can lead to software that does
not meet desired functionalities or fails to address user requirements effectively.
Schedule and Cost Risks: These risks involve project scheduling and budget constraints. Factors such as
inaccurate estimations, resource constraints, delays in development, or unexpected dependencies can lead
to project delays and cost overruns.
RISK MANAGEMENT
SOFTWARE RISKS
Some common types of software risks include:
Human Risks: Human-related risks encompass factors such as inadequate skills or experience of team
members, poor communication, lack of coordination, or mismanagement. These risks can impact the
quality and timely delivery of software projects.
External Risks: External risks are influenced by factors outside the direct control of the development team.
They may include changes in regulatory requirements, evolving technology standards, legal or compliance
issues, or dependencies on third-party components or services.
Security Risks: Security risks involve vulnerabilities or weaknesses in software systems that can be exploited
by attackers. These risks may lead to unauthorized access, data breaches, or other security incidents,
compromising the confidentiality, integrity, or availability of software and user data.
RISK MANAGEMENT
SOFTWARE RISKS
To manage software risks effectively, organizations employ risk management practices such as risk
identification, assessment, mitigation, and monitoring throughout the software development lifecycle.
This includes proactive measures such as conducting risk assessments, implementing preventive controls,
regularly reviewing and updating risk plans, and adopting best practices for software development, testing,
and security.
By addressing software risks proactively, organizations can minimize the negative impact on software
projects, enhance system reliability, and improve overall stakeholder satisfaction.
RISK MANAGEMENT
SOFTWARE RISKS
Risk identification
Risk identification is the process of systematically identifying and documenting potential risks
that may impact a project, organization, or specific activity.
It is an essential step in the risk management process and involves identifying both internal and
external risks that could affect the achievement of objectives or the successful completion of a
project.
There are two distinct types of risks for each of the categories generic risks and product-specific risks.
Generic risks are a potential threat to every software project.
Product-specific risks can be identified only by those with a clear understanding of the technology, the
people, and the environment that is specific to the software that is to be built.
RISK MANAGEMENT
SOFTWARE RISKS
RISK PROJECTION
Risk projection, also called risk

estimation, attempts to rate each risk in
two ways—
(1) the likelihood or probability that the
risk is real and
(2) the consequences of the problems
associated with the risk, should it
occur
RISK MANAGEMENT
SOFTWARE RISKS
RISK PROJECTION
Developing a Risk Table

A risk table provides you with a simple
technique for risk projection.
RISK MANAGEMENT
SOFTWARE RISKS
Risk identification. Only 70 percent of the software components scheduled
for reuse will, in fact, be integrated into the application. The remaining
functionality will have to be custom developed.
Risk probability. 80 percent (likely).
Risk impact. Sixty reusable software components were planned. If only
70 percent can be used, 18 components would have to be developed
from scratch (in addition to other custom software that has been
scheduled for development). Since the average component is 100 LOC
and local data indicate that the software engineering cost for each LOC
is $14.00, the overall cost (impact) to develop the components would be
18 100 14 $25,200.
Risk exposure. RE 0.80 25,200 $20,200.
RISK MANAGEMENT
SOFTWARE RISKS
RISK REFINEMENT
During early stages of project planning, a risk may be stated quite generally. As time passes and more is
learned about the project and the risk, it may be possible to refine the risk into a set of more detailed
risks, each somewhat easier to mitigate, monitor, and manage.
One way to do this is to represent the risk in condition-transition-consequence (CTC) format
Given that <condition> then there is concern that (possibly) <consequence>.

RISK MANAGEMENT
SOFTWARE RISKS
RISK MITIGATION, MONITORING, AND MANAGEMENT
• All of the risk analysis activities presented to this point have a single goal—to assist the project team in
developing a strategy for dealing with risk.
• An effective strategy must consider three issues: risk avoidance, risk monitoring, and risk management
and contingency planning.
• If a software team adopts a proactive approach to risk, avoidance is always the best strategy.
Risk mitigation refers to the process of taking proactive measures to reduce or eliminate
potential risks and their impacts. It involves identifying, assessing, and implementing
strategies to minimize the likelihood or severity of risks. The goal of risk mitigation is to
enhance project or organizational resilience and ensure that potential risks are managed
effectively.
RISK MANAGEMENT
SOFTWARE RISKS
Risk-monitoring activities - The project manager monitors factors that may provide an indication of
whether the risk is becoming more or less likely.
• Risk-monitoring activities are essential for effective risk management.
• They involve the ongoing assessment and tracking of identified risks throughout the lifecycle of a
project, process, or organization.
• The purpose of risk monitoring is to stay informed about the current status of risks, identify any
changes or new risks, and take appropriate actions to address them.
RISK MANAGEMENT
SOFTWARE RISKS
Risk management and contingency planning assumes that mitigation efforts have failed and that the risk
has become a reality.
• It involves a systematic approach to understanding and addressing uncertainties that could affect
the achievement of project objectives or organizational goals
• risk management process, organizations can enhance their ability to identify and address potential
risks, minimize negative impacts, and make informed decisions that improve overall project success
and organizational resilience.
RISK MANAGEMENT
SOFTWARE RISKS
THE RMMM PLAN
A risk management strategy can be included in the software project plan, or the risk management steps
can be organized into a separate risk mitigation, monitoring, and management plan (RMMM).
The RMMM plan documents all work performed as part of risk analysis and is used by the project
manager as part of the overall project plan. Rather, each risk is documented individually using a risk
information sheet.
Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps
commence. Risk mitigation is a problem avoidance activity. Risk monitoring is a project tracking activity
with three primary objectives:
(1) to assess whether predicted risks do, in fact, occur;
(2) to ensure that risk aversion steps defined for the risk are being properly applied; and
(3) to collect information that can be used for future risk analysis.
RISK MANAGEMENT
SOFTWARE RISKS
THE RMMM PLAN
MAINTENANCE & REENGINEERING
What is it?
Consider any technology product that has served well. Use it regularly, but it’s getting old. It
breaks too often, takes longer to repair than you’d like, and no longer represents the newest
technology.
What to do? For a time, try to fix it, patch it, even extend its functionality. That’s called
maintenance.
But maintenance becomes increasingly difficult as the years pass. There comes a time when
need to rebuild it. Create a product with added functionality, better performance and
reliability, and improved maintainability. That’s what we call reengineering.
Software Maintenance
• Software is released to end-users, and
– Within days, bug reports filter back to the software engineering organization.
– Within weeks, one class of users indicates that the software must be changed so that it can
accommodate the special needs of their environment.
– Within months, another corporate group who wanted nothing to do with the software when
it was released, now recognizes that it may provide them with unexpected benefit.
– They’ll need a few enhancements to make it work in their world.
• All this work is software maintenance

Software Maintenance
It encompasses a set of processes, practices, and activities aimed at ensuring the proper
functioning, performance, and evolution of software throughout its lifecycle.
What is maintainability?
Maintainable software exhibits effective modularity.
• It makes use of design patterns that allow ease of understanding. It has been constructed using well-
defined coding standards and conventions, leading to source code that is self-documenting and
understandable.
• It has undergone a variety of quality assurance techniques that have uncovered potential maintenance
problems before the software is released. It has been created by software engineers who recognize that
they may not be around when changes must be made.
• Therefore, the design and implementation of the software must “assist” the person who is making the
change.
SOFTWARE SUPPORTABILITY
“The capability of supporting a software system over its whole product life.
This implies satisfying any necessary needs or requirements, but also the provision of equipment,
support infrastructure, additional software, facilities, manpower, or any other resource required to
maintain the software operational and capable of satisfying its function.
The software should contain facilities to assist support personnel when a defect is encountered in the
operational environment (and make no mistake, defects will be encountered).
Reengineering
Reengineering, also known as software reengineering or software system reengineering, is the process of
analyzing and modifying an existing software system to improve its functionality, performance,
maintainability, or other attributes.
It involves making significant changes to the software's structure, architecture, or codebase while
retaining its original functionality and purpose.
Reengineering is typically done to address issues such as software aging, technological obsolescence,
poor maintainability, or evolving business requirements.
Reengineering
BUSINESS PROCESS REENGINEERING

• Business Process Reengineering (BPR) is a strategic
approach to redesigning and improving business
processes within an organization to achieve significant
enhancements in performance, efficiency, and
customer satisfaction.
• It involves the analysis, rethinking, and radical redesign
of core business processes to achieve dramatic
improvements in productivity, quality, and competitive
advantage.
• BPR aims to challenge existing practices, eliminate
non-value-added activities, and leverage technology
and innovation to transform the way work is done.
Reengineering
SOFTWARE REENGINEERING
• Is the process of modifying or restructuring existing
software systems to improve their maintainability,
reliability, performance, and functionality.
• It involves analyzing, understanding, and making
changes to the software code, architecture, or
design without altering its external behavior or
purpose.
• Software reengineering aims to address issues such
as outdated technology, software aging, evolving
business requirements, or poor software quality.
Reengineering
SOFTWARE REENGINEERING
Inventory analysis. Every software organization should have an inventory of all applications. The inventory
can be nothing more than a spreadsheet model containing information that provides a detailed
description (e.g., size, age, business criticality) of every active application.
By sorting this information according to business criticality, longevity, current maintainability and
supportability, and other locally important criteria, candidates for reengineering appear.
Resources can then be allocated to candidate applications for reengineering work.

Reengineering
Document restructuring.
• It involves making changes to the document's headings, sections, paragraphs, formatting, and overall
flow to enhance readability and facilitate understanding.
• Document restructuring is often done to improve the document's logical structure, navigation, and
accessibility for the intended audience
• By restructuring a document, it becomes more organized, user-friendly, and effective in conveying
information to the intended audience.
• It improves readability, facilitates comprehension, and enhances the overall impact and usability of the
document.
Reengineering
Reverse engineering
• Reverse engineering is the process of analyzing and understanding the design, structure, and
functionality of a product, system, or software by examining its components, behavior, and information
flow.
• It involves working backward from the end product to uncover its internal workings, often without
access to the original design documentation or source code.
• Reverse engineering is a process of design recovery.
• Reverse engineering tools extract data, architectural, and procedural design information from an existing
program.
Reengineering
Code restructuring
• The most common type of reengineering (actually, the use of the term reengineering is questionable in
this case) is code restructuring.
• Some legacy systems have a relatively solid program architecture, but individual modules were coded
in a way that makes them difficult to understand, test, and maintain. In such cases, the code within the
suspect modules can be restructured.
• To accomplish this activity, the source code is analyzed using a restructuring tool.
• Violations of structured programming constructs are noted and code is then restructured (this can be
done automatically) or even rewritten in a more modern programming language.
• The resultant restructured code is reviewed and tested to ensure that no anomalies have been
introduced. Internal code documentation is updated.
Reengineering
Data restructuring.
• A program with weak data architecture will be difficult to adapt and enhance. In fact, for many
applications, information architecture has more to do with the long-term viability of a program than the
source code itself.
• Data restructuring is a full-scale reengineering activity. In most cases, data restructuring begins with a
reverse engineering activity.
• Current data architecture is dissected, and necessary data models are defined. Data objects and
attributes are identified, and existing data structures are reviewed for quality.
• When data structure is weak the data are reengineered.
• Because data architecture has a strong influence on program architecture and the algorithms that
populate it, changes to the data will invariably result in either architectural or code-level changes.
Reengineering
Forward engineering
• Forward engineering, also known as forward design, is the traditional process of designing, developing,
and implementing a new product, system, or software from scratch.
• It involves starting with a conceptual idea or set of requirements and then progressing through various
stages to create a final product that meets those requirements.
• Forward engineering not only recovers design information from existing software but uses this
information to alter or reconstitute the existing system in an effort to improve its overall quality.
• In most cases, reengineered software reimplements the function of the existing system and also adds
new functions and/or improves overall performance.
THANK YOU

Unit 3

Uploaded by

Copyright:

Available Formats

You might also like

Unit 3

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 3

Uploaded by

Copyright:

Available Formats

SOFTWARE ENGINEERING

Agile Implementation and Managing Software Products:

Agile is an approach to project management that leans heavily on

• Agile is an ability to adapt or to create and respond to

• It basically means to understand the changes and uncertainty

• Keeping this thought in mind, the software developers build

• Accelerate software delivery.

The top benefits realized are the ability to:

• Manage changing priorities.

Effective (rapid and adaptive) response to change

• Agile prioritizes flexibility and continuous improvement

• Small working teams used to maximize communication and minimize overhead

Step4: Hold the Sprint Planning Meeting

Step 5 : Hold the Daily Standup Meetings

Step 6 : View the Burndown Chart

Step 7: Hold the Sprint Review Meeting

Step 8: Hold the Sprint Retrospective Meeting

What is Extreme Programming?

• Save costs and time

• This methodology does not measure code quality assurance

• It may cause defects in the initial code.

• XP is not the best option if programmers are separated geographically.

❖ Senior Managers - who define business issues.

❖ Technical leadership model

• Difficulty of problem to be solved.

Informal, interpersonal procedures - group meetings

Must first determine project scope.

❖Select a software engineering model.

❖ Planning -- determine resources, time line & other info.

❖ Risk analysis -- assess technical and management risks

❖ Engineering -- build one or more representations of the product.

❖ Customer evaluation -- obtain feedback on product

• Tasks – the details of what needs to be done

The four basic steps in Software Project Estimation are −

• Estimate the size of the development product.

The plan must be adapted and updated as the project proceeds.

Task Set for Project Planning 5. Estimate cost and effort.

To achieve reliable cost and effort estimates, a number of options arise

• For this reason, it is must to decompose the problem, recharacterizing it as a set of

The accuracy of a software project estimate is predicated on a number of things:

If an indirect approach is chosen, size is represented as function points (FP).

EV=(Sopt + 4Sm + Spess)/6

Decomposition for FP-based

Each of the complexity weighting factors is estimated, and the value

The organizational average productivity

• The most common technique for estimating a project

• It uses the size of the software to estimate the effort.

• It has evolved into a more comprehensive estimation model, called COCOMOII.

NOP = (object points) X [(100 - %reuse)/100]

where NOP is defined as new object points.

PROD = NOP / person-month

For different levels of developer experience and development environment maturity.

Estimated effort = NOP/ PROD

(1) software may be purchased (or licensed) off-the-shelf,

Expected cost = (path probability)i * (estimated path cost)i

For the build path,

Now it’s time to connect the dots.