Software

Management
(Introduction of
Software Engineering
and management
terms)

1
What is Software
Engineering?
 Engineering approach to
develop software.
 Building Construction Analogy.
 Systematic collection of past
experience:
 techniques,
 methodologies,
 guidelines.

3
Engineering Practice
 Heavy use of past experience:
 Past experience is systematically
arranged.
 Theoretical basis and
quantitative techniques provided.
 Many are just thumb rules.
 Tradeoff between alternatives
 Pragmatic approach to cost-
effectiveness 4
Why Study Software Engineering? (1)

 To acquire skills to develop

large programs.
 Exponential growth in complexity
and difficulty level with size.
 The ad hoc approach breaks
down when size of software
increases: ---

5
Why Study Software Engineering? (2)

 Ability to solve complex

programming problems:
 How to break large projects into
smaller and manageable parts?
 Learn techniques of:
 specification, design, interface
development, testing, project
management, etc.
6
Why Study Software Engineering? (3)

 To acquire skills to be
a better programmer:
Higher Productivity
Better Quality Programs

7
Software Crisis
 Software products:
 fail to meet user
requirements.
 frequently crash.
 expensive.
 difficult to alter, debug, and
enhance.
 often delivered late.
 use resources non-optimally.

8
Factors Contributing to the
Software Crisis

 Larger problems,
 Lack of adequate training in
software engineering,
 Increasing skill shortage,
 Low productivity
improvements.

9
Software
Software Myths
Myths
(Management
(Management Perspectives)
Perspectives)
As long as there are good standards and clear
procedures in my company, I shouldn’t be too
concerned.
But the proof of the pudding
is in the eating;
not in the Recipe !
Software
Software Myths
Myths
(Management
(Management Perspectives)
Perspectives)
As long as my software engineers(!) have
access to the fastest and the most sophisticated
computer environments and state-of-the-art
software tools, I shouldn’t be too concerned.

The environment is
only one of the several factors
that determine the quality
of the end software product!
 Software
Software Myths
Myths
(Management
(Management Perspectives)
Perspectives)
When my schedule slips, what I have to do
is to start a fire-fighting operation: add more
software specialists, those with higher skills
and longer experience - they will bring the
schedule back on the rails!
Unfortunately,
software business does not
entertain schedule compaction
beyond a limit!
 Software
Software Myths
Myths
(Customer
(Customer Perspectives)
Perspectives)
 A general statement of objectives is
sufficient to get started with the
development of software. Missing/vague
requirements can easily be
incorporated/detailed out as they get
concretized.
 Application requirements can never be
stable; software can be and has to be made
flexible enough to allow changes to be
incorporated as they happen.
 Software
Software Myths
Myths
(Developer
(Developer Perspectives)
Perspectives)
Once the software is demonstrated, the job
is done.

Usually, the problems just begin!

 Software
Software Myths
Myths
(Developer
(Developer Perspectives)
Perspectives)
Until the software is coded and is available for
testing, there is no way for assessing its quality.

Usually, there are too many

tiny bugs inserted at every stage
that grow in size and complexity
as they progress thru further stages!
 Software
Software Myths
Myths
(Developer
(Developer Perspectives)
Perspectives)

The only deliverable for a software

development project is the tested code.

The code is only

the externally visible component
of the entire software complement!
 Software
Software Product
Product
is a product designated for delivery to
the user
source
source documents
documents
codes
codes reports
reports

manuals
manuals
object
object plans
plans
codes
codes
data
data

test test
testresults
results
testsuites
suites prototypes
prototypes
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics
Finding and fixing a software problem

1 after delivery of the product is 100

times more expensive than defect
removal during requirements and
early design phases.
20 20
relative effort to repair

15
Effort
Effortto
toRepair
RepairSoftware
Software 10
(when
(when defects aredetected
defects are detected
at different stages)
at different stages) 5
5
2
0.5 1
0 0.15

Maintenance
Acc. Test
Unit test
Reqmts

Coding
Design
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

2
Nominal software development
schedules can be compressed up to
25% (by adding people, money, etc.)
but no more.

3 Maintenance costs twice what the

development costs.
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

4
Development and maintenance costs
are primarily a function of the size.

5Variations in humans
account for the greatest
variations in productivity.

6
The ratio of software to
hardware costs has gone from
15:85 in 1985 and continues to
grow in favor of software as the
dominant cost.
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

7 Only about 15% of the

development effort is in coding.

8
Applications products cost three
times as much per instruction as
individual programs; system
software products cost nine times
as much.

9 Walkthroughs catch 60% of

the errors.
 Distribution
