• Computer software is the product that software engineers design

and build.
• It is programs that execute within a computer of any size and
architecture, documents that the hard-copy and virtual forms, and
data that combine numbers and text but also includes
representations of pictorial, video, and audio information.

2
BYTE COMPUTERS
96625 01148
• Software is
• (1) Instructions (computer programs) that when executed provide
desired function and performance,
• (2) Data Structures that enable the programs to
adequately(sufficient for the purpose) manipulate information, and
• (3) Documents that describe the operation and use of the
programs.

3
BYTE COMPUTERS
96625 01148
 1) Software is developed or engineered, it is not manufactured in
the classical sense :
• Although some similarities exist between software development
and hardware manufacture, the two activities are fundamentally
different.
• → In both activities, high quality is achieved through good design,
but the manufacturing phase for hardware can introduce quality
problems that are nonexistent (or easily corrected) for software.
• → Both activities are dependent on people, but the relationship
between people applied and work accomplished is entirely
different.
BYTE COMPUTERS
4
96625 01148
• → Both activities require the construction of a "product" but the
approaches are different. Software costs are concentrated in
engineering.

5
BYTE COMPUTERS
96625 01148
2) Software doesn't "wear out."

6
BYTE COMPUTERS
96625 01148
• Figure 1.1 depicts failure rate as a function of time for hardware.
The relationship, often called the "bathtub curve“.
• It indicates that hardware exhibits relatively high failure rates early
in its life (these failures are often attributable to design or
manufacturing defects); defects are corrected and the failure rate
drops to a steady-state level (ideally, quite low) for some period of
time.
• As time passes, however, the failure rate rises again as hardware
components suffer from the cumulative affects of dust, vibration,
abuse, temperature extremes, and many other environmental
maladies. Stated simply, the hardware begins to wear out. 7
BYTE COMPUTERS
96625 01148
 8
BYTE COMPUTERS
96625 01148
• The failure rate curve for software should take the form of the
“idealized curve” shown in Figure 1.2. Undiscovered defects will
cause high failure rates early in the life of a program.
• However, these are corrected (ideally, without introducing other
errors) and the curve flattens as shown. However, the implication is
clear—software doesn't wear out. But it does deteriorate!
• As changes are made, it is likely that some new defects will be
introduced, causing the failure rate curve to spike.
• Slowly, the minimum failure rate level begins to rise—the software
is deteriorating due to change.
9
BYTE COMPUTERS
96625 01148
• There are no software spare parts. Every software failure indicates
an error in design or in the process through which design was
translated into machine executable code.

10
BYTE COMPUTERS
96625 01148
3) Although the industry is moving toward component-based
assembly, most software continues to be custom built.
• The reusable components have been created so that the engineer
can concentrate on the truly innovative elements of a design, that
is, the parts of the design that represent something new.
• In the 1960s, we built scientific subroutine libraries that were
reusable in a broad array of engineering and scientific
applications.
• These subroutine libraries reused well-defined algorithms in an
effective manner but had a limited domain of application.
11
BYTE COMPUTERS
96625 01148
• For example, today's graphical user interfaces are built using
reusable components that enable the creation of graphics
windows, pull-down menus, and a wide variety of interaction
mechanisms.

12
BYTE COMPUTERS
96625 01148
1) System software:
• System software is a collection of programs written to service
other programs. Some system software (e.g., compilers, editors,
and file management utilities) process complex.
• Other systems applications (e.g., operating system components,
drivers, telecommunications processors) process largely
indeterminate data.

13
BYTE COMPUTERS
96625 01148
2) Real-time software:
• Software that monitors/analyzes/controls real-world events as
they occur is called real time. Elements of real-time software
include a data gathering component that collects and formats
information from an external environment,

14
BYTE COMPUTERS
96625 01148
3) Business software:
• Business information processing is the largest single software
application area. Discrete "systems" (e.g., payroll, accounts
receivable/payable, inventory) have evolved into management
information system (MIS) software that accesses one or more
large databases containing business information.

15
BYTE COMPUTERS
96625 01148
4) Engineering and scientific software:
• Engineering and scientific software have been characterized by
"number crunching" algorithms. Molecular biology to automated
manufacturing.
• However, modern applications within the engineering/scientific
area are moving away from conventional numerical algorithms.
Computer-aided design, system simulation, and other interactive
applications have begun to take on real-time and even system
software characteristics.

16
BYTE COMPUTERS
96625 01148
5) Embedded software:
• Intelligent products have become commonplace in nearly every
consumer and industrial market.
• Embedded software resides in read-only memory and is used to
control products and systems.
• Embedded software can perform very limited and esoteric
functions (e.g., keypad control for a microwave oven) or provide
significant function and control capability (e.g., digital functions in
an automobile such as fuel control, dashboard displays, and
braking systems).
17
BYTE COMPUTERS
96625 01148
6) Personal computer software:
• Word processing, spreadsheets, computer graphics, multimedia,
entertainment, database management, personal and business
financial applications, external network, and database access are
only a few of hundreds of applications.

