The document discusses software process models. It describes the waterfall model, which is a generic process framework for software engineering that defines five framework activities: communication, planning, modeling, construction, and deployment. It also discusses umbrella activities that are applied throughout the process, such as project tracking and control. The waterfall model prescribes distinct activities, actions, tasks, milestones, and work products for software development. However, process models need to be adapted to meet the needs of specific projects.

1. 1

2. Unit-1
Introduction to Software and
Software Engineering
2

3. Software’s Dual Role (Nature of Software)
• Software is a product
– Transforms information - produces, manages, acquires,
modifies, displays, or transmits information
– Delivers computing potential of hardware and networks
(WITHOUT S/W DIFFICULT TO OPERATE H/W)
• Software is a vehicle for delivering a product
– Controls other programs (operating system)
– Effects communications (networking software)
– Helps build other software (software tools &
environments)
3

4. Software Products
• Generic products:
– Stand-alone systems which are produced by a
development organization and sold on the open
market to any customer.(e.g. Microsoft Products)
• Customized products:
– Systems which are commissioned by a specific
customer and developed specially by some
contractor.(e.g. College Mgmt. S/W)
4

5. Software
Applications
5
(1) System Software:
• System software is a collection of programs written
to service other programs.
• It is characterized by heavy interaction with
computer hardware; heavy usage by multiple users;
concurrent operation that requires scheduling,
resource sharing, and sophisticated process
management; complex data structures; and multiple
external interfaces.
Ex. Compilers, operating system, drivers etc.

6. (2) Application Software :
• Application software consists of standalone
programs that solve a specific business need.
• Application software is used to control the
business function in real-time.
• E.g. :Medical Store Mgmt. System
6

7. (3) Engineering /Scientific software:
• Characterized by "number crunching" algorithms.
• Applications range from astronomy to volcano logy,
from automotive stress analysis to space shuttle
orbital dynamics, and from molecular biology to
automated manufacturing.
Ex. Computer Aided Design (CAD), system stimulation
etc.
7

8. (4) Embedded Software:
• It resides in read-only memory and is used to
control products and systems
• Embedded software can perform limited and
esoteric functions.
Ex. keypad control for a microwave oven or
timer
8

9. (5) Product line software:
• Designed to provide a specific capability for
use by many different customers, product line
software can focus on a limited and esoteric
marketplace.
Ex. Word processing, spreadsheet, CG,
multimedia, etc.
9

10. (6) Web Applications:
• Web apps can be little more than a set of
linked hypertext files.
• It evolving into sophisticated computing
environments that not only provide
standalone features, functions but also
integrated with corporate database and
business applications.
10

11. (7) Artificial Intelligence software:
• AI software makes use of numerical & non-
numerical algorithms to solve complex
problems those are not amenable(easily
controlled) to computation or straightforward
analysis.
Ex. Robotics, expert system, game playing, etc.
11

12. Characteristics of Software
1] Software is developed or engineered
2] Software doesn’t “wear out.”
3] Although the industry is moving toward
component-based construction, most
software continues to be custom built.
12

13. Manufacturing vs. Development
• Once a hardware product has been manufactured, it
is difficult or impossible to modify. In contrast,
software products are routinely modified and
upgraded.
• In hardware, hiring more people allows you to
accomplish more work, but the same does not
necessarily hold true in software engineering.
• Unlike hardware, software costs are concentrated in
design rather than production.(Once demo is ready
then can produce multiple copy)
13

14. Wear vs.
Deterioration
Failure curve for Hardware
14
Earlier Failure
rate in its life
Earlier Failure
rate in its life
Affection from Dust,
Abuse, Temperature,
Environment etc
Affection from Dust,
Abuse, Temperature,
Environment etc

15. Wear vs. Deterioration
Software deteriorate over time
15

16. Component Based vs. Custom Built
• Hardware products typically employ many
standardized design components.
• Most software continues to be custom built.
• The software industry does seem to be moving
(slowly) toward component-based construction.
16

17. Hardware vs. Software
Hardware Software
 Manufactured
 Wears out
 Built using
