Elementary Probability theory Chapter 2.pptx

Fundamentals of software engineering
Chapter 2
Software process model

Objectives
 To understand the concepts of
software processes and software
process models.
 To describe the generic process
models and when they may be used.
 To introduce iterative and sequential
process models.

Software process
 Software process is a set of related activities that
leads to the production of a software system.
 Software process can be defined as a framework for
the activities, actions, and tasks that are required to
build high-quality software.
 A software process model is an abstract
representation of a process. It presents a description
of a process from some particular perspective.

Generic process model
 A generic process framework for software
engineering defines five framework activities
communication, planning, modeling, construction,
and deployment. And also a set of umbrella
activities- project tracking and control, risk
management, quality assurance, configuration
management and etc.
 A process flow describes how the framework
activities and the actions and tasks that occur within

linear process flow executes each of the five framework
activities in sequence, beginning with communication and
culminating with deployment.
An iterative process flow repeats one or more of the
activities before proceeding to the next.
Process flow types

Cont’d
An evolutionary process flow executes the activities
in a “circular” manner. Each circuit through the five
activities leads to a more complete version of the
software.

Cont’d
A parallel process flow executes one or more
activities in parallel with other activities (e.g., modeling
for one aspect of the software might be executed in
parallel with construction of another aspect of the
software).

Waterfall model
 The waterfall model takes the fundamental process
activities as separate process phases such as
requirements specification, software design,
implementation, and testing.
 It presents the software development process as a
number of stages

Cont’d

Cont’d
 Requirements analysis and definition
• The system’s services, constraints, and goals are
established by consultation with system users. They
are then defined in detail and serve as a system
specification.
 System and software design
• It establishes an overall system architecture. Software
design involves identifying and describing the
fundamental software system abstractions and their
relationships.
 Implementation and unit testing
• During this stage, the software design is realized as a
set of programs or program units. Unit testing involves
verifying that each unit meets its specification.

Cont’d
 Integration and system testing
 The individual program units or programs are
integrated and tested as a complete system to
ensure that the software requirements have been
met. After testing, the software system is delivered
to the customer.
 Operation and maintenance
 Normally, this is the longest life-cycle phase.
Maintenance involves correcting errors that were
not discovered in earlier stages of the life cycle.

Problems in Waterfall Model
 Real projects rarely follow the sequential flow that the
model proposes. Changes can cause confusion as
the project team proceeds.
 It is often difficult for the customer to state all
requirements explicitly.
 The customer must have patience. A working version
of the program(s) will not be available until late in the
project time span.
 Classic life cycle leads to “blocking states” in which
some project team members must wait for other
members of the team to complete dependent tasks.

When to use the waterfall model
This model is used only when :
 The requirements are very well known, clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available
freely
 The project is short.
 The waterfall model is not the right process model in
situations where informal team communication is
possible and software requirements change quickly.

Waterfall model is only appropriate for some types of
system:
 Embedded systems where the software has to interface
with hardware systems. Because of the inflexibility of
hardware, it is not usually possible to delay decisions on
the software’s functionality until it is being implemented.
 Critical systems where there is a need for extensive
safety and security analysis of the software specification
and design. In these systems, the specification and
design documents must be complete so that this analysis
is possible.
 Large software systems that are part of broader
engineering systems developed by several partner
Cont’d

Incremental Process Models
 There may be a compelling need to provide a limited
set of software functionality to users quickly and then
expand on that functionality in later software releases.
 It combines elements of linear and parallel process
flows.
 When an incremental model is used, the first
increment is often a core product.
 That is, basic requirements are addressed but many
supplementary features (some known, others
unknown) remain undelivered.
 The incremental process model focuses on the
delivery of an operational product with each increment

Cont’d
 Each linear sequence produces deliverable
“increments” of the software in a manner that is
similar to the increments produced by an evolutionary
process flow.
Example: word-processing software
First increment: basic file management, editing, and
document production functions.
Second increment: more sophisticated editing and
document production capabilities.
Third increment: spelling and grammar checking.
Fourth increment: advanced page layout capability

Advantages of Incremental
models
 Generates working software quickly and early
during the software life cycle.
 This model is more flexible – less costly to
change scope and requirements.
 It is easier to test and debug during a smaller
iteration.
 Customer feedback is received after the
delivery of each component
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces
are identified and handled during it’s iteration.

Disadvantage's of Incremental
models
 Needs good planning and design.
 Needs a clear and complete definition of the whole
system before it can be broken down and built
incrementally.
 Total cost is higher than waterfall.

