In projects involving many participants, often of different technical and cultural backgrounds, accuracy and clarity as the cost of miscommunication increases rapidly. For a notation to enable accurate communication, it must come with a well-defined semantics, it must be well suited for representing a given aspect of a system and it must be well understood among project participants.

1. LECTURE 1
INTRODUCTION TO
SOFTWARE ENGINEERING
P R E PA R E D B Y : E N G R . WA FA Q A I S E R K H A N

2. MARKS DISTRIBUTION
•4 QUIZ EACH OF 2.5 MARKS
•2 ASSIGNMENTS EACH OF 5 MARKS
•1 PROJECT OF 10 MARKS

3. • “ The amateur software engineer is always in search of
magic, some sensational method or tool whose application
promises to render software development trivial. It is the
mark of professional software engineer to know that no
such panacea exists.” –GRADY BOOCH in Object
Oriented Analysis and Design

4. BACKGROUND
• The term software engineering was coined by a computer scientist
Anthony Oettinger.
• The term was then used in 1968 as a title for the world’s first
conference on software engineering sponsored and facilitated by
NATO.
• Conference was attended by international experts on Software who
agreed on defining best practices for software grounded in the
application of engineering.
• The widespread lack of best practices for software at the time was
perceived as a software crisis.

5. BACKGROUND

6. BACKGROUND
• The discipline of software engineering was created to address poor
quality of software, get projects exceeding time and budget under
control, and ensure that software is built systematically, rigorously,
measurably, on time, on budget, and within specification.
• THE MOON WAS PROMISED, A LUNAR ROVER BUILT, AND A PAIR OF
SQUARE WHEELS DELIVERED.

7. INTRODUCTION TO SOFTWARE
ENGINEERING FAILURES

8. INTRODUCTION TO SOFTWARE
ENGINEERING FAILURES
YEAR 1900 BUG
– Last two digits of person’s birth year was registered on the assumption
that either it was not important exactly how old a person is, or that no
one lives longer than 100 years.
– In 1992, Mary from Winona, Minnesota, received an invitation to attend a
kindergarten. Mary was 104 at the time.
BIRTH-1888
WAS---1988
CONSIDERED: 0YEAR OLD
100YEARS
1992: 4YEARS OLD

9. • Many systems are so hard to understand, even during their development
phase, that they are never finished: these are called vaporware.
• Software development projects are subject to constant change.
• Because requirements are complex they need to be updated when
errors are discovered.
• If the project lasts many years, the staff turn-around is high, requiring
constant training.

10. WHAT IS SOFTWARE ENGINEERING
• Software engineering is a modeling activity.
• Software engineers deal with complexity through modeling, by focusing at any one time
on only the relevant details and ignoring everything else.
• A model is an abstract representation of a system that enables us to answer questions
about the system.
• Models are useful when dealing with systems that are too large, too small, too
complicated, or too expensive to experience firsthand.
• Models also allow us to visualize and understand systems that either no longer exists or
that are only claimed to exist.

11. WHAT IS SOFTWARE ENGINEERING
• Software engineering is a problem-solving activity. Given the lack of fundamental theory, they
often have to rely on empirical methods to evaluate the benefits of different alternatives.
• Software engineering is an engineering activity. It is not algorithmic.
• It requires experimentation, the reuse of pattern solutions, and the incremental evolution of
the system toward a solution that is acceptable to the client.
• It includes six steps:
1. Requirements elicitation
2. Analysis
3. System design
4. Object design
5. Implementation
6. Testing

12. WHAT IS SOFTWARE ENGINEERING
• Software Engineers six steps: Engineers 5 steps approach:
1. Requirements elicitation 1. Formulate the problem
2. Analysis 2. Analyze the problem
3. System design 3. Search the solutions
4. Object design 4. Decide on the appropriate solution
5. Implementation 5. Specify the solution
6. Testing