components
 Relatively simple
Developed /
Engineered
 Deteriorates
 Custom built
 Complex
17

18. S/W Engineering
• Software Engineering is the science and art of
building significant software systems that are:
–1) on time
–2) on budget
–3) with acceptable performance
–4) with correct operation.
18

19. S/W Engineering
19
– A discipline whose aim is the production of
quality software, delivered on time, within
budget, and satisfying users' needs
– The specification, development,
management, and evolution of software
systems
– Designing and developing high-quality
software

20. S/W Engineering
• The economies of all developed nations are
dependent on software.
• More and more systems are software
controlled.
• Software engineering is concerned with
theories, methods and tools for professional
software development.
20

21. Software Myths
Definition: Beliefs about software and the process
used to build it.
Myths have number of attributes that have made them
insidious (i.e. dangerous).
• Misleading Attitudes - caused serious problem for
managers and technical people.

22. Management myths
Managers in most disciplines, are often under pressure to
maintain budgets, keep schedules on time, and improve
quality.
Myth1: We already have a book that's full of standards
and procedures for building software, it does provide my
people with everything they need to know.
Reality :
• Are software practitioners aware of existence standards?
• Does it reflect modern software engineering practice?
• Is it complete? Is it streamlined to improve time to
delivery while still maintaining a focus on quality?
•In many cases, the answer to all of these questions is "no."

23. Customer Myths
• Myth: A general statement of objectives is sufficient to begin writing
programs— we can fill in the details later.
(E.g. only def. is der clg mgmt sys.)
• Reality: A poor up-front definition is the major cause of failed software
efforts.
• A formal and detailed description of the information domain, function,
behavior, performance, interfaces,
design constraints, and validation criteria is essential.
characteristics can be determined only after thorough communication
between customer and developer.

24. • Myth: Project requirements continually change, but
change can be easily accommodated because software is
flexible. (E.g. Wipro-IPCA exp.)
• Reality: It is true that software requirements change, but
the impact of change varies with the time at which it is
introduced.
• If serious attention is given to up-front definition, early
requests for change can be accommodated easily with
relatively little impact on cost.
When changes are requested during software design, during
implementation (code and test) the cost impact grows
rapidly.

25. Software Myths
• Myth: If we get behind schedule, we can add more programmers
and catch up (sometimes called the Mongolian horde concept).
• Reality Software development is not a mechanistic process like
manufacturing.
• In the words: "adding people to a late software project makes it
later." At first, this statement may seem counterintuitive.
• However, as new people are added, people who were working
must spend time educating the newcomers, thereby reducing the
amount of time spent on productive development effort.
• People can be added but only in a planned and well- coordinated
manner.

26. Software Myths
• Once we write a working program, we’re done.
• Until I get the program running, I have no way of
assessing its quality.
• The only deliverable work product for a successful
project is the working program.
• Software engineering will make us create too much
documentation and will slow us down.
26

27. Practitioner's myths
• Myth: Once we write the program and get it to
work, our job is done.
• Reality: Expert said "the sooner you begin
'writing code', the longer it'll take you to get
done."
• Industry data indicate that between 60 and 80
percent of all effort expended on software will be
expended after it is delivered to the customer for
the first time.

28. • Myth: Until I get the program "running" I
have no way of assessing its quality.
• Reality: One of the most effective software
quality assurance mechanisms can be
applied from the inception of a project—
the formal technical review.
• Software reviews are a "quality filter" that
have been found to be more effective than
testing for finding certain classes of
software defects.

29. • Myth: The only deliverable work product
for a successful project is the working
program.
• Reality: A working program is only one
part of a software configuration that
includes many elements.
• Documentation provides a foundation
for successful engineering and, more
important, guidance for software
support.

30. • Myth: Software engineering will make us
create voluminous and unnecessary
documentation and will invariably slow us
down.
• Reality: Software engineering is not about
creating documents. It is about creating
quality
• Better quality leads to reduced rework. And
reduced rework results in faster delivery
times.

