Introduction to Software Engineering

1
Software Engineering
Ch Anwar ul Hassan
Department of Computer Science and Software
Engineering
Federal Urdu University of Arts, Sciences & Technology,
Islamabad
anwarchaudary@gmail.com

Today is Introductory Session
Today’s Agenda
 Resource Person
 Participants
 Course
Federal Urdu University of Arts, Sciences & Technology, Islamabad

About Myself

Introduction of Participants
 Name
 Previous qualification & experties
 Courses studies in area of SE & Programming
 Expectations from this course

How to be successful in my class
1. Come to class
2. Strive to learn
3. Be on time for class
4. Pay attention in class. Ask questions.
5. If you don’t understand a topic and/or don’t understand why it’s
relevant, ASK.
6. Be prepared to answer questions in class (Revise Previous
lectures).
7. Play fair
8. DO NOT walk out of class during a class
9. Be respectful
10. As corny as this sounds, try to have some fun in learning this
stuff.

Course Profile
Credit Hours: 03
Evaluation Criteria
Survey Report 05%
Presentation 05%
Assignments/Quiz 10%
Mid term 30%
Final exam 50%

7
Course Contents
 Introduction to Software Engineering
 Software Processes
 Requirements Engineering
 Software Analysis & Design
 Software Project Management
 Software Costing & Estimation
 Software Testing
 Software Quality Assurance

8
Course Objectives
 To learn about all the difficulties in developing
software so that we can avoid pitfalls and
myths in software design
 To learn about different software processes
so that we can choose a suitable one
 To learn to design high-quality efficient
software so that it is usable and maintainable
 To learn about advanced methods for
software engineering

9
Chapter 1
Introduction to Software
Engineering
An overview of software engineering, types
of software, ethics for software engineers,
challenges facing to software engineering,
software crisis, myths, methods, evolution.

10
Contents
 What is Software & its Importance
 Types of Software
 Software Crisis & Software Myths
 What is Software Engineering
 Evolution of Software Engineering
 State-of-art in Software Engineering
Recommended Text Book;
Software Engineering: Seventh Edition (Ian Sommervill)

11
What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...
(“Software Engineering- a practitioner’s
approach,” Pressman, 5ed. McGraw-Hill)

12
What is Software (ctd.)?
Or you may want to say:
 Software consists of
 (1) instructions (computer programs) that when
executed provided desired function and performance,
 (2) data structures that enable the programs to
adequately manipulate information, and
 (3) documents that describe the operation and use of
the programs.

13
What is Software (ctd.)?
But these are only the concrete part of software that
may be seen, there exists also invisible part which is
more important:
 Software is the dynamic behavior of programs on real
computers and auxiliary equipment.
 “… a software product is a model of the real world, and the
real world is constantly changing.”
 Software is a digital form of knowledge. (“Software
Engineering,” 7ed. Sommerville, Addison-Wesley, 2000)

14
The statistics – Chaos Report
Project completion
16%
31%
53%
On time, on budget,
with all of the specified
features and functions
Cancelled before they
were completed
delivered and
operational but over-
budget, over-schedule
or with fewer features
and functions than
specified
 Standish Group – 1995
 365 IT executives in US
companies in diverse industry
segments.
 8,380 projects
average cost
overrun = 189%
average
time
overrun =
222%.
61% of originally specified
features included


?
In Averages
• 189% of original budget
• 221% of original schedule
• 61% of original functionality

15
Symptom of Software Crisis
 About US$250 billions spent per year in the
US on application development
 Out of this, about US$140 billions wasted
due to the projects getting abandoned or
reworked; this in turn because of not
following best practices and standards
Ref: Standish Group, 1996

16
Symptom of Software Crisis
 10% of client/server apps are abandoned or
restarted from scratch
 20% of apps are significantly altered to avoid
disaster
 40% of apps are delivered significantly late
Source: 3 year study of 70 large c/s apps 30 European firms.
Compuware (12/95)

17
 Software products:
 fail to meet user requirements
 crash frequently
 expensive
 difficult to alter, debug, enhance
 often delivered late
Observed Problems

18
Why is the Statistics so Bad?
 Misconception on software development
 Software myths, e.g., the man-month myth
 False assumptions
 Not distinguishing the coding of a computer program
from the development of a software product
 Software programs have exponential growth in
complexity and difficulty level with respect to size.
 The ad hoc approach breaks down when size of
software increases.

19
Why is the Statistics so Bad?
 Software professionals lack engineering
training
 Programmers have skills for programming
but without the engineering mindset about a
process discipline
 Internal complexities
 Essences and accidents made by Fred.
Brooks

20
How is Software usually Constructed …
The requirements
specification was
defined like this
The developers
understood it in
that way
This is how the
problem was
solved before.
This is how the
problem is
solved now
That is the program
after debugging
This is how the program is
described by marketing dept.
This, in fact, is what the
customer wanted … ;-)

21
Software Myths
(Customer Perspectives)
 A general statement of objectives is sufficient to get
started with the development of software.
Missing/vague requirements can easily be
incorporated/detailed out as they get concretized.
 Application requirements can never be stable;
software can be and has to be made flexible enough
to allow changes to be incorporated as they happen.

22
Software Myths
(Developer Perspectives)
Once the software is demonstrated, the job is done.
Usually, the problems just begin!

23
Until the software is coded and is available for testing,
there is no way for assessing its quality.
Usually, there are too many
tiny bugs inserted at every stage
that grow in size and complexity
as they progress thru further stages!
Software Myths

24
The only deliverable for a software
development project is the tested code.
The code is only
the externally visible component
of the entire software complement!
Software Myths

25
Software Myths
(Management Perspectives)
As long as there are good standards and clear procedures in my
company, I shouldn’t be too concerned.
But the proof of the pudding
is in the eating;
not in the Recipe !

26
Software Myths
As long as my software engineers(!) have access to the fastest
and the most sophisticated computer environments and state-
of-the-art software tools, I shouldn’t be too concerned.
The environment is
only one of the several factors
that determine the quality
of the end software product!

27
Software Myths
When my schedule slips, what I have to do is to start a
fire-fighting operation: add more software specialists,
those with higher skills and longer experience - they
will bring the schedule back on the rails!
Unfortunately,
software business does not
entertain schedule compaction
beyond a limit!

28
Misplaced Assumptions
 All requirements can be pre-specified
 Users are experts at specification of their
needs
 Users and developers are both good at
visualization
 The project team is capable of unambiguous
communication
Ref: Larry Vaughn

29
Types of Software
Software has mainly divided into two
Categories:
 System software
Systems software includes the programs that are dedicated to
managing the computer itself, such as the operating system.
 Application software
Application software, or simply applications, are often called
productivity programs or end-user programs because they enable
the user to complete tasks, such as creating documents
 specific to the task it is designed e.g. word processing software

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

31
 Deterioration: To grow worse; to be
impaired in quality e.g. Road Structure
Changes in software development on the later stages,
make the structure worse.
 Wear-out : Get tired through overuse e.g.
Bath Tub Curve
Wear Out vs Deterioration

Wear Out vs Deterioration
32
Software doesn’t Wear-out the hardware begins to Wear-
out with time
Software becomes reliable our time, not a physical identity.
Bath Tub Curve

33
What is Software Engineering?
 Different focuses for this term exist in various
textbooks. Some are listed below.
 The application of a systematic, disciplined,
quantifiable approach to development, operation,
and maintenance of software; that is, the
application of engineering to software. (IEEE
Standard Computer Dictionary, 610.12, ISBN 1-
55937-079-3, 1990)

34
What is Software Engineering? (ctd)
 Software engineering is concerned with the theories,
methods and tools for developing, managing and
evolving software products. (I. Sommerville, 6ed.)
 A discipline whose aim is the production of quality
software, delivered on time, within budget, and
satisfying users' needs. (Stephen R. Schach,
Software Engineering, 2ed.)
 Multi-person construction of multi-version software
(Parnas, 1987)

35
 The practical application of scientific knowledge in
the design and construction of computer programs
and the associated documentation required to
develop, operate and maintain them (B.W. Boehm)
 The establishment and use of sound engineering
principles in order to obtain economically software
that is reliable and works efficiently on real
machines (F.L. Bauer)
What is Software Engineering? (ctd.)

36
 The technological and managerial discipline
concerned with systematic production and
maintenance of software products that are
developed and modified on time and within cost
constraints (R. Fairley)
 A discipline that deals with the building of software
systems which are so large that they are built by a
team or teams of engineers (Ghezzi, Jazayeri,
Mandrioli)
What is Software Engineering? (ctd.)

37
Casting the Term
 The field of software engineering was born in NATO
Conferences, 1968 in response to chronic failures
of large software projects to meet schedule and
budget constraints
 Since then, term became popular because software
is getting more and more important to industry and
business but the “software crisis” still persists.

38
Other Definitions of Software
Engineering
 “A systematic approach to the analysis, design,
implementation and maintenance of software.” (The Free
On-Line Dictionary of Computing)
 “The systematic application of tools and techniques in
the development of computer-based applications.” (Sue
Conger in The New Software Engineering)
 “Software Engineering is about designing and
developing high-quality software.” (Shari Lawrence
Pfleeger in Software Engineering -- The Production of
Quality Software)

39
So, Software Engineering is …
 Scope
 study of software process, development
principles, techniques, and notations
 Goals
 production of quality software,
 delivered on time,
 within budget,
 satisfying customers’ requirements and users’
needs

40
Software Programming ≠ Software
Engineering
 Software programming: the process of translating a problem from
its physical environment into a language that a computer can
understand and obey. (Webster’s New World Dictionary of
Computer Terms)
 Single developer
 “Toy” applications
 Short lifespan
 Single or few stakeholders
 Architect = Developer = Manager = Tester = Customer = User
 One-of-a-kind systems
 Built from scratch
 Minimal maintenance

41
Software Programming ≠ Software
Engineering
 Software engineering
 Teams of developers with multiple roles
 Complex systems
 Indefinite lifespan
 Numerous stakeholders
 Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
 System families
 Reuse to amortize costs
 Maintenance accounts for over 60% of overall development
costs

42
Unique Characteristics of Software
 Software is malleable
 Software construction is human-intensive
 Software is intangible and hard to measure
 Software problems are usually complex
 Software directly depends upon the hardware
 It is at the top of the system engineering “food chain”
 Software doesn’t wear out but will deteriorate
 Software solutions require unusual rigor
 Software has discontinuous operational nature

Engineering vs Manufacturing
43
Engineering is the application of science and math to solve
problems. Engineers figure out how things work and find
practical uses for scientific discoveries.
https://www.livescience.com/47499-what-is-engineering.html

Engineering vs Manufacturing
44
Manufacturing; The making of articles on a large scale
using machinery; industrial production or the Process of
converting raw materials, components, or parts into finished
goods

45
Software Process
 Software Development life cycle
 Waterfall Model
 Prototype Model
 Spiral Model
 Incremental Model

46
Traditional Software Engineering
Software Systems
DataFunction Behavior
Entity-Relation
Diagram
Data Flow
Diagram
State Transition
Diagram

47
Object-Oriented Software Engineering
Software Systems
FunctionObject Behavior
Data Flow
Diagram
Class
Diagram
State Chart

48
Evolution of Software Industry
 Independent Programming Service
 Software Product
 Enterprise Solution
 Packaged Software for the Mass
 Internet Software and Services

49
Independent Programming Services
(Era 1)
 Feb 1955, Elmer Kubie and John Sheldon
founded CUC
 the First Software Company that devoted to the
construction of software especially for hardware
company.
 Promoting Software Industry: two Major
Projects,
 SABRE, airline reservation system, $30 million.
 SAGE, air defense system (1949~1962)
700/1000 programmers in the US. $8 billion.

50
Software Product (Era 2)
 1964 Martin Goetz developed Flowchart
Software -- Autoflow for RCA, but rejected.
 Sale to the customer of RCA & IBM.
 Develop and market software products not specifically
designed for a particular hardware platform.
 MARK IV, a pre-runner for the database
management system.
 IBM unbundled software from hardware.

51
Enterprise Solutions (Era 3)
 Dietmar Hopp. IBM Germany
 Systems, Applications and Products (SAP)
$3.3billion (1997)
 Setting up shop in Walldorf, Germany.
 Marked by the emergence of enterprise solutions
providers.
e.g. Baan 1978. Netherlands. $680 million (1997)
Oracle 1977. U.S.
Larry Ellison.
 ERP, $45 billion (1997)

52
Packaged Software for the Masses
(Era 4)
 Software products for the masses. 1979.
 VisiCalc, Spreadsheet program.
 August 1981: The deal of the century.
 Bill Gates bought the first version of the OS from a small
firm called Seattle Computer Products for $50,000 without
telling them it was for IBM.
 The development of the IBM PC, 1981, initiated a 4th
software era.
 PC-based mass-market software. Few additional services are
required for installation.
 Microsoft reached revenues of $11.6 billion. Packaged
Software Products, $57 billion (1997)

53
Internet Software and Services (Era 5)
 Internet and value-added services period,
1994. W
 with Netscape’s browser software for the internet.

54
Object-Oriented
Ad hoc
Data flow-based
Data structure-
based
Control flow-
based
Evolution of Design Techniques

55
Related Knowledge
Maths
Application
domain
knowledge
Advanced
SE
Knowledge
Guide to the
SWEBOK
Ironman
C.S.
...
Knowledge of
a Software
Engineer
Specialized
SE
Knowledge

56
IT Market
Hardware
products
Hardware
maintenance
Software Products
& Services
Processing Services
and Internet Services
Embedded
Software
Professional
Service
Software
Products
Enterprise
Solution
Packaged
Mass-Market
Software