Distribution of
of Effort
Effort
Across
Across Phases
Phases

10
25 5
45
Testing 15 40

20 30
Coding
15
Design 45
30
20
Analysis
Traditional Structured CASE environment
environment techniques

Analysis Design Coding Testing

Distribution
Distribution of
of Activities
Activities
in
in Defect
Defect Removal
Removal

walkthru
unit test
evaluation
10 5 10 integration
other
10

65
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

10 Many software processes

obey a Pareto distribution.

20% 80%
tools use
Symptom of Software Crisis
 about US$250 billion spent per year in the
US on application development
 of this, about US$140 billion wasted due to
the projects getting abandoned or
reworked; this in turn because of not
following best practices and standards
 10% of client/server apps are abandoned or restarted
from scratch
 20% of apps are significantly altered to avoid disaster
 40% of apps are delivered significantly late

Source: 3 year study of 70 large c/s apps 30 European firms.

Compuware Ref: Standish Group,
25
Programs versus Software
Products
 Usually small in size  Large
 Author himself is  Large number of
sole user users
 Single developer  Team of
 Lacks proper user developers
interface  Well-designed
 Lacks proper interface
documentation  Well documented &
 Ad hoc user-manual
development. prepared
 Systematic
development 26
Computer Systems
Engineering
 Computer systems engineering:
 encompasses software engineering.
 Many products require development of
software as well as specific hardware to
run it:
 a coffee vending machine,
 a mobile communication product, etc.
 The high-level problem:
 deciding which tasks are to be solved by software
 which ones by hardware.

27
Computer Systems Engineering
(CONT.)

 Often, hardware and software are developed together:

 Hardware simulator is used during software development.
 Integration of hardware and software.
 Final system testing

28
Emergence of Software Engineering
 Early Computer Programming (1950s):
 Programs were being written in assembly language.
 Programs were limited to about a few hundreds of
lines of assembly code.
 Every programmer developed his own style of writing programs:
 according to his intuition (exploratory programming).

(Early 60s)
 High-level languages such as FORTRAN, ALGOL, and
COBOL were introduced:
 This reduced software development efforts greatly.
 Software development style was still exploratory.
 Typical program sizes were limited to a few thousands
of lines of source code.

29
Control Flow-Based Design (late 60s)

 Size and complexity of programs increased further:

 exploratory programming style proved to be insufficient.
 Programmers found:
 very difficult to write cost-effective and correct programs.

 programs written by others very difficult to understand

and maintain.
 To cope up with this problem, experienced programmers
advised: ``Pay particular attention to the design of the
program's control structure.'’
(late 60s)

 A program's control structure indicates:

 the sequence in which the program's instructions are
executed.
 To help design programs having good control structure:
 flow charting technique was developed.
30
(late 60s)
 Using flow charting technique:
 one can represent and design a program's control structure.
 Usually one understands a program:
 by mentally simulating the program's execution sequence.

 A program having a messy flow chart representation:

 difficult to understand and debug.
 It was found:
 GO TO statements makes control structure of a program messy
 GO TO statements alter the flow of control arbitrarily.
 The need to restrict use of GO TO statements was recognized.

 Many programmers had extensively used assembly languages.

 JUMP instructions are frequently used for program branching
in assembly languages,
 programmers considered use of GO TO statements
inevitable.

31
Structured Programming
 A program is called structured
 when it uses only the following types of constructs:
 sequence,
 selection,
 iteration
 Unstructured control flows are avoided.
 Consist of a neat set of modules.
 Use single-entry, single-exit program constructs.
 Structured programs are:
 Easier to read and understand,
 easier to maintain,
 require less effort and time for development.

33
Data Structure-Oriented Design
(Early 70s)

 Soon it was discovered:

 it is important to pay more attention to the design of
data structures of a program
 than to the design of its control structure.
 Data flow-oriented techniques advocate:
 the data items input to a system must first be identified,
 processing required on the data items to produce the
required outputs should be determined.
 Data flow technique is a generic technique:
 can be used to model the working of any system
 not just software systems.
 A major advantage of the data flow technique is its
simplicity.
34
Object-Oriented Design (80s)
 Object-oriented technique:
 an intuitively appealing design approach:
 natural objects (such as employees, pay-roll-register,
etc.) occurring in a problem are first identified.
 Relationships among objects:
 such as composition, reference, and inheritance are
determined.
 Each object essentially acts as
 a data hiding (or data abstraction) entity.

 Object-Oriented Techniques have gained wide

acceptance:
 Simplicity
 Reuse possibilities
 Lower development time and cost
 More robust code
 Easy maintenance