31. The Software Process
• What? A software process – as a framework for the
tasks that are required to build high-quality software.
• Who does? Managers, software engineers, and customers.
• Why? Provides stability, control, and organization
otherwise chaotic(disorder) activity.
• Steps? General activities are common to all software
processes, details vary.
• Work product? Programs, documents, and data.

32. What is software Engg.?
• Definition :
– (1) The application of 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) above
• Its a discipline that is concerned with all aspects of software production.
• Software engineers should adopt
– Systematic and organized approach to their work
– Use appropriate tools and techniques depending on the problem
to be solved
– The development constraints and the resources available
• Apply Engineering Concepts to developing Software
• Challenge for Software Engineers is to produce high quality software with
finite amount of resources & within a predicted schedule

33. Software Engineering – Layered
Technology
Layered Technology
A quality focus: theA quality focus: the “bedrock“bedrock””
Process model: theProcess model: the “framework”“framework”
Methods: technicalMethods: technical “how to’s”“how to’s”
Tools: CASE preferredTools: CASE preferred

34. Layered Technology
A quality Focus
• Every organization is rest on its commitment to quality.
• Total quality management, Six Sigma, or similar continuous
improvement culture and it is this culture ultimately leads to development
of increasingly more effective approaches to software engineering.
• The bedrock(foundation) that supports software engineering is a quality
focus.
Process:
• It’s a foundation layer for software engineering.
• It’s define framework for a set of key process areas (KPA) for effectively
manage and deliver quality software in a cost effective manner
• The processes define the tasks to be performed and the order in which
they are to be performed
• Provides the glue that holds the layers together;

35. Layered Technology
Methods:
• It provide the technical how-to's for building software.
• Methods encompass a broad array of tasks that include requirements analysis,
design, program construction, testing, and support.
• There could be more than one technique to perform a task and different
techniques could be used in different situations.
Tools:
• Provide automated or semi-automated support for the process, methods and
quality control.
• When tools are integrated so that information created by one tool can be used
by another, a system for the support of software development, called
computer-aided software engineering (CASE)

36. Generic Process Framework
• A process framework establishes the
foundation for a complete software process
by identifying a small number of framework
activities.
• Frame work activities are applicable to all
software projects.

37. Generic Process Model
 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?

38. Process framework
Why process :
A process defines who is doing what, when and how to
reach a certain goal to build complete software process.
• Identified a small number of framework activities that are
applicable to all software projects, regardless of their size
or complexity.
• It encompasses a set of umbrella activities that are
applicable across the entire software process.

39. Process Framework
•Each framework
activities is populated
by a set for software
engineering actions – a
collection of related
tasks.
• Each action has
individual work task.

40. Generic Process Framework
Activities
• Communication:
– Heavy communication with customers, stakeholders, team
– Encompasses requirements gathering and related activities
• Planning:
– Workflow that is to follow
– Describe technical task, likely risk, resources will require,
work products to be produced and a work schedule.
• Modeling:
– Help developer and customer to understand requirements
(Analysis of requirements) & Design of software
• Construction:
– Code generation: either manual or automated or both
– Testing – to uncover error in the code.
• Deployment:
– Delivery to the customer for evaluation
– Customer provide feedback

41. Umbrella Activities
• Software project Management or tracking and control
– Assessing progress against the project plan.
– Take adequate action(Sufficient) to maintain schedule.
• Formal technical reviews
– Assessing software work products in an effort to uncover and remove
errors before goes into next action or activity.
• Software quality assurance
– Define and conducts the activities required to ensure software quality.
• Software configuration management
– Manages the effects of change.
• Document preparation and production
– Help to create work products such as models, documents, logs, form and list.
• Reusability management
– Define criteria for work product reuse
– Mechanisms to achieve reusable components.
• Measurement
– Define and collects process, project, and product measures
– Assist the team in delivering software that meets customer’s needs.
• Risk management
– Assesses risks that may effect that outcome of project or quality of product (i.e.
software)