13. WHAT IS SOFTWARE ENGINEERING
• Requirements elicitations and analysis corresponds to step 1 and 2 of
the engineering method.
• During system design, software engineers analyze the problem and
break it down into smaller pieces, and select general strategies for
designing the system.
• During object design, they select detail solutions for each piece and
decide on the most appropriate solution.
• System design and object design result in the solution domain model
and correspond to steps 3 and 4 of the engineering method.

14. WHAT IS SOFTWARE ENGINEERING
• During implementation, software engineers realize the system by
translating the solution domain model into an executable
representation.
• Implementation corresponds to step 5 of the engineering method.
• During testing developers find differences between the system and its
models by executing the system ( or parts of it) with sample input data
sets.

15. WHAT IS SOFTWARE ENGINEERING
• Software engineering is a knowledge acquisition activity.
• In modeling the application and solution domain, software engineers
collect data, organize it into information, and formalize it into
knowledge.
• Knowledge acquisition is not sequential, as a single piece of additional
data can invalidate complete models.
• Software engineering is a rationale-driven activity.
• Enables software engineers to understand the implication of a
proposed change when revisiting a decision.

16. SOFTWARE ENGINEERING CONCEPTS
• A PROJECT whose purpose to develop a software system, is composed of a number of
ACTIVITIES.
• Each ACTIVITY is in turn composed of number of TASKS.
• A TASK consumes RESOURCES and produces a WORKPRODUCT.
• A WORKPRODUCT can be either a SYSTEM, a MODEL, or a DOCUMENT.
• RESOURCES are either PARTICIPANTS, TIME, or EQUIPMENT.

17. SOFTWARE ENGINEERING CONCEPTS

18. SOFTWARE ENGINEERING PROJECT

19. SOFTWARE ENGINEERING PROJECT
PARTICIPANTS AND ROLES

20. SOFTWARE ENGINEERING PROJECT
PARTICIPANTS AND ROLES

21. SOFTWARE ENGINEERING PROJECT
SYSTEM AND MODELS
• SYSTEM is a collection of interconnected parts.
• We use the term Model to refer to any abstraction of the system.
• ATicketDistributor for an underground train is a system.
• Blueprints for the TicketDistributor, schematics of its electric
wiring, and object models of its software are models of the
TicketDistributor.

22. SOFTWARE ENGINEERING PROJECT
WORKPRODUCTS
• A workproduct is produced during the development, such as a
document or a piece of software for other developers or for the
client.
• WorkProduct for the project’s internal consumption is referred as
internal work product.
• WorkProduct that must be delivered to a client is referred to as a
deliverable.

23. SOFTWARE ENGINEERING PROJECT
WORKPRODUCTS

24. SOFTWARE ENGINEERING PROJECT
WORKPRODUCTS

25. SOFTWARE ENGINEERING PROJECT
ACTIVITIES, TASKS AND RESOURCES
• An ACTIVITY is a set of tasks that is performed toward a specific purpose.
• For example, requirements elicitation is an activity whose purpose is to define with the client what the
system will do.
• Activities are also sometimes called phases.
• TASK a piece of work to be done.
• A manager assigns it to a developer, the developer carries it out, and the manager monitors the progress
and completion of the task.Task consume resources, result in work products.
• RESOURCES are assets that are used to accomplish work.
• Resources include time, equipment, and labor.
• When planning a project, a manager breaks down the work into tasks and assigns them to resources.

26. SOFTWARE ENGINEERING PROJECT
ACTIVITIES, TASKS AND RESOURCES

27. SOFTWARE ENGINEERING PROJECT
ACTIVITIES, TASKS AND RESOURCES

28. SOFTWARE ENGINEERING PROJECT
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTS
• Requirements specify a set of features that the system must have.
• A functional requirement is a specification of a function that the system must support.
• A non-functional requirement is a constraint on the operation of the system that is not
related directly to a function of the system.

29. SOFTWARE ENGINEERING PROJECT
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTS