0% found this document useful (0 votes)
7 views

Unit 1 - Part 1

The lecture introduces software engineering as a systematic approach to software development, emphasizing the importance of life cycle models and the evolution from exploratory to structured practices. It highlights the dual role of software as both a product and a means to deliver functionality, while addressing common myths and the software crisis. The adoption of life cycle models is presented as essential for managing complexity and ensuring quality in software projects.

Uploaded by

devansh kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

Unit 1 - Part 1

The lecture introduces software engineering as a systematic approach to software development, emphasizing the importance of life cycle models and the evolution from exploratory to structured practices. It highlights the dual role of software as both a product and a means to deliver functionality, while addressing common myths and the software crisis. The adoption of life cycle models is presented as essential for managing complexity and ensuring quality in software projects.

Uploaded by

devansh kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 61

Introduction to Software

Engineering (LECT 1)

Mayank Singh

1
Organization of this Lecture
● What is Software Engineering?
● Programs vs. Software Products
● Evolution of Software Engineering
● Notable Changes In Software
Development Practices
● Introduction to Life Cycle Models
● Summary

2
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
Technology Development
Pattern
Engineering
Esoteric Past
Experience
Technology

Craft
Systematic Use of Past
Experience and Scientific Basis

Unorganized Use of
Art Past Experience

Time

5
Why Study Software
Engineering? (1)
● To acquire skills to develop
large programs.
– Exponential growth in complexity
and difficulty level with size.
– Thead hoc approach breaks down
when size of software increases.

6
Why Study Software
Engineering? (2)
● Ability to solve complex
programming problems:
– How to break large projects into smaller
and manageable parts?
– How to use abstraction?

● Also learn techniques of:


– Specification, design, user interface
development, testing, project
management, etc. 7
Why Study Software Engineering?
(3)

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

8
Software’s Dual Role
● Software is a product
– Delivers computing potential
– Produces, manages, acquires, modifies, displays, or
transmits information
● Software is a vehicle for delivering a product
– Supports or directly provides system functionality
– Controls other programs (e.g., an operating
system)
– Effects communications (e.g., networking software)
– Helps build other software (e.g., software tools)

9
What is Software?

Software is a set of items or objects


that form a “configuration” that
includes
• programs
• documents
• data ...

10
Characteristics Software?

● software is engineered
● software doesn’t wear out
● software is complex

11
Failure Curve for Hardware

12
Idealized and Actual Failure
curve for Software

13
Software Myths
● Management
● 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?
● My people have state-of-the-art software
development tools, after all, we buy them the
newest computers.
● If we get behind schedule, we can add more
programmers and catch up
● If I decide to outsource3 the software project to a
third party, I can just relax and let that firm build
it.
14
Software Myths
● Customer
● A general statement of objectives is
sufficient to begin writing programs—we can
fill in the details later.

● Project requirements continually change, but


change can be easily accommodated because
software is flexible.

15
Impact of Changes

16
Software Myths
● Practitioner’s
● Once we write the program and get it to work, our
job is 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 voluminous


and unnecessary documentation and will invariably
slow us down.
17
Software Crisis?

● "the turning point in the course of a


disease, when it becomes clear whether
the patient will live or die.

18
Software Crisis
● Software products:
– Failto meet user requirements.
– Frequently crash.
– Expensive.
– Difficult to alter, debug, and
enhance.
– Often delivered late.
– Use resources non-optimally.
19
Software Crisis (cont.)

Hw cost
Sw cost

1960 Year
2008

Relative Cost of Hardware and Software


20
Factors Contributing to the
Software Crisis
● Larger problems,
● Lack of adequate training in
software engineering,
● Increasing skill shortage,
● Low productivity improvements.

21
What is software
engineering?
● Software engineering is an engineering
discipline which is concerned with all
aspects of software production

● Software engineers should adopt a


systematic and organised approach to
their work and use appropriate tools and
techniques depending on the problem to
be solved, the development constraints
and the resources available
22
Software 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

23
What are the costs of
software engineering?
● Roughly 40% of costs are development
costs, 60% are testing costs. For custom
software, evolution costs often exceed
development costs
● Costs vary depending on the type of system
being developed and the requirements of
system attributes such as performance and
system reliability
● Distribution of costs depends on the
development model that is used 24
SE Layered Process

25
Types of Software Projects
● Software products
● Outsourced projects
● Indian companies have focused
on outsourced projects.

26
Software Applications