When to use Incremental Models
 It is useful when staffing is unavailable for a
complete implementation by the business
deadline that has been established for the
project.
 Increments can be planned to manage technical
risks.
Say need of hardware.
 Enabling partial functionality to be delivered to
end users without inordinate delay.
 Major requirements must be defined; however,
some details can evolve with time.
 There is a need to get a product to the market
early.
 A new technology is being used.

Evolutionary Process Models
 Software, like all complex systems, evolves over
a period of time.
 You need a process model that has been
explicitly designed to accommodate a product
that evolves over time.
 Evolutionary models are iterative.
 They are characterized in a manner that enables
you to develop increasingly more complete
versions of the software.
Two common evolutionary process models:
i. Prototyping
ii. The spiral model

Prototyping
A prototyping paradigm may offer the best approach when:
 A customer defines a set of general objectives for
software, but does not identify detailed requirements for
functions and features.
 The developer may be unsure of the efficiency of an
algorithm, the adaptability of an operating system, or the
form that human-machine interaction should take.
 It can be used as a stand-alone process model, it is more
commonly used as a technique that can be implemented
within the context of any one of the process models.
 Prototyping paradigm assists you and other stakeholders
to better understand what is to be built when
requirements are fuzzy.

Cont’d
Both stakeholders and software engineers like the
prototyping paradigm. Users get a feel for the actual system,
and developers get to build something immediately.

The Spiral Model
 The spiral model is an evolutionary software
process model that couples the iterative nature
of prototyping with the controlled and
systematic aspects of the waterfall model.
 It provides the potential for rapid development
of increasingly more complete versions of the
software.
 The spiral development model is a risk-driven
process model generator that is used to guide
multi-stakeholder concurrent engineering of

It has two main distinguishing features:
1. One is a cyclic approach for incrementally growing a
system’s degree of definition and implementation while
decreasing its degree of risk.
2. The other is a set of anchor point milestones for
ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.
 Using the spiral model, software is developed in a series
of evolutionary releases.
 During early iterations, the release might be a model or
prototype. During later iterations, increasingly more
complete versions of the engineered system are
produced.
 Spiral model is divided into a set of framework activities
defined by the software engineering team.

When to use spiral model
 When releases are required to be frequent
 When the project is large
 When the amount of risk is large
 Where the requirements are unclear and complex
 Where requirement may change at any time

Characteristics of Spiral Model
 Unlike other process models that end when software
is delivered, the spiral model can be adapted to
apply throughout the life of the computer software.
 The spiral model is a realistic approach to the
development of large-scale systems and software.
Because software evolves as the process
progresses.
 The developer and customer better understand and
react to risks at each evolutionary level.
 The spiral model uses prototyping as a risk reduction
mechanism but, more important, enables you to
apply the prototyping approach at any stage in the
evolution of the product.

Issues regarding Spiral Model
 The spiral model is not a panacea.
 It may be difficult to convince customers (particularly
in contract situations) that the evolutionary approach
is controllable.
 It demands considerable risk assessment expertise
and relies on this expertise for success. If a major risk
is not uncovered and managed, problems will
undoubtedly occur.
 It is much complex than other SDLC, deals mostly
with large projects

Component-Based Development
 Commercial off-the-shelf (COTS) software
components, developed by vendors who offer them as
products, provide targeted functionality with well-
defined interfaces that enable the component to be
integrated into the software that is to be built.
 The component-based development model
incorporates many of the characteristics of the spiral
model.
 It is evolutionary in nature, demanding an iterative
approach to the creation of software.
 However, the component-based development model
constructs applications from prepackaged software
components.

Cont’d
• Modeling and construction activities begin with the
identification of candidate components.
• These components can be designed as either
conventional software modules or object-oriented
classes or packages of classes.

Steps involved in Component-Based
Development Model
1. Available component-based products are
researched and evaluated for the application domain.
2. Component integration issues are considered.
3. A software architecture is designed to
accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure
proper functionality.

Benefits of Component-Based
Development
 The component-based development model leads to
software reuse, and reusability provides software
engineers with a number of measurable benefits.
 Your software engineering team can achieve a
reduction in development cycle time as well as a
reduction in project cost if component reuse becomes
part of your culture.

Elementary Probability theory Chapter 2.pptx

Recommended

Recommended

More Related Content

Similar to Elementary Probability theory Chapter 2.pptx

Similar to Elementary Probability theory Chapter 2.pptx (20)

More from ethiouniverse

More from ethiouniverse (13)

Recently uploaded

Recently uploaded (20)

Elementary Probability theory Chapter 2.pptx