36
Evolution of Design
Techniques
Object-Oriented

Data flow-based

Data structure-
based

Control flow-
based

Ad hoc

37
Evolution of Other Software
Engineering Techniques
 The improvements to the software design methodologies
 are indeed very conspicuous.
 In additions to the software design techniques:
 several other techniques evolved.
 life cycle models,
 specification techniques,
 project management techniques,
 testing techniques,
 debugging techniques,
 quality assurance techniques,
 software measurement techniques,
 CASE tools, etc.

38
Differences Between the Exploratory Style and
Modern Software Development Practices
 Use of Life Cycle Models
 Software is developed through several well-defined
stages:
 requirements analysis and specification,
 design,
 coding,
 testing, etc.
 Emphasis has shifted
 from error correction to error prevention.
 Modern practices emphasize:
 detection of errors as close to their point of
introduction as possible.
 In exploratory style,
 errors are detected only during testing,
 Now,
 focus is on detecting as many errors as possible in
each phase of development.
39
Differences Between the Exploratory Style and Modern
Software Development Practices (CONT.)
 During all stages of development process:
 Periodic reviews are being carried out
 Software testing has become systematic:
 standard testing techniques are available.
 A lot of effort and attention is now being paid to:
 requirements specification.
 Also, now there is a distinct design phase:
 standard design techniques are being used.
 There is better visibility of design and code:
 visibility means production of good quality, consistent
and standard documents.
 In the past, very little attention was being given to
producing good quality and consistent documents.
 We will see later that increased visibility makes
software project management easier.
40
Differences between the exploratory style and modern
software development practices (CONT.)

 Because of good documentation:

 fault diagnosis and maintenance are smoother now.
 Several metrics are being used:
 help in software project management, quality
assurance, etc.
 Projects are being thoroughly planned:
 estimation,
 scheduling,
 monitoring mechanisms.
 Use of CASE tools.

41
 Software Life Cycle
 Software life cycle (or software process):
 series of identifiable stages that a software
product undergoes during its life time:
 Feasibility study
 requirements analysis and specification,
 design,
 coding,
 testing
 maintenance.
Common Symptoms of Failed Software Development Projects
 Inaccurate understanding of end-user-needs
 Inability to deal with changing requirements
 Modules that do not fit together
 Software that is too hard to maintain or extend
 Late discovery of serious flaws
 Poor software quality
 Unacceptable software performance
42
Some Root Causes for Failure
 Ad hoc requirements management
 Ambiguous and imprecise communication
 Brittle software architectures
 Overwhelming complexity
 Undetected inconsistencies in requirements, design and
implementations
 Insufficient testing
 Subjective project status assessment
 Failure to attack risk
 uncontrolled change propagation
 Insufficient use of automation tools
Misplaced Assumptions
 All requirements can be pre specified.
 Users are expert at specification of their needs.
 Users and developers are both good at visualization.
 The project team is capable of unambiguous
communication.
Ref: Larry Vaughn
43
43
Life Cycle Model
 A software life cycle model (or process model):
 a descriptive and diagrammatic model of software life cycle:
 identifies all the activities required for product development,
 establishes a precedence ordering among the different activities,
 Divides life cycle into phases.

 Several different activities may be carried out in each life

cycle phase.
 For example, the design stage might consist of:
 structured analysis activity followed by
 structured design activity.
 A written description:
 forms a common understanding of activities among
the software developers.
 helps in identifying inconsistencies, redundancies,
and omissions in the development process.
 Helps in tailoring a process model for specific projects.
44
Why Model Life Cycle ?
 Processes are tailored for special projects.
 A documented process model
 helps to identify where the tailoring is to occur.

 The development team must identify a suitable life cycle model:

 and then adhere to it.
 Primary advantage of adhering to a life cycle model:
 helps development of software in a systematic and disciplined
manner.

 When a program is developed by a single programmer ---

 he has the freedom to decide his exact steps.
 When a software product is being developed by a team:
 there must be a precise understanding among team
members as to when to do what,
 otherwise it would lead to chaos and project failure.

45
Life Cycle Model (CONT.)

 A software project will never succeed if:

 one engineer starts writing code,
 another concentrates on writing the test document
first,
 yet another engineer first defines the file structure
 Aanother defines the I/O for his portion first.
life cycle model:
 defines entry and exit criteria for every phase.
 A phase is considered to be complete:
 only when all its exit criteria are satisfied.
 The phase exit criteria for the software requirements
specification phase:
 Software Requirements Specification (SRS) document
