2. Objectives
To understand the phases in a software project
To understand fundamental concepts of
requirements engineering and Analysis Modeling.
To understand the basics of object oriented
concept
To understand the major considerations for
enterprise integration and deployment.
To learn various testing and project management
techniques
3. COURSE OUTCOMES
CO. NO. COURSE OUTCOME
BLOOM
S LEVEL
At the end of the course students will be able to
CO 1 Compare different process models. C4
CO 2
Formulate Concepts of requirements engineering
and Analysis Modeling.
C4
CO 3
To understand the fundamentals of object
oriented concept
C3
CO 4 Apply systematic procedure for software design C4
CO 5 Find errors with various testing techniques C4
CO6 Evaluate project schedule, estimate project cost
and effort required
C5
4. Syllabus
UNIT-I Software Process and Agile Development 9
Introduction to Software Engineering, Software Process, Perspective and Specialized
Process Models – Introduction to Agility – Agile process – Extreme programming –
XP process - Estimation-FP,LOC and COCOMO I and II, Risk Management, Project
Scheduling.
.
UNIT-IIRequirements Analysis and Specification 9
Software Requirements: Functional and Non-Functional, User requirements,
Software Requirements Document – Requirement Engineering Process: Feasibility
Studies, Requirements elicitation and analysis, requirements validation, requirements
management-Classical analysis: Structured system Analysis, Petri Nets
UNIT III- Object Oriented Concepts 9
Introduction to OO concepts, UML Use case Diagram,Class Diagram-Object
Diagram-Component Diagram-Sequence and Collaboration-Deployment-Activity
Diagram-Package Diagram
5. Syllabus
UNIT-IV Software Design 9
Design Concepts- Design Heuristic – Architectural Design –Architectural styles,
Architectural Design, Architectural Mapping using Data Flow- User Interface
Design: Interface analysis, Interface Design –Component level Design: Designing
Class based components.
UNIT-VTesting and Management 9
Software testing fundamentals- white box testing- basis path testing-control
structure testing-black box testing- Regression Testing – Unit Testing –
Integration Testing – Validation Testing – System Testing And Debugging –
Reengineering process model – Reverse and Forward Engineering.
Total: 45 Periods
6. Syllabus
LEARNING RESOURCES:
TEXT BOOKS
1.Roger S. Pressman, “Software Engineering – A Practitioner’s Approach”, Eighth Edition,
McGraw-Hill International Edition, 2019.(Unit I,II,IV,V)
2. Ian Sommerville, “Software Engineering”, Global Edition, Pearson Education Asia,
2015.(Unit I,II,III)
3.Bernd Bruegge& Allen H. Dutoit Object-oriented software engineering using UML,
patterns, and Java ,Prentice hall ,3rd Edition 2010.(Unit III)
REFERENCES
1.Titus Winters,Tom Manshreck& Hyrum Wright, Software Engineering at Google,lessons
learned from programming over time, O’ REILLY publications,2020. (Unit I,II,IV,V)
2.Rajib Mall, “Fundamentals of Software Engineering”, Third Edition, PHI Learning
Private Limited, 2009. (Unit I,II,IV,V)
3.PankajJalote, “Software Engineering, A Precise Approach”, Wiley India, 2010 (Unit
I,II,IV,V)
ONLINE LINKS
1.http://www.nptelvideos.in/2012/11/software-engineering.html
2. https://nptel.ac.in/courses/106/101/106101061/
8. What is Software?
8
The product that software professionals build and then
support over the long term.
Software encompasses: (1) instructions (computer
programs) that when executed provide desired features,
function, and performance; (2) data structures that enable
the programs to adequately store and manipulate
information and (3) documentation that describes the
operation and use of the programs.
9. 9
What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...
10. 10
Software’s Dual Role
• Software is a product
– Produces, manages, acquires, modifies, displays,
or transmits information
• Software is a vehicle for delivering a product
– Supports or directly provides system functionality
– Controls other programs (e.g., an operating
system)
– Effects communications (e.g., networking
software)
– Helps build other software (e.g., software tools)
11. 11
What Is Software?
Is the Product that SW engineers Design and Build.
it encompasses:
Instructions “Computer Programs”
Documents “Describe Programs”
Architecture including Data Structures “Enable Programs”
Logical rather than physical
12. 12
Software vs. Hardware
• software is engineered not manufactured
• software doesn’t wear out
• Software is custom build
14. Software products
• Generic products
– Stand-alone systems that are marketed and sold to any
customer who wishes to buy them.
– Examples – PC software such as editing, graphics
programs, project management tools; CAD software;
software for specific markets such as appointments systems
for dentists.
• Customized products
– Software that is commissioned by a specific customer to
meet their own needs.
– Examples – embedded control systems, air traffic control
software, traffic monitoring systems.
14
15. Why Software is Important?
• The economies of ALL developed nations are
dependent on software.
• More and more systems are software controlled
(transportation, medical, telecommunications, military,
industrial, entertainment,)
• Software engineering is concerned with theories,
methods and tools for professional software
development.
• Expenditure on software represents a
significant fraction of GNP in all developed countries.
16. Software costs
• Software costs often dominate computer
system costs. The costs of software on a PC
are often greater than the hardware cost.
• Software costs more to maintain than it does
to develop. For systems with a long life,
maintenance costs may be several times
development costs.
• Software engineering is concerned with cost-
effective software development.
17. Features of Software?
• Its characteristics that make it different from other things human being
build.
Features of such logical system:
• Software is developed or engineered, it is not manufactured in the
classical sense which has quality problem.
• Software doesn't "wear out.” but it deteriorates (due to change). Hardware
has bathtub curve of failure rate ( high failure rate in the beginning, then drop to
steady state, then cumulative effects of dust, vibration, abuse occurs).
• Although the industry is moving toward component-based construction
(e.g. standard screws and off-the-shelf integrated circuits), most
software continues to be custom-built. Modern reusable components
encapsulate data and processing into software parts to be reused by
different programs. E.g. graphical user interface, window, pull-down
menus in library etc.
17
18. Software Applications
1. System software: such as compilers, editors, file
management utilities
2. Application software: stand-alone programs for
specific needs.
3.Engineering/scientific software: Characterized by
“number crunching”algorithms. such as automotive
stress analysis, molecular biology, orbital dynamics etc
4. Embedded software resides within a product or system.
(key pad control of a microwave oven, digital function
of dashboard display in a car).
18
19. Software Applications
5. Product-line software focus on a limited marketplace
to address mass consumer market. (word processing,
graphics, database management)
6. WebApps (Web applications) network centric software.
As web 2.0 emerges, more sophisticated computing
environments is supported integrated with remote
database and business applications.
7. AI software uses non-numerical algorithm to solve
complex problem. Robotics, expert system, pattern
recognition game playing
19
20. The IEEE definition:
Software Engineering: (1) The application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the
application of engineering to software. (2) The study of
approaches as in (1).
The seminal definition:
[Software engineering is] the establishment and use of sound
engineering principles in order to obtain economically
software that is reliable and works efficiently on real
machines.
Software Engineering Definition
21. Importance of Software Engineering
• More and more, individuals and society rely on
advanced software systems. We need to be able to
produce reliable and trustworthy systems
economically and quickly.
• It is usually cheaper, in the long run, to use software
engineering methods and techniques for software
systems rather than just write the programs as if it
was a personal programming project. For most types
of system, the majority of costs are the costs of
changing the software after it has gone into use.
21
22. FAQ about software engineering
22
Question Answer
What is software?
Computer programs, data structures and associated
documentation. Software products may be developed
for a particular customer or may be developed for a
general market.
What are the attributes of good
software?
Good software should deliver the required
functionality and performance to the user and should
be maintainable, dependable and usable.
What is software engineering?
Software engineering is an engineering discipline that
is concerned with all aspects of software production.
What is the difference between software
engineering and computer science?
Computer science focuses on theory and
fundamentals; software engineering is concerned with
the practicalities of developing and delivering useful
software.
What is the difference between software
engineering and system engineering?
System engineering is concerned with all aspects of
computer-based systems development including
hardware, software and process engineering. Software
engineering is part of this more general process.
23. Essential attributes of good software
23
Product characteristic Description
Maintainability
Software should be written in such a way so that it can evolve to
meet the changing needs of customers. This is a critical
attribute because software change is an inevitable requirement
of a changing business environment.
Dependability and
security
Software dependability includes a range of characteristics
including reliability, security and safety. Dependable software
should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or
damage the system.
Efficiency
Software should not make wasteful use of system resources
such as memory and processor cycles. Efficiency therefore
includes responsiveness, processing time, memory utilisation,
etc.
Acceptability
Software must be acceptable to the type of users for which it is
designed. This means that it must be understandable, usable
and compatible with other systems that they use.
24. A Layered Technology
24
a “quality” focus
process model
methods
tools
Any engineering approach must rest on organizational commitment to quality which
fosters a continuous process improvement culture.
Process layer as the foundation defines a framework with activities for effective delivery of
software engineering technology. Establish the context where products (model, data,
report, and forms) are produced, milestone are established, quality is ensured and change
is managed.
Method provides technical how-to’s for building software. It encompasses many tasks
including communication, requirement analysis, design modeling, program construction,
testing and support.
Tools provide automated or semi-automated support for the process and methods.
25. Software Process
• A process is a collection of activities, actions and
tasks that are performed when some work product is
to be created. It is not a rigid prescription for how
to build computer software. Rather, it is an adaptable
approach that enables the people doing the work to
pick and choose the appropriate set of work actions
and tasks.
• Purpose of process is to deliver software in a timely
manner and with sufficient quality to satisfy those
who have sponsored its creation and those who will
use it.
25
26. Five Activities of a Generic Process
Framework
• Communication: communicate with customer to understand objectives and
gather requirements
• Planning: creates a “map” defines the work by describing the tasks, risks
and resources, work products and work schedule.
• Modeling: Create a “sketch”, what it looks like architecturally, how the
constituent parts fit together and other characteristics.
• Construction: code generation and the testing.
• Deployment: Delivered to the customer who evaluates the products and
provides feedback based on the evaluation.
• These five framework activities can be used to all software development
regardless of the application domain, size of the project, complexity of the
efforts etc, though the details will be different in each case.
• For many software projects, these framework activities are applied
iteratively as a project progresses. Each iteration produces a software
increment that provides a subset of overall software features and
functionality. 26
27. 27
SE Activities
Com m unic at ion
Planning
Modeling
Const r uc t ion
Deploy m ent
analysis
design
code
t est
projec t init iat ion
requirem e
nt gat hering estimating
scheduling
tracking
deliv ery
s upport
f eedbac k
Each phase has three components:
1. Set of activities - This is what you do
2. Set of deliverables - This is what you produce.
3. Quality Control Measures - This is what you use to evaluate the deliverables.
28. Umbrella Activities
Complement the five process framework activities and help team manage and
control progress, quality, change, and risk.
• Software project tracking and control: assess progress against the plan and
take actions to maintain the schedule.
• Risk management: assesses risks that may affect the outcome and quality.
• Software quality assurance: defines and conduct activities to ensure quality.
• Technical reviews: assesses work products to uncover and remove errors
before going to the next activity.
• Measurement: define and collects process, project, and product measures to
ensure stakeholder’s needs are met.
• Software configuration management: manage the effects of change
throughout the software process.
• Reusability management: defines criteria for work product reuse and
establishes mechanism to achieve reusable components.
• Work product preparation and production: create work products such as
models, documents, logs, forms and lists.
28
29. Prescriptive Process Models
- Generic process framework (revisited)
- Traditional process models
- Specialized process models
- The unified process
30. 30
Generic Process Framework
• Communication
– Involves communication among the customer and other stake holders;
encompasses requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule
• Modeling (Analyze, Design)
– Encompasses the creation of models to better under the requirements and
the design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and feedback
31. 31
Modeling: Software Requirements
Analysis
• Helps software engineers to better understand the problem they will
work to solve
• Encompasses the set of tasks that lead to an understanding of what
the business impact of the software will be, what the customer wants,
and how end-users will interact with the software
• Uses a combination of text and diagrams to depict requirements for
data, function, and behavior
– Provides a relatively easy way to understand and review requirements for
correctness, completeness and consistency
32. 32
Modeling: Software Design
• Brings together customer requirements, business needs, and technical
considerations to form the “blueprint” for a product
• Creates a model that that provides detail about software data structures,
software architecture, interfaces, and components that are necessary to
implement the system
• Architectural design
– Represents the structure of data and program components that are required to
build the software
– Considers the architectural style, the structure and properties of components that
constitute the system, and interrelationships that occur among all architectural
components
• User Interface Design
– Creates an effective communication medium between a human and a computer
– Identifies interface objects and actions and then creates a screen layout that forms
the basis for a user interface prototype
• Component-level Design
– Defines the data structures, algorithms, interface characteristics, and
communication mechanisms allocated to each software component
34. 34
Prescriptive Process Model
• Defines a distinct set of activities, actions, tasks, milestones, and work
products that are required to engineer high-quality software
• The activities may be linear, incremental, or evolutionary
36. 36
Waterfall Model
(Description)
• Oldest software lifecycle model and best understood by upper management
• Used when requirements are well understood and risk is low
• Work flow is in a linear (i.e., sequential) fashion
• Used often with well-defined adaptations or enhancements to current
software
37. 37
Waterfall Model
(Problems)
• Doesn't support iteration, so changes can cause confusion
• Difficult for customers to state all requirements explicitly and up front
• Requires customer patience because a working version of the program
doesn't occur until the final phase
• Problems can be somewhat alleviated in the model through the addition of
feedback loops (see the next slide)
38. 38
Waterfall Model with Feedback
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
40. 40
Incremental Model
(Description)
• Used when requirements are well understood
• Multiple independent deliveries are identified
• Work flow is in a linear (i.e., sequential) fashion within an increment and is
staggered between increments
• Iterative in nature; focuses on an operational product with each increment
• Provides a needed set of functionality sooner while delivering optional
components later
• Useful also when staffing is too short for a full-scale development
42. 42
Prototyping Model
(Description)
• Follows an evolutionary and iterative approach
• Used when requirements are not well understood
• Serves as a mechanism for identifying software requirements
• Focuses on those aspects of the software that are visible to the
customer/user
• Feedback is used to refine the prototype
43. 43
Prototyping Model
(Potential Problems)
• The customer sees a "working version" of the software, wants to stop all
development and then buy the prototype after a "few fixes" are made
• Developers often make implementation compromises to get the software
running quickly (e.g., language choice, user interface, operating system
choice, inefficient algorithms)
• Lesson learned
– Define the rules up front on the final disposition of the prototype before it is
built
– In most circumstances, plan to discard the prototype and engineer the actual
production software with a goal toward quality
45. 45
Spiral Model
(Description)
• Invented by Dr. Barry Boehm in 1988 while working at TRW
• Follows an evolutionary approach
• Used when requirements are not well understood and risks are high
• Inner spirals focus on identifying software requirements and project risks; may
also incorporate prototyping
• Outer spirals take on a classical waterfall approach after requirements have
been defined, but permit iterative growth of the software
• Operates as a risk-driven model…a go/no-go decision occurs after each
complete spiral in order to react to risk determinations
• Requires considerable expertise in risk assessment
• Serves as a realistic model for large-scale software development
46. 46
General Weaknesses of
Evolutionary Process Models
1) Prototyping poses a problem to project planning because of the
uncertain number of iterations required to construct the product
2) Evolutionary software processes do not establish the maximum speed
of the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and extensibility, and
second on high quality
• We should prioritize the speed of the development over zero defects
• Extending the development in order to reach higher quality could result in
late delivery
48. 48
Component-based Development Model
• Consists of the following process steps
– Available component-based products are researched and evaluated for
the application domain in question
– Component integration issues are considered
– A software architecture is designed to accommodate the components
– Components are integrated into the architecture
– Comprehensive testing is conducted to ensure proper functionality
• Relies on a robust component library
• Capitalizes on software reuse, which leads to documented savings in
project cost and time
49. 49
Formal Methods Model
(Description)
• Encompasses a set of activities that leads to formal mathematical
specification of computer software
• Enables a software engineer to specify, develop, and verify a
computer-based system by applying a rigorous, mathematical
notation
• Ambiguity, incompleteness, and inconsistency can be discovered and
corrected more easily through mathematical analysis
• Offers the promise of defect-free software
• Used often when building safety-critical systems
50. 50
Formal Methods Model
(Challenges)
• Development of formal methods is currently quite time-consuming
and expensive
• Because few software developers have the necessary background to
apply formal methods, extensive training is required
• It is difficult to use the models as a communication mechanism for
technically unsophisticated customers
52. 52
Background
• Birthed during the late 1980's and early 1990s when object-oriented
languages were gaining wide-spread use
• Many object-oriented analysis and design methods were proposed;
three top authors were Grady Booch, Ivar Jacobson, and James
Rumbaugh
• They eventually worked together on a unified method, called the
Unified Modeling Language (UML)
– UML is a robust notation for the modeling and development of object-
oriented systems
– UML became an industry standard in 1997
– However, UML does not provide the process framework, only the
necessary technology for object-oriented development
53. 53
Background (continued)
• Booch, Jacobson, and Rumbaugh later developed the unified process,
which is a framework for object-oriented software engineering using
UML
– Draws on the best features and characteristics of conventional software
process models
– Emphasizes the important role of software architecture
– Consists of a process flow that is iterative and incremental, thereby
providing an evolutionary feel
• Consists of five phases: inception, elaboration, construction,
transition, and production
54. 54
Phases of the Unified Process
communication
planning
modeling
construction
deployment
Inception Elaboration
Construction
Transition
Production
55. 55
Inception Phase
• Encompasses both customer communication and planning activities of the
generic process
• Business requirements for the software are identified
• A rough architecture for the system is proposed
• A plan is created for an incremental, iterative development
• Fundamental business requirements are described through preliminary use
cases
– A use case describes a sequence of actions that are performed by a user
56. 56
Elaboration Phase
• Encompasses both the planning and modeling activities of the generic process
• Refines and expands the preliminary use cases
• Expands the architectural representation to include five views
– Use-case model
– Analysis model
– Design model
– Implementation model
– Deployment model
• Often results in an executable architectural baseline that represents a first cut
executable system
• The baseline demonstrates the viability of the architecture but does not
provide all features and functions required to use the system
57. 57
Construction Phase
• Encompasses the construction activity of the generic process
• Uses the architectural model from the elaboration phase as input
• Develops or acquires the software components that make each use-case
operational
• Analysis and design models from the previous phase are completed to reflect
the final version of the increment
• Use cases are used to derive a set of acceptance tests that are executed prior to
the next phase
58. 58
Transition Phase
• Encompasses the last part of the construction activity and the first part of the
deployment activity of the generic process
• Software is given to end users for beta testing and user feedback reports on
defects and necessary changes
• The software teams create necessary support documentation (user manuals,
trouble-shooting guides, installation procedures)
• At the conclusion of this phase, the software increment becomes a usable
software release
59. 59
Production Phase
• Encompasses the last part of the deployment activity of the generic process
• On-going use of the software is monitored
• Support for the operating environment (infrastructure) is provided
• Defect reports and requests for changes are submitted and evaluated
60. 60
Unified Process Work Products
• Work products are produced in each of the first four phases of the
unified process
• In this model, we will concentrate on the analysis model and the
design model work products
• Analysis model includes
– Scenario-based model, class-based model, and behavioral model
• Design model includes
– Component-level design, interface design, architectural design, and
data/class design
62. 62
The Manifesto for
Agile Software Development
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
•Individuals and interactions over processes and
tools
•Working software over comprehensive
documentation
•Customer collaboration over contract
negotiation
•Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.” Kent Beck et al
63. 63
What is
“Agility”?
• 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
65. 65
An Agile Process
• Is driven by customer descriptions of what is
required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy
emphasis on construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur
66. 66
Agility Principles - I
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face–to–face conversation.
67. 67
Agility Principles - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is
essential.
11. The best architectures, requirements, and designs emerge from
self–organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
68. 68
Human Factors
• the process molds to the needs of the people
and team, not the other way around
• key character must exist among the people on
an agile team and the team itself:
– Competence.
– Common focus.
– Collaboration.
– Decision-making ability.
– Fuzzy problem-solving ability.
– Mutual trust and respect.
– Self-organization.
69. 69
Extreme Programming (XP)
• The most widely used agile process, originally
proposed by Kent Beck
• XP Planning
– Begins with the creation of “user stories”
– Agile team assesses each story and assigns a cost
– Stories are grouped to for a deliverable increment
– A commitment is made on delivery date
– After the first increment “project velocity” is used
to help define subsequent delivery dates for other
increments
70. 70
Extreme Programming (XP)
• XP Design
– Follows the KIS principle
– Encourage the use of CRC cards
– For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
– Encourages “refactoring”—an iterative refinement of the internal
program design
• XP Coding
– Recommends the construction of a unit test for a store before coding
commences
– Encourages “pair programming”
• XP Testing
– All unit tests are executed daily
– “Acceptance tests” are defined by the customer and excuted to assess
customer visible functionality
71. 71
Extreme Programming (XP)
unit t est
cont inuous int egrat ion
accept ance t est ing
pair
programming
Release
user st ories
values
accept ance t est crit eria
it erat ion plan
simple design
CRC cards
spike solut ions
prot ot ypes
refact oring
software increment
project velocity computed
72. 72
Adaptive Software Development
• Originally proposed by Jim Highsmith
• ASD — distinguishing features
– Mission-driven planning
– Component-based focus
– Uses “time-boxing”
– Explicit consideration of risks
– Emphasizes collaboration for requirements gathering
– Emphasizes “learning” throughout the process
73. 73
Adaptive Software Development
adapt ive cycle planning
uses mission st at ement
project const raint s
basic requirement s
t ime-boxed release plan
Requirement s gat hering
JAD
mini-specs
component s implement ed/ t est ed
focus groups for feedback
formal t echnical reviews
post mort ems
software increment
adjustments for subsequent cycles
Release
74. 74
Dynamic Systems Development Method
• Promoted by the DSDM Consortium (www.dsdm.org)
• DSDM—distinguishing features
– Similar in most respects to XP and/or ASD
– Nine guiding principles
• Active user involvement is imperative.
• DSDM teams must be empowered to make decisions.
• The focus is on frequent delivery of products.
• Fitness for business purpose is the essential criterion for acceptance of
deliverables.
• Iterative and incremental development is necessary to converge on an accurate
business solution.
• All changes during development are reversible.
• Requirements are baselined at a high level
• Testing is integrated throughout the life-cycle.
76. 76
Scrum
• Originally proposed by Schwaber and Beedle
• Scrum—distinguishing features
–Development work is partitioned into “packets”
–Testing and documentation are on-going as the
product is constructed
–Work occurs in “sprints” and is derived from a
“backlog” of existing requirements
–Meetings are very short and sometimes conducted
without chairs
–“demos” are delivered to the customer with the
time-box allocated
78. 78
Crystal
• Proposed by Cockburn and Highsmith
• Crystal—distinguishing features
– Actually a family of process models that allow
“maneuverability” based on problem
characteristics
– Face-to-face communication is emphasized
– Suggests the use of “reflection workshops” to
review the work habits of the team
79. 79
Feature Driven Development
• Originally proposed by Peter Coad et al
• FDD—distinguishing features
– Emphasis is on defining “features”
• a feature “is a client-valued function that can be
implemented in two weeks or less.”
–Uses a feature template
• <action> the <result> <by | for | of | to> a(n) <object>
–A features list is created and “plan by
feature” is conducted
–Design and construction merge in FDD
81. 81
Agile Modeling
• Originally proposed by Scott Ambler
• Suggests a set of agile modeling principles
– Model with a purpose
– Use multiple models
– Travel light
– Content is more important than representation
– Know the models and the tools you use to create
them
– Adapt locally
82. 82
Estimation
• Estimation of resources, cost, and schedule for
a software engineering effort requires
– experience
– access to good historical information (metrics)
– the courage to commit to quantitative predictions
when qualitative information is all that exists
• Estimation carries inherent risk and this risk
leads to uncertainty
84. 84
To Understand Scope ...
• Understand the customers needs
• understand the business context
• understand the project boundaries
• understand the customer’s
motivation
• understand the likely paths for
change
• understand that ...
Even when you understand,
nothing is guaranteed!
85. 85
What is Scope?
• Software scope describes
– the functions and features that are to be delivered
to end-users
– the data that are input and output
– the “content” that is presented to users as a
consequence of using the software
– the performance, constraints, interfaces, and
reliability that bound the system.
• Scope is defined using one of two techniques:
• A narrative description of software scope is developed
after communication with all stakeholders.
• A set of use-cases is developed by end-users.
87. 87
Project Estimation
• Project scope must be understood
• Elaboration (decomposition) is
necessary
• Historical metrics are very helpful
• At least two different techniques
should be used
• Uncertainty is inherent in the
process
89. 89
Estimation Accuracy
• Predicated on …
– the degree to which the planner has properly
estimated the size of the product to be built
– the ability to translate the size estimate into
human effort, calendar time, and dollars (a
function of the availability of reliable software
metrics from past projects)
– the degree to which the project plan reflects the
abilities of the software team
– the stability of product requirements and the
environment that supports the software
engineering effort.
92. 92
Example: LOC Approach
Average productivity for systems of this type = 620 LOC/pm.
Burdened labor rate =$8000 per month, the cost per line of code is
approximately $13.
Based on the LOC estimate and the historical productivity data, the total
estimated project cost is $431,000 and the estimated effort is 54 person-
months.
93. 93
These slides are designed to
accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-
Hill 2009). Slides copyright 2009 by
Example: FP Approach
The estimated number of FP is derived:
FPestimated = count-total 3 [0.65 + 0.01 3 S (Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total estimated
project cost is $461,000 and estimated effort is 58 person-months.
94. 94
Process-Based Estimation
Obtained from “process framework”
application
functions
framework activities
Effort required to
accomplish
each framework
activity for each
application function
95. 95
Process-Based Estimation Example
Activity
Task
Function
UICF
2DGA
3DGA
DSM
PCF
CGDF
DAM
Totals
% effort
CC Planning
Risk
Analysis Engineering
Construction
Release Totals
CE
analysis design code test
0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00
1% 1% 1% 8% 45% 10% 36%
CC = customer communication CE = customer evaluation
0.50
0.75
0.50
0.50
0.50
0.25
2.50
4.00
4.00
3.00
3.00
2.00
0.40
0.60
1.00
1.00
0.75
0.50
5.00
2.00
3.00
1.50
1.50
1.50
8.40
7.35
8.50
6.00
5.75
4.25
0.50 2.00 0.50 2.00 5.00
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Based on an average burdened labor rate of $8,000 per
month, the total estimated project cost is $368,000 and
the estimated effort is 46 person-months.
97. 97
Estimation with Use-Cases
use cases scenarios pages Êscenarios pages LOC LOC estimate
e subsystem 6 10 6 Ê 12 5 560 3,366
subsystem group 10 20 8 Ê 16 8 3100 31,233
e subsystem group 5 6 5 Ê 10 6 1650 7,970
Ê Ê Ê Ê
stimate Ê Ê Ê Ê 42,568
User interface subsystem
Engineering subsystem group
Infrastructure subsystem group
TotalLOC estimate
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.
98. 98
Empirical Estimation Models
General form:
effort = tuning coefficient * size
exponent
usually derived
as person-months
of effort required
either a constant or
a number derived based
on complexity of project
usually LOC but
may also be
function point
empirically
derived
99. 99
COCOMO-II
• 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.
100. 100
The Software Equation
A dynamic multivariable model
E = [LOC x B0.333/P]3 x (1/t4)
where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter”
101. 101
Estimation for OO Projects-I
• Develop estimates using effort decomposition, FP analysis, and any
other method that is applicable for conventional applications.
• Using object-oriented requirements modeling (Chapter 6), develop
use-cases and determine a count.
• From the analysis model, determine the number of key classes
(called analysis classes in Chapter 6).
• Categorize the type of interface for the application and develop a
multiplier for support classes:
– Interface type Multiplier
– No GUI 2.0
– Text-based user interface 2.25
– GUI 2.5
– Complex GUI 3.0
102. 102
Estimation for OO Projects-II
• Multiply the number of key classes (step 3) by the multiplier to obtain an
estimate for the number of support classes.
• Multiply the total number of classes (key + support) by the average
number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-
days per class.
• Cross check the class-based estimate by multiplying the average number
of work-units per use-case
103. 103
Estimation for Agile Projects
• Each user scenario (a mini-use-case) is considered separately for
estimation purposes.
• The scenario is decomposed into the set of software engineering
tasks that will be required to develop it.
• Each task is estimated separately. Note: estimation can be based on
historical data, an empirical model, or “experience.”
– Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or
some other volume-oriented measure (e.g., use-case count).
• Estimates for each task are summed to create an estimate for the
scenario.
– Alternatively, the volume estimate for the scenario is translated into
effort using historical data.
• The effort estimates for all scenarios that are to be implemented for a
given software increment are summed to develop the effort estimate
for the increment.
105. 105
Computing Expected Cost
(path probability) x (estimated path cost)
i i
For example, the expected cost to build is:
expected cost = 0.30 ($380K) + 0.70 ($450K)
similarly,
expected cost = $382K
expected cost = $267K
expected cost = $410K
build
reuse
buy
contr
expected cost =
= $429 K
106. 106
Project Risks
What can go wrong?
What is the likelihood?
What will the damage be?
What can we do about it?
107. 107
Reactive Risk Management
• project team reacts to risks when they occur
• mitigation—plan for additional resources in
anticipation of fire fighting
• fix on failure—resource are found and applied
when the risk strikes
• crisis management—failure does not respond
to applied resources and project is in jeopardy
108. 108
Proactive Risk Management
• formal risk analysis is performed
• organization corrects the root
causes of risk
– TQM concepts and statistical SQA
– examining risk sources that lie beyond
the bounds of the software
– developing the skill to manage change
109. 109
Seven Principles
• Maintain a global perspective—view software risks within the context of
system and the business problem
• Take a forward-looking view—think about the risks that may arise in the
future; establish contingency plans
• Encourage open communication—if someone states a potential risk, don’t
discount it.
• Integrate—a consideration of risk must be integrated into the software
process
• Emphasize a continuous process—the team must be vigilant throughout
the software process, modifying identified risks as more information is
known and adding new ones as better insight is achieved.
• Develop a shared product vision—if all stakeholders share the same
vision of the software, it likely that better risk identification and
assessment will occur.
• Encourage teamwork—the talents, skills and knowledge of all stakeholder
should be pooled
111. 111
Risk Identification
• Product size—risks associated with the overall size of the software to be built
or modified.
• Business impact—risks associated with constraints imposed by management
or the marketplace.
• Customer characteristics—risks associated with the sophistication of the
customer and the developer's ability to communicate with the customer in a
timely manner.
• Process definition—risks associated with the degree to which the software
process has been defined and is followed by the development organization.
• Development environment—risks associated with the availability and quality
of the tools to be used to build the product.
• Technology to be built—risks associated with the complexity of the system to
be built and the "newness" of the technology that is packaged by the system.
• Staff size and experience—risks associated with the overall technical and
project experience of the software engineers who will do the work.
112. 112
Assessing Project Risk-I
• Have top software and customer managers
formally committed to support the project?
• Are end-users enthusiastically committed to
the project and the system/product to be
built?
• Are requirements fully understood by the
software engineering team and their
customers?
• Have customers been involved fully in the
definition of requirements?
• Do end-users have realistic expectations?
113. 113
Assessing Project Risk-II
• Is project scope stable?
• Does the software engineering team have the right
mix of skills?
• Are project requirements stable?
• Does the project team have experience with the
technology to be implemented?
• Is the number of people on the project team
adequate to do the job?
• Do all customer/user constituencies agree on the
importance of the project and on the requirements
for the system/product to be built?
114. 114
Risk Components
• performance risk—the degree of uncertainty
that the product will meet its requirements
and be fit for its intended use.
• cost risk—the degree of uncertainty that the
project budget will be maintained.
• support risk—the degree of uncertainty that
the resultant software will be easy to correct,
adapt, and enhance.
• schedule risk—the degree of uncertainty that
the project schedule will be maintained and
that the product will be delivered on time.
115. 115
Risk Projection
• Risk projection, also called risk estimation,
attempts to rate each risk in two ways
– the likelihood or probability that the risk is real
– the consequences of the problems associated
with the risk, should it occur.
• The are four risk projection steps:
– establish a scale that reflects the perceived
likelihood of a risk
– define the consequences of the risk
– estimate the impact of the risk on the project and
the product,
– note the overall accuracy of the risk projection so
that there will be no misunderstandings.
116. 116
Building a Risk Table
Risk Probability Impact RMMM
Risk
Mitigation
Monitoring
&
Management
117. 117
Building the Risk Table
• Estimate the probability of occurrence
• Estimate the impact on the project on a
scale of 1 to 5, where
– 1 = low impact on project success
– 5 = disastrous impact on project success
• sort the table by probability and impact
118. 118
Risk Exposure (Impact)
The overall risk exposure, RE, is determined using the following
relationship [Hal98]:
RE = P x C
where
P is the probability of occurrence for a risk, and
C is the cost to the project should the risk occur.
119. 119
Risk Exposure Example
• 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% (likely).
• Risk impact. 60 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 x 100 x 14 =
$25,200.
• Risk exposure. RE = 0.80 x 25,200 ~ $20,200.
120. 120
• mitigation—how can we avoid the risk?
• monitoring—what factors can we track that
will enable us to determine if the risk is
becoming more or less likely?
• management—what contingency plans do
we have if the risk becomes a reality?
Risk Mitigation, Monitoring,
and Management
121. 121
Risk Due to Product Size
• estimated size of the product in LOC or FP?
• estimated size of product in number of programs,
files, transactions?
• percentage deviation in size of product from
average for previous products?
• size of database created or used by the product?
• number of users of the product?
• number of projected changes to the requirements
for the product? before delivery? after delivery?
• amount of reused software?
Attributes that affect risk:
122. 122
Risk Due to Business Impact
• affect of this product on company revenue?
• visibility of this product by senior management?
• reasonableness of delivery deadline?
• number of customers who will use this product
• interoperability constraints
• sophistication of end users?
• amount and quality of product documentation that
must be produced and delivered to the customer?
• governmental constraints
• costs associated with late delivery?
• costs associated with a defective product?
Attributes that affect risk:
123. 123
Risks Due to the Customer
• Have you worked with the customer in the past?
• Does the customer have a solid idea of requirements?
• Has the customer agreed to spend time with you?
• Is the customer willing to participate in reviews?
• Is the customer technically sophisticated?
• Is the customer willing to let your people do their
job—that is, will the customer resist looking over your
shoulder during technically detailed work?
• Does the customer understand the software
engineering process?
Questions that must be answered:
124. 124
Risks Due to Process Maturity
• Have you established a common process framework?
• Is it followed by project teams?
• Do you have management support for
software engineering
• Do you have a proactive approach to SQA?
• Do you conduct formal technical reviews?
• Are CASE tools used for analysis, design and
testing?
• Are the tools integrated with one another?
• Have document formats been established?
Questions that must be answered:
125. 125
Technology Risks
• Is the technology new to your organization?
• Are new algorithms, I/O technology required?
• Is new or unproven hardware involved?
• Does the application interface with new software?
• Is a specialized user interface required?
• Is the application radically different?
• Are you using new software engineering methods?
• Are you using unconventional software development
methods, such as formal methods, AI-based approaches,
artificial neural networks?
• Are there significant performance constraints?
• Is there doubt the functionality requested is "do-able?"
Questions that must be answered:
126. 126
Staff/People Risks
• Are the best people available?
• Does staff have the right skills?
• Are enough people available?
• Are staff committed for entire duration?
• Will some people work part time?
• Do staff have the right expectations?
• Have staff received necessary training?
• Will turnover among staff be low?
Questions that must be answered:
127. 127
Project: Embedded software for XYZ system
Risk type: schedule risk
Priority (1 low ... 5 critical): 4
Risk factor: Project completion will depend on tests which require
hardware component under development. Hardware component
delivery may be delayed
Probability: 60 %
Impact: Project completion will be delayed for each day that
hardware is unavailable for use in software testing
Monitoring approach:
Scheduled milestone reviews with hardware group
Contingency plan:
Modification of testing strategy to accommodate delay using
software simulation
Estimated resources: 6 additional person months beginning in July
Recording Risk Information
128. 128
Why Are Projects Late?
• an unrealistic deadline established by someone outside the software
development group
• changing customer requirements that are not reflected in schedule
changes;
• 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
129. 129
Scheduling Principles
• compartmentalization—define distinct tasks
• interdependency—indicate task
interrelationship
• effort validation—be sure resources are
available
• defined responsibilities—people must be
assigned
• defined outcomes—each task must have an
output
• defined milestones—review for quality
130. 130
Effort and Delivery Time
Effort
Cost
Impossible
region
td
Ed
Tmin = 0.75T d
to
Eo
Ea = m( td
4/ ta
4)
development time
Ea = effort in person-months
td = nominal delivery time for schedule
to = optimal development time (in terms of cost)
ta = actual delivery time desired
131. 131
Effort Allocation
• “front end” activities
– customer communication
– analysis
– design
– review and modification
• construction activities
– coding or code generation
• testing and installation
– unit, integration
– white-box, black box
– regression
40-50%
30-40%
15-20%
132. 132
Defining Task Sets
• determine type of project
• assess the degree of rigor required
• identify adaptation criteria
• select appropriate software
engineering tasks
133. 133
Task Set Refinement
1.1 Concept scoping determines the overall scope of the
project.
Task definition: Task 1.1 Concept Scoping
1.1.1 Identify need, benefits and potential customers;
1.1.2 Define desired output/control and input events that drive the application;
Begin Task 1.1.2
1.1.2.1 FTR: Review written description of need
FTR indicates that a formal technical review (Chapter 26) is to be conducted.
1.1.2.2 Derive a list of customer visible outputs/inputs
1.1.2.3 FTR: Review outputs/inputs with customer and revise as required;
endtask Task 1.1.2
1.1.3 Define the functionality/behavior for each major function;
Begin Task 1.1.3
1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2;
1.1.3.2 Derive a model of functions/behaviors;
1.1.3.3 FTR: Review functions/behaviors with customer and revise as required;
endtask Task 1.1.3
1.1.4 Isolate those elements of the technology to be implemented in software;
1.1.5 Research availability of existing software;
1.1.6 Define technical feasibility;
1.1.7 Make quick estimate of size;
1.1.8 Create a Scope Definition;
endTask definition: Task 1.1
is refined to
137. 137
Schedule Tracking
– conduct periodic project status meetings in which each
team member reports progress and problems.
– evaluate the results of all reviews conducted throughout
the software engineering process.
– determine whether formal project milestones (the
diamonds shown in Figure 27.3) have been accomplished by
the scheduled date.
– compare actual start-date to planned start-date for each
project task listed in the resource table (Figure 27.4).
– meet informally with practitioners to obtain their subjective
assessment of progress to date and problems on the
horizon.
– use earned value analysis (Section 27.6) to assess progress
quantitatively.
138. 138
Progress on an OO Project-I
• Technical milestone: OO analysis completed
• All classes and the class hierarchy have been defined and reviewed.
• Class attributes and operations associated with a class have been defined and reviewed.
• Class relationships (Chapter 8) have been established and reviewed.
• A behavioral model (Chapter 8) has been created and reviewed.
• Reusable classes have been noted.
• Technical milestone: OO design completed
• The set of subsystems (Chapter 9) has been defined and reviewed.
• Classes are allocated to subsystems and reviewed.
• Task allocation has been established and reviewed.
• Responsibilities and collaborations (Chapter 9) have been identified.
• Attributes and operations have been designed and reviewed.
• The communication model has been created and reviewed.
139. 139
Progress on an OO Project-II
• Technical milestone: OO programming completed
• Each new class has been implemented in code from the design model.
• Extracted classes (from a reuse library) have been implemented.
• Prototype or increment has been built.
• Technical milestone: OO testing
• The correctness and completeness of OO analysis and design models has been
reviewed.
• A class-responsibility-collaboration network (Chapter 6) has been developed and
reviewed.
• Test cases are designed and class-level tests (Chapter 19) have been conducted for
each class.
• Test cases are designed and cluster testing (Chapter 19) is completed and the
classes are integrated.
• System level tests have been completed.
140. 140
Earned Value Analysis (EVA)
• Earned value
– is a measure of progress
– enables us to assess the “percent of
completeness” of a project using quantitative
analysis rather than rely on a gut feeling
– “provides accurate and reliable readings of
performance from as early as 15 percent into the
project.” [Fle98]
141. 141
Computing Earned Value-I
• The budgeted cost of work scheduled (BCWS) is determined for each work
task represented in the schedule.
– BCWSi is the effort planned for work task i.
– To determine progress at a given point along the project schedule, the value of
BCWS is the sum of the BCWSi values for all work tasks that should have been
completed by that point in time on the project schedule.
• The BCWS values for all work tasks are summed to derive the budget at
completion, BAC. Hence,
BAC = ∑ (BCWSk) for all tasks k
142. 142
Computing Earned Value-II
• Next, the value for budgeted cost of work performed (BCWP) is
computed.
– The value for BCWP is the sum of the BCWS values for all work tasks that
have actually been completed by a point in time on the project schedule.
• “the distinction between the BCWS and the BCWP is that the former
represents the budget of the activities that were planned to be
completed and the latter represents the budget of the activities that
actually were completed.” [Wil99]
• Given values for BCWS, BAC, and BCWP, important progress indicators
can be computed:
• Schedule performance index, SPI = BCWP/BCWS
• Schedule variance, SV = BCWP – BCWS
• SPI is an indication of the efficiency with which the project is utilizing scheduled
resources.
143. 143
Computing Earned Value-III
• Percent scheduled for completion = BCWS/BAC
– provides an indication of the percentage of work that should have been
completed by time t.
• Percent complete = BCWP/BAC
– provides a quantitative indication of the percent of completeness of the
project at a given point in time, t.
• Actual cost of work performed, ACWP, is the sum of the effort actually
expended on work tasks that have been completed by a point in time on
the project schedule. It is then possible to compute
• Cost performance index, CPI = BCWP/ACWP
• Cost variance, CV = BCWP – ACWP
