The document discusses various process models for software engineering including waterfall, incremental, RAD, evolutionary (prototyping and spiral), concurrent, component-based, aspect-oriented, and reuse-oriented models. It also covers project metrics, software measurement approaches including size-oriented metrics like lines of code and function-oriented metrics like function points. Key aspects of each model are defined along with their applicability and limitations.

1. Unit - 2
1
Process Model

2. The Waterfall Model
2
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.

3. 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.
3

4. The Incremental Model
4

5. 2.6 The RAD Model
• Is a “high-speed” adaptation of the linear sequential model in
which rapid development is achieved by using component-
based construction.
• Is an incremental software development process model that
emphasizes an extremely short development cycle.

6. 6
The RAD Model
RAD

7. 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. 7

8. 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. 8

9. Evolutionary Models: Prototyping
9
Construction
of prototype
communication
Quick
plan
Modeling
Quick design
Construction
of prototype
Deployment
delivery &
feedback

10. 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. 10

11. Evolutionary Models: The Spiral
11

12. Three Concerns on Evolutionary
Processes
• First concern is that prototyping poses a problem to project planning because of
the uncertain number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that the
process will fall into chaos. On the other hand if the speed is too slow then
productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility
rather than on high quality. We should prioritize the speed of the development
over zero defects. Extending the development in order to reach high quality
could result in a late delivery of the product when the opportunity niche has
disappeared.
12

13. 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.
13

14. Concurrent Model
14

15. Component-based software
engineering
• Based on systematic reuse where systems are integrated from
existing components or COTS (Commercial-off-the-shelf)
systems.
• Process stages
• Component analysis;
• Requirements modification;
• System design with reuse;
• Development and integration.
• This approach is becoming increasingly used as component
standards have emerged.

16. Reuse-oriented
development

17. Aspect Oriented software Development
• The Aspectual requirements define crosscutting concerns
which impact over software architecture .
• AOP provides process and methodological approach for base
activities for aspect.

18. Aspect Terminology
AOCS work with concept of Horizontal slices through vertically
decomposed software component
• Common systemic aspect include user Interface, collaborative
work, distribution, memory management,
transaction processing, security, Integrity etc.
This process will adopt characteristics of both spiral and concurrent
model.
Evolutionary nature of spiral model
Parallel nature of concurrent model

19. Cross-cutting concerns
Security req.
Recovery req.
Core concerns
New customer
req.
Customer
management req.
Account
req.
Cross-cutting
concerns

20. 20
Project Metrics
• Used during estimation for P.M. and Team
1 assessment
2 Risk track
3 Uncover problem area
4 Adjust work flow
5 software quality
• Used to monitor and control progress
• The intent is twofold
Minimize the development schedule
Assess product quality on an ongoing basis
• Leads to a reduction in overall project cost

21. 21
21
SOFTWARE METRICS FOR PROCESS AND PROJECTS
PROCES
S
BUSINES
CONDITIONS
CUSTOMER
CHARACTERISTICS
DEVELOPMEN
T ENVIRONMENT
PEOPLE
TECHNOLOGY
PRODUCT

22. 22
Software Measurement
• S/W measurement can be categorized in two ways:
1. Direct measures of the s/w process (e.g., cost and effort
applied) and product (e.g., lines of code (LOC) produced,
etc.)
2. Indirect measures of the product (e.g., functionality,
quality, complexity, etc.)
• Requires normalization of both size- and function-
oriented metrics

23. 23
Size-Oriented Metrics (1)
• Lines of Code (LOC) can be chosen as the normalization
value
• Example of simple size-oriented metrics
• Errors per KLOC (thousand lines of code)
• Defects per KLOC
• $ per KLOC
• Pages of documentation per KLOC

24. 24
Size-Oriented Metrics (2)
• Controversy regarding use of LOC as a key
measure
• According to the proponents
• LOC is an “artifact” of all s/w development projects
• Many existing s/w estimation models use LOC or KLOC as a key
input
• According to the opponents
• LOC measures are programming language dependent
• They penalize well-designed but shorter programs
• Cannot easily accommodate nonprocedural languages
• Difficult to predict during estimation

25. 25
Function-Oriented Metrics
(1)
• The most widely used function-oriented metric is the
function point (FP)
• fp=count total * [0.65+0.01* ∑(fi)]
• CT=ex.in+output,Inquires, int.ext. logical interface
• Computation of the FP is based on characteristics of the
software’s information domain and complexity

26. 26
Function-Oriented Metrics
(2)
• Controversy regarding use of FP as a key measure
• According to the proponents
• It is programming language independent
• Can be predicted before coding is started
• According to the opponents
• Based on subjective rather than objective data
• Has no direct physical meaning – it’s just a number

