0% found this document useful (0 votes)
12 views33 pages

Lecture-1

Uploaded by

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

Lecture-1

Uploaded by

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

Software Engineering

Lecture: 1

Ms. Shazia Yousaf


Lecturer,
Department of Software Engineering,
National University of Modern Languages
Contents
Class and course policies
Introduction to Software Engineering

2
Policies
Must write your name, roll number and
section in a test
You can submit the assignments till the end
of class on due date
20% marks deduction per week day for late
submission of work
Ask questions; participate actively in class
You are allowed to talk to instructor only

3
Policies

You are responsible for what is covered in


class
Deficiency in attendance may lead to
termination
You are encouraged to help each other with
your homework assignments – but you must
turn in your own work
If you are found to be cheating, you will fail
at least the assignment / test and perhaps
the entire class

4
Policies
If you have any learning disabilities or
special needs, please let me know in
advance through email or personal
meeting
Check your email regularly for messages
Quizzes are unannounced except the
grand one
No re-take of quizzes.

5
Policies
No plagiarism will be allowed, if full or
part of assignment or quiz is copied, the
student will be given 0 marks.
75% attendance policy will hold (no
arguments later on)
A student 10 minutes late in class will be
considered absent.

6
Contacts

 Student Hours:
Tuesday 09:00 – 11:00 PM
 Email:
[email protected]

7
What is a Software?
It is general term for various kinds of
programs used to operate computers and
related devices.
Two types
◦ Application software
◦ System software

8
Engineering
 Derived from old French engin = skill, which stems from
Latin ingenium = ability to invent, brilliance, genius

 The word was created in the 16th century and


originally described a profession that we would
probably call an artistic inventor ("Encyclopedia" by The Software
Toolworks, 1991)

 Engineering is the application of science for practical


purposes.

9
Engineering
 The profession of or work performed by an engineer.

 Engineering involves the knowledge of the


mathematical and natural sciences (biological and
physical) gained by study, experience, and practice that
are applied with judgment and creativity to develop
ways to utilize the materials and forces of nature for
the benefit of mankind

10
What is Software Engineering?
 Software Engineering is an engineering discipline which
concerns with the development of software by applying
Engineering Principles

 Goal is the cost-effective development of software


systems

11
Software Engineering?
Software Engineering [IEEE]:

 The application of a systematic, disciplined, quantifiable


approach to the development, operation, and
maintenance of software; that is, the application of
engineering to software.

12
Software Engineering
 In 1968 a Conference was held in Germany.

◦ Purpose: to look for a solution to software crisis

◦ 50 top computer scientists, programmers and industry leaders


got together to look for a solution to the difficulties in building
large software systems (i.e., software crisis)

◦ The term “software engineering” was first used in that


conference to indicate a systematic, disciplined, quantifiable
approach to the production and maintenance of software
 Three-decades later (1994) an article in Scientific American (Sept.
94, pp. 85-96) by W. Wayt Gibbs was titled:

◦ “Software’s Chronic Crisis’’


Software’s Chronic Crisis
Large software systems often:
 Do not provide the desired functionality
 Take too long to build
 Cost too much to build
 Require too much resources (time, space) to run
 Cannot evolve to meet changing needs

◦ For every 6 large software projects that become


operational, 2 of them are canceled
◦ On the average software development projects
overshoot their schedule by half
◦ 3 quarters of the large systems do not provide
required functionality
Software Failures
There is a long list of failed software
projects and software failures

You can find a list of famous software


bugs at:
http://www5.in.tum.de/~huckle/bugse.html
Software’s Chronic Crisis
These are not isolated incidents:
◦ IBM survey of 24 companies developing
distributed systems:
 55% of the projects cost more than expected
 68% overran their schedules
 88% had to be substantially redesigned
Software’s Chronic Crisis
Software product size is increasing exponentially
Software is everywhere: from TV sets to cell-
phones
Software is in safety-critical systems
◦ cars, airplanes, nuclear-power plants
We are seeing more of
◦ distributed systems
◦ embedded systems
◦ real-time systems
 These kinds of systems are harder to build
Software requirements change
◦ software evolves rather than being built
Software’s Chronic Crisis
Software has the following properties in
its essence:
◦ Complexity
◦ Conformity
◦ Changeability
◦ Invisibility
Software’s Chronic Crisis
Software’s chronic crisis: Development of
large software systems is a challenging
task

Software engineering focuses on