42. Capability Maturity Model
Integration (CMMI)
• The Software Engineering Institute (SEI) has developed
process meta-model to measure organization different level
of process capability and maturity.
• CMMI – developed by SEI
• The CMMI defines each process area in terms of “specific
goals” and the “specific practices” required to achieve these
goals.
• Specific goals establish the characteristics that must exist
if the activities implied by a process area are to be
effective.
• Specific practices refine a goal into a set of process-
related activities.

43. CMMI Level
Level 1: Initial. The software process is characterized as
ad hoc and occasionally even chaotic.
Few processes are defined, and success depends on individual effort.
Level 2: Repeatable. Basic project management processes
are established to track cost, schedule, and functionality.
The necessary process discipline is in place to repeat earlier successes on
projects with similar applications.

44. CMMI Level (cont.)
Level 3: Defined.
 The software process for both management and engineering activities is documented,
standardized, and integrated into an organization wide software process.
 All projects use a documented and approved version of the organization's process
for developing and supporting software.
 This level includes all characteristics defined for level 2.
Level 4 (Quantitatively Managed) -
– All level 3 criteria have been satisfied.
– Software process and products are quantitatively understood
– Controlled using detailed measures and assessment.
Level 5 (Optimized)
– This level includes all characteristics defined for level 4.
– Continuous process improvement is enabled by quantitative feedback from the
process and testing innovative ideas & technology

45. HemalKumar Rajyaguru

46. • The process model can be defined as the abstract representation of
process.
• Process models prescribe a distinct set of activities, actions,
tasks, milestones, and work products required to engineer high
quality software.
• Process models are not perfect, but provide roadmap for
software engineering work.
• Software models provide stability, control, and organization to a
process that if not managed can easily get out of control
• Software process models are adapted to meet the needs of software
engineers and managers for a specific project.
Software process model /
SDLC

47. HemalKumar Rajyaguru
Waterfall Model or Classic Life
Cycle(CPMCD)

48. • Requirement Analysis and Definition: The systems services, constraints and goals
are defined by customers with system users.
• Scheduling tracking -
– Assessing progress against the project plan.
– Require action to maintain schedule.
• System and Software Design: How –It establishes and overall system architecture.
Software design involves fundamental system abstractions and their relationships.
• Integration and system testing: The individual program unit 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 phase of the software life
cycle. The system is installed and put into practical use. Maintenance involves correcting errors
which were not discovered in earlier stages of the life-cycle.
Waterfall Model or Classic Life
Cycle

49. Limitations of the waterfall model
 The nature of the requirements will not change very much During
development; during evolution
 The model implies that you should attempt to complete a given stage before
moving on to the next stage
 Does not account for the fact that requirements constantly change.
 It also means that customers can not use anything until the entire system
is complete.
 The model implies that once the product is finished, everything else is
maintenance.
 Surprises at the end are very expensive
 Some teams sit ideal for other teams to finish
 Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.

50. • Problems:
1. Real projects are rarely follow the sequential
model.
2. Difficult for the customer to state all the
requirement in advance.
3. Assumes patience from customer - working
version of program will not available until
programs not getting change fully.
Problem

51. Waterfall Model with Feedback
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback

52. Incremental Process Model
C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment
Delivers software in small but usable pieces,
each piece builds on pieces already delivered

53. • Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments with
each increment delivering part of the required functionality.
• First Increment is often core product
– Includes basic requirement
– Many supplementary features (known & unknown) remain
undelivered
• A plan of next increment is prepared
– Modifications of the first increment
– Additional features of the first increment
• It is particularly useful when enough staffing is not available
for the whole project
• Increment can be planned to manage technical risks.
• Incremental model focus more on delivery of operation
product with each increment.
The Incremental Model

54. • User requirements are prioritised and the highest priority
requirements are included in early increments.
• Once the development of an increment is started, the requirements are
frozen though requirements for later increments can continue to
evolve.
• Customer value can be delivered with each increment so system
functionality is available earlier.
• Early increments act as a prototype to help obtain requirements for later
increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most
testing.
The Incremental Model