is complete, reviewed, and approved by the customer.
 A phase can start: only if its phase-entry criteria have
been satisfied.
 It becomes easier for software project managers:
 to monitor the progress of the project. 46
Life Cycle Model (CONT.)

 When a life cycle model is adhered to,

 the project manager can at any time fairly accurately tell,
 at which stage (e.g., design, code, test, etc. ) of the project is.
 Otherwise, it becomes very difficult to track the progress of
the project
 the project manager would have to depend on the guesses of
the team members.
 This usually leads to a problem:
 known as the 99% complete syndrome.
 Many life cycle models have been proposed.
 We will confine our attention to a few important and
commonly used models.
 classical waterfall model
 iterative waterfall,
 evolutionary,
 prototyping, and
 spiral model 47
Chapter 2
`Software Engineering
 Process Models
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

These slides are designed and adapted from slides provided by Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill
2009) by Roger Pressman.

48
 Social Learning Process
 Software is embodied knowledge that is initially dispersed,
tacit and incomplete.

 In order to convert knowledge into software, dialogues are

needed between users and designers, between designers
and tools to bring knowledge into software.

 Software development is essentially an iterative social

learning process, and the outcome is “software capital”.

Definition of Software Process

 A framework for the activities, actions, and tasks that are

required to build high-quality software.

 SP defines the approach that is taken as software is engineered.

 Is not equal to software engineering, which also encompasses

technologies that populate the process– technical methods and
automated tools. 49
What / who / why is Process Models?
 What: Go through a series of predictable steps--- a road map that helps
you create a timely, high-quality results.
 Who: Software engineers and their managers, clients also. People adapt
the process to their needs and follow it.
 Why: Provides stability, control, and organization to an activity that can
if left uncontrolled, become quite chaotic. However, modern software
engineering approaches must be agile and demand ONLY those
activities, controls and work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the software that
you are building. One process might be good for aircraft avionic system,
while an entirely different process would be used for website creation.
 How to ensure right: A number of software process assessment
mechanisms that enable us to determine the maturity of the software
process. However, the quality, timeliness and long-term viability of the
software are the best indicators of the efficacy of the process you use.

50
 A Generic Process Model
 As we discussed before, a generic
process framework for software
engineering defines five framework
activities-communication, planning,
modeling, construction, and
deployment.
 In addition, a set of umbrella activities-
project tracking and control, risk
management, quality assurance,
configuration management, technical
reviews, and others are applied
throughout the process.
 Next question is: how the framework
activities and the actions and tasks
that occur within each activity are
organized with respect to sequence
and time? See the process flow for
answer. A Generic Process Model
51
 Process Flow
 Linear process flow executes
each of the five activities in
sequence.
 An iterative process flow
repeats one or more of the
activities before proceeding to
the next.
 An evolutionary process flow
executes the activities in a
circular manner. Each circuit
leads to a more complete
version of the software.
 A parallel process flow executes
one or more activities in parallel
with other activities ( modeling
for one aspect of the software
in parallel with construction of
another aspect of the software. 52
Identifying a Task Set
 Before you can proceed with the process model, a key
question: what actions are appropriate for a framework
activity given the nature of the problem, the characteristics
of the people and the stakeholders?
 A task set defines the actual work to be done to accomplish
the objectives of a software engineering action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be applied
 For example, a small software project requested by one
person with simple requirements, the communication
activity might encompass little more than a phone all with
the stakeholder. Therefore, the only necessary action is
phone conversation, the work tasks of this action are:
 1. Make contact with stakeholder via telephone.
 2. Discuss requirements and take notes.
 3. Organize notes into a brief written statement of
requirements.
 4. E-mail to stakeholder for review and approval. 53
Example of a Task Set for Elicitation
 The task sets for Requirements gathering
action for a simple project may include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal
meeting.
3. Ask each stakeholder to make a list of
features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.

54
 Prescriptive Models
 Originally proposed to bring order to chaos.
 Prescriptive process models advocate an orderly approach to
software engineering. However, will some extent of chaos (less
rigid) be beneficial to bring some creativity?

That leads to a few questions …

 If prescriptive process models strive for structure and order
(prescribe a set of process elements and process flow), are they
inappropriate for a software world that thrives on change?
 Yet, if we reject traditional process models (and the order they
imply) and replace them with something less structured, do we
make it impossible to achieve coordination and coherence in
software work?

55
 The Waterfall Model

It is the oldest paradigm for SE. When requirements are well

defined and reasonably stable, it leads to a linear fashion.
(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements explicitly.
Blocking state. 3. code will not be released until very late.)

The classic life cycle suggests a systematic, sequential approach

to software development.

56
The V-Model
 A variation of waterfall model
depicts the relationship of
quality assurance actions to
the actions associated with
communication, modeling
and early code construction
activates.

 Team first moves down the

left side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of
the V, performing a series of
tests that validate each of
the models created as the
team moved down the left
side.
57
 The Incremental Model
 When initial requirements are reasonably well defined,
but the overall scope of the development effort precludes
a purely linear process. A compelling need to expand a
limited set of new functions to a later system release.
 It combines elements of linear and parallel process flows.
Each linear sequence produces deliverable increments of
the software.
 The first increment is often a core product with many
supplementary features. Users use it and evaluate it with
more modifications to better meet the needs.

58
Evolutionary Models
 Software system evolves over time as requirements often
change as development proceeds. Thus, a straight line to a
complete end product is not possible. However, a limited
version must be delivered to meet competitive pressure.
 Usually a set of core product or system requirements is well
understood, but the details and extension have yet to be
defined.
 You need a process model that has been explicitly designed
to accommodate a product that evolved over time.
 It is iterative that enables you to develop increasingly more
complete version of the software.
 Two types are introduced, namely Prototyping and Spiral
models. Quick
plan
communication
Modeling
Quick design

Deployment Constructi
delivery & on Construction
feedback of of prototype
prototype
59
Evolutionary Models: Prototyping
 When to use: Customer defines a set of general objectives but does not
identify detailed requirements for functions and features. Or Developer may
be unsure of the efficiency of an algorithm, the form that human computer
interaction should take.
 What step: Begins with communication by meeting with stakeholders to
define the objective, identify whatever requirements are known, outline
areas where further definition is mandatory. A quick plan for prototyping and
modeling (quick design) occur. Quick design focuses on a representation of
those aspects the software that will be visible to end users. ( interface and
output). Design leads to the construction of a prototype which will be
deployed and evaluated. Stakeholder’s comments will be used to refine
requirements .
 Both stakeholders and software engineers like the prototyping paradigm.
Users get a feel for the actual system, and developers get to build something
immediately. However, engineers may make compromises in order to get a
prototype working quickly. The less-than-ideal choice may be adopted
forever after you get used to it.

60
 Evolutionary Models: The Spiral
 It couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model and is a risk-driven
process model generator that is used to guide multi-stakeholder
concurrent engineering of software intensive systems.
 Two main distinguishing features: one is cyclic approach for
incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk. The other is a
set of anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory system solutions.
 A series of evolutionary releases are delivered. During the early
iterations, the release might be a model or prototype. During later
iterations, increasingly more complete version of the engineered
system are produced.
 The first circuit in the clockwise direction might result in the product
specification; subsequent passes around the spiral might be used to
develop a prototype and then progressively more sophisticated
versions of the software. Each pass results in adjustments to the
project plan. Cost and schedule are adjusted based on feedback.
Also, the number of iterations will be adjusted by project manager.
 Good to develop large-scale system as software evolves as the
process progresses and risk should be understood and properly
reacted to. Prototyping is used to reduce risk.
 However, it may be difficult to convince customers that it is
controllable as it demands considerable risk assessment expertise.

61
 Concurrent Model
 Allow a software team to represent iterative and concurrent
elements of any of the process models. For example, the
modeling activity defined for the spiral model is accomplished
by invoking one or more of the following actions: prototyping,
analysis and design.
 The Figure shows modeling may be in any one of the states at
any given time. For example, communication activity has
completed its first iteration and in the awaiting changes state.
The modeling activity was in inactive state, now makes a
transition into the under development state. If customer
indicates changes in requirements, the modeling activity
moves from the under development state into the awaiting
changes state.
 Concurrent modeling is applicable to all types of software
development and provides an accurate picture of the current
state of a project. Rather than confining software engineering
activities, actions and tasks to a sequence of events, it defines
a process network. Each activity, action or task on the
network exists simultaneously with other activities, actions or
tasks. Events generated at one point trigger transitions among
the states.
62
 Still Other Process Models
 Component based development—the process to apply
when reuse is a development objective ( like spiral model)
 Formal methods—emphasizes the mathematical
specification of requirements ( easy to discover and
eliminate ambiguity, incompleteness and inconsistency)
 Aspect Oriented software development (AOSD)—provides a
process and methodological approach for defining,
specifying, designing, and constructing aspects
 Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely aligned
with the Unified Modeling Language (UML) to model and
develop object-oriented system iteratively and
incrementally.

63
The Unified Process (UP)
elaboration UP Phases
inception

UP Work Products