● system software
● application software
● engineering/scientific software
● embedded software
● product-line software
● WebApps (Web applications)
● AI software

27
Programs versus Software
Products
● Usually small in size ● Large
● Author himself is sole ● Large number of
user users
● Single developer ● Team of developers
● Lacks proper user ● Well-designed
interface interface
● Lacks proper ● Well documented &
documentation user-manual prepared
● Systematic
● Ad hoc development. development

28
Evolution of an Art into an
Engineering Discipline
● The early programmers used an
exploratory (also called build and fix)
style.
– In the build and fix (exploratory) style,
normally a `dirty' program is quickly
developed.
– The different imperfections that are
subsequently noticed are fixed.

29
What is Wrong with the
Exploratory Style?
● Can successfully be used for very small
programs only.
Software
Exploratory Engineering
Effort, time,

Machine
cost

Program Size

30
What is Wrong with the
Exploratory Style? Cont…
● Besides the exponential growth of
effort, cost, and time with problem
size:
– Exploratory style usually results in
unmaintainable code.
– It becomes very difficult to use the
exploratory style in a team development
environment.
31
What is Wrong with the
Exploratory Style? Cont…
● Why does the effort required
to develop a product grow
exponentially with product size?
– Why does the approach
completely breaks down when the
product size becomes large?

32
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.
33
Differences between the exploratory
style and modern software
development practices
● Emphasis has shifted
– from error correction to error
prevention.
● Modern practices emphasize:
– detection of errors as close to
their point of introduction as
possible.

34
Differences between the exploratory
style and modern software
development practices (CONT.)
● In exploratory style,
– errors are detected only
during testing,
● Now,
– focus is on detecting as many
errors as possible in each
phase of development.

35
Differences between the exploratory
style and modern software
development practices (CONT.)

● In exploratory style,
– coding
is synonymous with
program development.
● Now,
– codingis considered only a
small part of program
development effort.
36
Differences between the exploratory
style and modern software
development practices (CONT.)
● 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.

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

38
Differences between the exploratory
style and modern software
development practices (CONT.)
● 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.

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

40
Differences between the exploratory
style and modern software
development practices (CONT.)
● Projects are being thoroughly
planned:
– estimation,
– scheduling,
– monitoring mechanisms.
● Use of CASE tools.

41
Evolution of Other Software
Engineering Techniques
– life cycle models,
– specification techniques,
– project management techniques,
– testing techniques,
– debugging techniques,
– quality assurance techniques,
– software measurement techniques,
– CASE tools, etc.
42
Software Life Cycle
● Software life cycle (or software
process):
– Series of identifiable stages that a
software product undergoes during its
time:
life time:
● Feasibility study
● Requirements analysis and specification,
● Design,
● Coding,
● Testing
● maintenance. 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.

44
Life Cycle Model (CONT.)

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

45
Why Model Life Cycle ?
● 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.
46
Why Model Life Cycle ?

● Processes are tailored for


special projects.
– A documented process model

● Helps to identify where the


tailoring is to occur.

47
Life Cycle Model (CONT.)

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

48
Life Cycle Model (CONT.)

● When a program is developed by


a single programmer ---
– hehas the freedom to decide his
exact steps.

49
Life Cycle Model (CONT.)

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

50
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
– another defines the I/O for his
portion first.
51
Life Cycle Model (CONT.)

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

52
Life Cycle Model (CONT.)

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

53
Life Cycle Model (CONT.)

● It becomes easier for software


project managers:
– tomonitor the progress of the
project.

54
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 55
members.
Life Cycle Model (CONT.)

● This usually leads to a problem:


– knownas the 99% complete
syndrome.

56
Life Cycle Model (CONT.)

● 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

57
Summary

● Software engineering is:


– Systematiccollection of decades
of programming experience
– Togetherwith the innovations
made by researchers.

58
Summary

● A fundamental necessity while


developing any large software
product:
– Adoption of a life cycle model.

59
Summary
● Adherence to a software life cycle
model:
– Helps to do various development
activities in a systematic and
disciplined manner.
– Also makes it easier to manage a
software development effort.

60
Reference
● Ian Sommerville “Software Engineering,
7th Edition”, Chapter 1.
● Rojer S. Pressman, “ Software
Engineering: A Practitioner’s Approach
6th Edition”, Chapter 1.
● Pankaj Jalot,Introductionto Software
Engg. Chapter 1.
● R. Mall, “Fundamentals of Software
Engineering,” Chapter1.
61

You might also like