18
BYTE COMPUTERS
96625 01148
7) Web-based software:
• The Web pages retrieved by a browser are software that
incorporates executable instructions (e.g., CGI, HTML, Perl, or
Java), and data (e.g., hypertext and a variety of visual and audio
formats).
• In essence, the network becomes a computer providing an almost
unlimited software resource that can be accessed by anyone with
a modem.

19
BYTE COMPUTERS
96625 01148
8) Artificial intelligence software:
• Artificial intelligence (AI) software makes use of non numerical
algorithms to solve complex problems.
• Expert systems, also called knowledge based systems, pattern
recognition (image and voice), theorem proving, and game playing
are representative of applications within this category.

20
BYTE COMPUTERS
96625 01148
• Management Myths
• Myth: We already have a book that's full of standards and
procedures for building software, won't that provide my people with
everything they need to know?
• Reality: The book of standards may very well exist, but is it used?
Are software practitioners aware of its existence? Does it reflect
modern software engineering practice? Is it complete? Is it
improve time to delivery while still maintaining a focus on quality?
In many cases, the answer to all of these questions is "no."

21
BYTE COMPUTERS
96625 01148
• Myth: My people have state-of-the-art software development tools,
after all, we buy them the newest computers.
• Reality: It takes much more than the latest model mainframe,
workstation, or PC to do high-quality software development.
Computer-aided software engineering (CASE) tools are more
important than hardware for achieving good quality and
productivity,

22
BYTE COMPUTERS
96625 01148
• 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 of Brooks: "adding people to a late
software project makes it later." 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.

23
BYTE COMPUTERS
96625 01148
• Myth: If I decide to outsource the software project to a third party, I
can just relax and let that firm build it.
• Reality: If an organization does not understand how to manage
and control software projects internally,it will struggle when it out
sources software projects.

24
BYTE COMPUTERS
96625 01148
• Myth: A general statement of objectives is sufficient to begin
writing program we can fill in the details later.
• 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. These
characteristics can be determined only after through
communication between customer and developer.

25
BYTE COMPUTERS
96625 01148
• Myth: Project requirements continually change, but change can be
easily accommodated because software is flexible.
• Reality: It is true that software requirements change, but the
impact of change varies with the time at which it is introduced.
Figure 1.3 illustrates the impact of change.
• If serious attention is given to up-front definition, early requests for
change can be accommodated easily.
• The customer can review requirements and recommend
modifications with relatively little impact on cost.

26
BYTE COMPUTERS
96625 01148
• When changes are requested during software design, the cost
impact grows rapidly. Changes in function, performance, interface,
or other characteristics during implementation (code and test)
have a severe impact on cost.

27
BYTE COMPUTERS
96625 01148
 28
BYTE COMPUTERS
96625 01148
• Myth: Once we write the program and get it to work, our job is
done.
• Reality: Someone once said that "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.

29
BYTE COMPUTERS
96625 01148
• 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.

30
BYTE COMPUTERS
96625 01148
• 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.

31
BYTE COMPUTERS
96625 01148
• 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.

32
BYTE COMPUTERS
96625 01148
• Software Development Life Cycle.
Planning

Deploy - Maintenance Defining / Analysis

Testing Designing

Coding -
Implementation
33
BYTE COMPUTERS
96625 01148
• Linear Sequential Model
• Sometimes called the classic life cycle or the waterfall model, the
linear sequential model suggests a systematic, sequential
approach to software development that begins at the system level
and progresses through analysis, design, coding, testing, and
support.

34
BYTE COMPUTERS
96625 01148
 35
BYTE COMPUTERS
96625 01148
• System/information engineering and modeling.
• This system view is essential when software must interact with other elements
such as hardware, people, and databases. System engineering and analysis
encompass requirements gathering at the system level with a small amount of
top level design and analysis.
• Software requirements analysis. The requirements gathering process is focused
specifically on software. To understand the nature of the program(s) to be built,
the software engineer ("analyst") must understand the information domain for
the software, as well as required function, behavior, performance, and
interface. Requirements for both the system and the software are documented
and reviewed with the customer.

36
BYTE COMPUTERS
96625 01148
• Design. Software design is actually a multi step process that focuses
on four distinct attributes of a program: data structure, software
architecture, interface representations, and procedural
(algorithmic) detail. The design process translates requirements into
a representation of the software that can be assessed for quality
before coding begins.
• Code generation. The design must be translated into a machine-
readable form. The code generation step performs this task. If design
is performed in a detailed manner, code generation can be
accomplished.
37
BYTE COMPUTERS
96625 01148
• Testing. Once code has been generated, program testing begins. The
testing process focuses on the logical internals of the software, ensuring
that all statements have been tested, and on the functional externals;
that is, conducting tests to uncover errors and ensure that defined input
will produce actual results that agree with required results.
• Support. Software will undoubtedly change after it is delivered to the
customer (a possible exception is embedded software). Change will occur
because errors have been encountered, because the software must be
adapted to accommodate changes in its external environment (e.g., a
change required because of a new operating system or peripheral device).