addressing challenges that arise in
development of large software systems
using a systematic, disciplined,
quantifiable approach
No Silver Bullet
In 1987, in an article titled:
“No Silver Bullet: Essence and Accidents
of Software Engineering”
Frederick P. Brooks made the argument
that there is no silver bullet that can kill
the werewolf software projects

Following Brooks, let’s philosophize


about software a little bit
Essence vs. Accident
 Essence vs. accident in software development
◦ We can get rid of accidental difficulties in developing
software
◦ Getting rid of these accidental difficulties will increase
productivity

 For example using a high level programming


language instead of assembly language
programming
◦ The difficulty we remove by replacing assembly
language with a high-level programming language is
not an essential difficulty of software development,
Essence vs. Accident
 Essence vs. accident in software development
◦ Brooks argues that software development is
inherently difficult
 “The essence of a software entity is a construct of interlocking
concepts: data sets, relationships among data items,
algorithms and invocations of functions. This essence is
abstract in that such a conceptual construct is the same
under many different representations. ... The hard part of
building software is the specification, design, and testing of
this conceptual construct, not the labor of representing it and
testing the fidelity of the representation.”
 Even if we remove all accidental difficulties which arise during
the translation of this conceptual construct (design) to a
representation (implementation), still at its essence software
development is difficult
Inherent Difficulties in Software
 Software has the following properties in its
essence:
◦ Complexity
◦ Conformity
◦ Changeability
◦ Invisibility

 The moral of the story:


◦ Do not raise your hopes up for a silver bullet, there
may never be a single innovation that can transform
software development as electronics, transistors,
integrated-circuits and VLSI transformed computer
hardware
Complexity
Software systems do not have regular
structures, there are no identical parts

Identical computations or data structures


are not repeated in software

In contrast, there is a lot of regularity in


hardware
◦ for example, a memory chip repeats the same
basic structure millions of times
Complexity
 Consider a plane that is going into a wind-tunnel for
aerodynamics tests
◦ During that test it does not matter what is the fabric used
for the seats of the plane, it does not even matter if the
plane has seats at all!
◦ Only thing that matters is the outside shape of the plane
◦ This is a great abstraction provided by the physical laws
and it helps mechanical engineers a great deal when they
are designing planes
 Such abstractions are available in any engineering
discipline that deals with real world entities
 Unfortunately, software engineers do not have the
luxury of using such abstractions which follow from
physical laws
◦ Software engineers have to develop the abstractions
themselves (without any help from the physical laws)
Conformity
Software has to conform to its environment
◦ Software conforms to hardware interfaces not
the other way around

Most of the time software systems have to


interface with an existing system

Even for a new system, the perception is


that, it is easier to make software interfaces
conform to other parts of the system
Changeability
Software is easy to change, unlike hardware

Once an Intel processor goes to the


production line, the cost of replacing it is
enormous (Pentium bug cost half billion
dollars)

If a Microsoft product has a bug, the cost of


replacing it is negligible.
◦ Just put the new download on a webpage and
ask users to update their software
Changeability is not an Advantage
Although it sounds like, finally, software
has an advantage over hardware, the
effect of changeability is that there is
more pressure on changing the software

Since software is easy to change,


software gets changed frequently and
deviates from the initial design
◦ adding new features
◦ supporting new hardware
Changeability
Conformity and Changeability are two of
the reasons why reusability is not very
successful in software systems

Conformity and Changeability make it


difficult to develop component based
software, components keep changing
Invisibility
Software is invisible and un-visualizable
Complete views can be incomprehensible
Partial views can be misleading

Arithmetic abstractions are very useful in


other engineering disciplines
◦ Floor plan of a building helps both the architect
and the client to understand and evaluate a
building
Software does not exist in physical space
and, hence, does not have an inherent
numerical representation
Invisibility
 Visualization tools for computer aided design are very
helpful to computer engineers
◦ Software tools that show the layout of the circuit (which
has a two-dimensional geometric shape) makes it much
easier to design a chip

 Visualization tools for software are not as successful


◦ There is nothing physical to visualize, it is hard to see an
abstract concept
◦ There is no physical distance among software components
that can be used in mapping software to a visual
representation
◦ UML and similar languages are making progress in this
area
Summary
According to Brooks, there are essential
difficulties in software development which
prevents significant improvements in
software engineering:
◦ Complexity; Conformity; Changeability; Invisibility

He argues that an order of magnitude


improvement in software productivity
cannot be achieved using a single technology
due to these essential difficulties
Questions ?

Thank You

The illiterate of the 21st century will not be those who cannot read and write,
but those who cannot learn, unlearn, and relearn.
--Unknown

You might also like