57
Software Products and Services
Enterprise
Solutions
IBM
Oracle
Computer Associates
SAP
HP
Fujitsu
Hitachi
Parametric Technology
People Soft
Siemens
Packaged Mars-Market
Software
Microsoft
IBM
Computer Associates
Adobe
Novell
Symantec
Intuit
Autodesk
Apple
The Learning Company
Professional Software
Services
Anderson Consulting
IBM
EDS
CSC
Science Applications
Cap Gemini
Hp
DEC
Fujitsu
BSO Origin

58
Software Engineering Today?
 Organizations “go with what has worked in
the past”
 Everyone is too busy getting product out the
door to spend time in education or training or
addressing these problems effectively
 “Out of date” practices become
institutionalized

59
Software Engineering Today?
 Few people know, or can integrate, best
practices
 Unable to adopt and utilize proven
methodologies in timely fashion
 Although significant improvements have been
made in specific areas, the rapidly evolving
nature of the software industry has resulted in
little overall improvement in the overall
situation.

60
Not Crisis, but a Chronic Problem
 The crisis persists
 After 35 years later, the software “crisis” is still with
us
 Major problems are still the same:
 poor quality (correctness, usability, maintainability, etc)
 over budget
 delivered late, or not at all
 It is not a crisis but a chronic problem
 It becomes a persistent, chronic condition that
software industry has to face with

61
What’s Wrong?
 Does software engineering have no progress at all?
Not quite true.
 We have indeed seen a lot of improvements, e.g. high level
programming, object-oriented technology, etc.
 But it does not achieve its promise, why?
 production of fault-free software, delivered on time
and within budget, that satisfies the users’ needs,
and is easy to maintain, etc.

62
A More Close Look
 The comparison with 1995’s report does show that there is some
progress in the past eight years.

63
So, What’s the Problem?
 Software issues: software industry has
changes a lot in the past years
 Education issue: more emphasis on methods
and tools but lack of sufficient education and
training on people
 Process and quality issue: there lacks of a
set of known proven practices for software
engineers to follow with

64
Software Changes in the Past Years
 Changes in software over time:
 grew in size from 10’s or 100’s of lines to 1000’s
to 1,000,000’s of lines of code
 operating environment changed from simple
“batch” operations to complex multiprogramming
systems, to time-sharing and distributed
computing to today’s Internet network computing
environment.

65
Software Changes in the Past Years
 As computer systems (both hardware and
software) have become larger and more
complex, the software development process
has also become more and more complex
 the simple art of “programming in the small” is no
longer capable of coping with the task.

66
Situations for Software are Different Too
 Driven by intense market forces, including
persistent pressure to deliver software on
unrealistic time schedules
 Rapidly changing requirements
 Pressures for faster time to market
 Continuing rapid evolution of software
methodologies and systems
 Integration of new processes and techniques
 Need to re-design major systems

67
Situations for Software are Different Too
 Talent shortage: needed software engineering
skills often in short supply
 What even worse
 Moore’s law means always trying new things
 Complexity moves into software
 Can’t find the limits except by trial and error

68
The Software Industry Today
 Even though much is now known about how
to improve software production, the overall
state is not much better than ever, due to the
urgency of meeting unrealistic delivery
schedules and the continuing rapid evolution
of the software industry
 i.e. poor quality, late delivery, over budget

69
The Software Industry Today
 Component-Based Engineering and Integration
 Technological Heterogeneity
 Enterprise Heterogeneity
 Greater potential for Dynamic Evolution
 Internet-Scale Deployment
 Many competing standards
 Much conflicting terminology

70
 Ability to collaborate; be able to communicate
clearly and concisely both to laypeople and peers.
 Able to follow instructions, make a team stronger
for your presence and not weaker.
 Ability to see the bigger picture and differing
perspectives; to compromise, to balance
competing priorities, and to priorities the user
Ethics for Software Engineers

71
 You write clean, reusable code that’s easier to read and
test
 You understand how your code helps drive the overall
business
 You listen more than you speak—or you at least listen
before you speak.
 You are disciplined (not sacrifice quality, focused time
for development work)
 You get help from strangers on the internet.
 You go beyond skill to achieve expertise, You are open
to new things
Ethics for Software Engineers

72
Three key Challenges
Software engineering in the 21st century
faces three key challenges:
 Legacy systems
 Old, valuable systems must be maintained and updated
 Heterogeneity
 Systems are distributed and include a mix of hardware and
software
 Delivery
 There is increasing pressure for faster delivery of software

Introduction to Software Engineering

Recommended

More Related Content

What's hot (20)

Similar to Introduction to Software Engineering (20)

More from AnwarrChaudary (20)

Recently uploaded (20)

Introduction to Software Engineering