27. Estimation for Software Projects
- Project planning
- Scope and feasibility
- Project resources
- Estimation of project cost and effort
- Decomposition techniques
- Empirical estimation models
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

28. 28
Software Project Planning
• Software project planning encompasses five major activities
• Estimation, scheduling, risk analysis, quality management planning, and
change management planning
• Estimation determines how much money, effort, resources, and time it will
take to build a specific system or product
• The software team first estimates
• The work to be done
• The resources required
• The time that will elapse from start to finish
• Then they establish a project schedule that
• Defines tasks and milestones
• Identifies who is responsible for conducting each task
• Specifies the inter-task dependencies

29. 29
Task Set for Project Planning
1) Establish project scope
2) Determine feasibility
3) Analyze risks
4) Define required resources
a) Determine human resources required
b) Define reusable software resources
c) Identify environmental resources
5) Estimate cost and effort
a) Decompose the problem
b) Develop two or more estimates using different approaches
c) Reconcile the estimates
6) Develop a project schedule
a) Establish a meaningful task set
b) Define a task network
c) Use scheduling tools to develop a timeline chart
d) Define schedule tracking mechanisms

30. 30
Software Scope
• Software scope describes
• The functions and features that are to be delivered to end users
• The data that are input to and output from the system
• 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 can be define using 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
(More on next slide)

31. 31
Software Scope (continued)
• After the scope has been identified, two questions are asked
• Can we build software to meet this scope?
• Is the project feasible?
• Software engineers too often rush (or are pushed) past these questions
• Later they become mired in a project that is doomed from the onset

32. 32
Feasibility
• After the scope is resolved, feasibility is addressed
• Software feasibility has four dimensions
• Technology – Is the project technically feasible? Is it within the state of the art?
Can defects be reduced to a level matching the application's needs?
• Finance – Is is financially feasible? Can development be completed at a cost that
the software organization, its client, or the market can afford?
• Time – Will the project's time-to-market beat the competition?
• Resources – Does the software organization have the resources needed to succeed
in doing the project?
Another view recommends the following feasibility dimensions: technological,
economical, legal, operational, and schedule issues (TELOS)

33. 33
Decomposition Introduction
• Before an estimate can be made and decomposition techniques applied,
the planner must
• Understand the scope of the software to be built
• Generate an estimate of the software’s size
• Then one of two approaches are used
• Problem-based estimation
• Based on either source lines of code or function point estimates
• Process-based estimation
• Based on the effort required to accomplish each task

34. 34
Approaches to Software Sizing
• Function point sizing
• Develop estimates of the information domain characteristics
• Standard component sizing
• Estimate the number of occurrences of each standard component
• Use historical project data to determine the delivered LOC size per standard
component
• Change sizing
• Used when changes are being made to existing software
• Estimate the number and type of modifications that must be accomplished
• Types of modifications include reuse, adding code, changing code, and deleting code
• An effort ratio is then used to estimate each type of change and the size of the change
The results of these estimates are used to compute an optimistic (low), a most
likely, and a pessimistic (high) value for software size

35. 35
Problem-Based Estimation
1) Start with a bounded statement of scope
2) Decompose the software into problem functions that can each be
estimated individually
3) Compute an LOC or FP value for each function
4) Derive cost or effort estimates by applying the LOC or FP values to
your baseline productivity metrics (e.g., LOC/person-month or
FP/person-month)
5) Combine function estimates to produce an overall estimate for the
entire project
(More on next slide)

36. 36
Problem-Based Estimation (continued)
• In general, the LOC/pm and FP/pm metrics should be computed by project
domain
• Important factors are team size, application area, and complexity
• LOC and FP estimation differ in the level of detail required for
decomposition with each value
• For LOC, decomposition of functions is essential and should go into
considerable detail (the more detail, the more accurate the estimate)
• For FP, decomposition occurs for the five information domain
characteristics and the 14 adjustment factors
• External inputs, external outputs, external inquiries, internal logical
files, external interface files
pm = person month

37. 37
Reconciling Estimates
• The results gathered from the various estimation techniques must be
reconciled to produce a single estimate of effort, project duration, and
cost
• If widely divergent estimates occur, investigate the following causes
• The scope of the project is not adequately understood or has been
misinterpreted by the planner
• Productivity data used for problem-based estimation techniques is
inappropriate for the application, obsolete (i.e., outdated for the current
organization), or has been misapplied
• The planner must determine the cause of divergence and then reconcile
the estimates

38. 38
Thank You