38
BYTE COMPUTERS
96625 01148
• Among the problems that are sometimes encountered when the linear
sequential model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes. As a
result, changes can cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly.
3. The customer must have patience. A working version of the program(s) will not
be available until late in the project time-span.
In an interesting analysis of actual projects, found that the linear nature of the
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.

39
BYTE COMPUTERS
96625 01148
• Advantage • Dis – Advantage
• Basic Model • Rigid
• Simple and Easy • No feedback
• Small Projects • No Experiment
• No Parallelism
• High Risk ( No Flexible)

BYTE COMPUTERS
40
96625 01148
• The prototyping paradigm (Figure 2.5) begins with requirements
gathering. Developer and customer meet and define the overall
objectives for the software, identify whatever requirements are known,
and outline areas where further definition is mandatory.
• A "quick design" then occurs. The quick design focuses on a
representation of those aspects of the software that will be visible to the
customer/user (e.g., input approaches and output formats).
• The quick design leads to the construction of a prototype. The prototype
is evaluated by the customer/user and used to refine requirements for the
software to be developed.

41
BYTE COMPUTERS
96625 01148
 42
BYTE COMPUTERS
96625 01148
- Misunderstandings between software users and developers are
solved.
- Missing services may be detected.
- Confusing services may be identified
- A working system is available early in the process

43
BYTE COMPUTERS
96625 01148
• 1. The customer sees what appears to be a working version of the
software, unaware that the prototype is held together “with chewing
gum and baling wire,” unaware that in the rush to get it working no
one has considered overall software quality or long-term
maintainability.
• 2. The developer often makes implementation compromises in order
to get a prototype working quickly. An inappropriate operating
system or programming language may be used simply because it is
available and known; an inefficient algorithm may be implemented
simply to demonstrate capability, although problems can occur,
prototyping can be an effective paradigm for software engineering.
44
BYTE COMPUTERS
96625 01148
 Requirement Gathering

Quick Design

Refinement Suggestion Build Prototype

Customer Evolution

45
BYTE COMPUTERS
96625 01148
• Advantage • Dis – Advantage
• Customer not Clear with idea. • Increase in cost of
• Throwaway Model Development
• Good for technical and • Don’t give whole Model in One
Requirement – time.

BYTE COMPUTERS
46
96625 01148
• The incremental model combines elements of the linear sequential
model (applied repetitively) with the iterative philosophy of
prototyping.
• Referring to Figure 2.7, the incremental model applies linear
sequences in a staggered(To arrange in a systematic order) fashion as
calendar time progresses.
• Each linear sequence produces a deliverable “increment” of the
software.

47
BYTE COMPUTERS
96625 01148
• For example, word-processing software developed using the
incremental paradigm might deliver basic file management,
editing, and document production functions in the first increment;
• more sophisticated editing and document production capabilities in
the second increment;
• spelling and grammar checking in the third increment; and
• advanced page layout capability in the fourth increment. It should
be noted that the process flow for any increment can incorporate the
prototyping paradigm.

48
BYTE COMPUTERS
96625 01148
 49
BYTE COMPUTERS
96625 01148
- Develop High Risk or Major Function First.
- Each release delivers an Operational Product.
- Customer can respond to each Build.
- Uses “Divided and Conquer” breakdown of tasks.
- Lower initial delivery cost.
- Initial product delivery cost.
- Customers get important functionality early.

50
BYTE COMPUTERS
96625 01148
• A spiral model is divided into a number of framework activities, also
called task regions.
• Typically, there are between three and six task regions.
• Figure 2.8 depicts a spiral model that contains six task regions:
• Customer communication—tasks required to establish effective
communication between developer and customer.
• Planning—tasks required to define resources, timelines, and other
project related information.

51
BYTE COMPUTERS
96625 01148
• Risk analysis—tasks required to assess both technical and
management risks.
• Engineering—tasks required to build one or more representations
of the application.
• Construction and release—tasks required to construct, test, install,
and provide user support (e.g., documentation and training).
• Customer evaluation—tasks required to obtain customer feedback
based on evaluation of the software representations created during the
engineering stage and implemented during the installation stage.

52
BYTE COMPUTERS
96625 01148
 53
BYTE COMPUTERS
96625 01148
• Each of the regions is populated by a set of work tasks, called a
task set, that are adapted to the characteristics of the project to be
undertaken.
• For small projects, the number of work tasks and their formality
is low. For larger, more critical projects, each task region contains
more work tasks that are defined to achieve a higher level of
formality.

54
BYTE COMPUTERS
96625 01148
• Advantage • Dis – Advantage
• Risk Handling • Complex
• Large Projects • Expensive
• Flexible • Too much Risk Analysis
• Customer Satisfaction • Time

BYTE COMPUTERS
55
96625 01148