This document introduces software engineering and discusses some key concepts. It defines software engineering as a systematic approach to software development, operation, and maintenance. The goal of software engineering is to produce high-quality software products through defined processes. However, software development faces challenges like inability to build programs fast enough to meet demand. The document also discusses common misconceptions around software, such as the belief that more programmers can catch up on a late project. It identifies poorly defined requirements as a major cause of failed software projects. Finally, it notes problems like lack of data collection and customer dissatisfaction that demonstrate the need for a systematic approach like software engineering.

1. CHAPTER 1
INTRODUCTION TO SOFTWARE
ENGINEERING
SOFTWARE SYSTEM
ENGINEERING
(260CT)

2. INTRODUCTION TO SOFTWARE ENGINEERING
Introduction to Software Engineering
(SE)
Software Products
Software Process
Software Misconceptions
What Causes the Needed of SE

3. Introduction to Software Engineering
 IEEE definition of Software Engineering (SE)
• A systematic approach towards development,
operation, maintenance and retirement of software
where, software is defined as related programs,
procedures and documentation.
 Another definition of SE
• The approach towards the systematic development of
large scale software systems using techniques and
tools to increase quality and productivity.

7. Software-related Problems
 Hardware advances continue to outpace ability to
build software
 Ability to build new programs can’t keep pace with
demand
 Society dependent on reliable operation of software
 Struggle to build software that has high reliability &
quality
 Ability to support & enhance existing programs is
threatened by poor design & inadequate resources
 Product delivered late

8. Software Products
 Objective of SE: to produce software products.
 Software products are software systems delivered to
customer with the documentation which describe
how to install and use the system.
 2 classes of software products:
• Generic products. Stand-alone systems which are
produced by a development organization and sold open
market to any customer who is able to buy them.
• Bespoke (customized products). These are systems
which are commissioned by a particular customer. The
software is developed specially for that customer by
some contractor.

9. Software Products
-Software product attributes
 The characteristics displayed by the product once it
is installed and put into use
• Product’s dynamic behaviour
• The use made of the product
• E.g. efficiency, reliability, maintainability, robustness,
portability
• The importance of characteristics varies from system to
system

10. Software Products
-Software product attributes
Process Characteristic Description
Understandability To what extent is the process explicitly defined
& how easy is it to understand the process
definition
Visibility Do the process activities culminate in clear
results so that the progress of the process is
externally visible?
Supportability To what extent can the process activities be
supported by CASE tools?
Acceptability Is the defined process acceptable to and usable
by the engineers responsible for producing the
software product?

11. Software Products
-Software product attributes
Process Characteristic Description
 Reliability Is the process designed in such a way that
process errors are avoided or trapped before
they result in product errors?
 Robustness Can the process continue in spite of
unexpected problems?
 Maintainability Can the process evolve to reflect changing
organizational requirements or identified
process improvements?
 Rapidity How can the process of delivering a system
from a given specification be completed?

12. The Software Process
 The set of activities and associated results which
produce a software product, which are carried by
software engineers.
 CASE (computer-aided software engineering) tools is
used to help some process activities.

13. The Software Process
 4 fundamental process activities common to all
software processes:
• Software specification. The functionality of the software
& constraints on its operation must be defined.
• Software development. The software to meet the
specification must be produced.
• Software validation. The software must be validated to
ensure that it does what the customer wants.
• Software evolution. The software must evolve to meet
changing customer needs.

14. The Software Process
-Process characteristics
Process characteristic Description
Understandability To what extent is the process explicitly defined & how easy is it to
understand the process definition?
Visibility  Do the process activities culminate in clear results so that the progress of
the process is externally visible?
Supportability  To what extent can the process activities be supported by CASE
tools?
Acceptability Is the defined process acceptable to and usable by the engineers
responsible for producing the software product?
Reliability Is the process designed in such a way that process errors are avoided or
trapped before they result in product errors?
Robustness  Can the process continue in spite of unexpected problems?
Maintainability  Can the process evolve to reflect changing organizational
requirements or identified process improvements?
Rapidity  How can the process of delivering a system from a given specification be
completed?

15. The Software Process
 2 basic software development models:
• The waterfall approach.
• Requirement analysis & definition
• goals & constraints are defined
• System & software design
• partitions requirements to either hardware or software
• Implementation & unit testing
• verify that each unit meets its specification
• Integration & system testing
• integrate & test as a complete system
• Operation & maintenance
• system is installed & put into practical use
• Evolutionary development

16. The Software Process

17. The Software Process
 2 types of evolutionary development
• Exploratory programming
• to work with the customer to explore their requirements &
deliver a final system
• Throw-away prototyping
• to understand the customer's requirements & hence
develop a better requirements definition of the system

18. Software Misconceptions
 Management Misconceptions
• There are standards and procedure existed for producing
software.
In reality:
• Standards are rarely used & are often out-of-date and
incomplete.
• Developers rarely know about them.
• State-of-art hardware is the essential ingredient for
successful software production.
In reality:
• Software, not hardware, tools are usually more
important for achieving quality and productivity.

19. Software Misconceptions
 Management Misconceptions
• If we get behind schedule, we can always add more
programmers and thus catch up.
In reality:
• Software development is not a mechanistic
process.
• Adding people to a late software project makes
it later.
• Newcomers must be educated (usually by those
working on the project) thereby reducing the
amount time spent on productive effort.

20. Software Misconceptions
 Customer Misconceptions
• A general statement of objectives is sufficient to begin
writing programs; details can be filled later.
In reality:
• Insufficient knowledge about requirements is
the major cause of failed software efforts.
• Formal & detailed descriptions of data,
functionality, design constraints & and
validation criteria are essential.
• Communication between customer & developer
is vital.

21. Software Misconceptions
 Customer Misconceptions
• Project requirements continually change, but change
easily accommodated because software is flexible.
In reality:
• The impact of change varies with the time at
which it is introduced.
• Early request for change can be accommodated
easily and cheaply.
• Changes made during design, implementation &
installation have a severe impact on cost.

22. Software Misconceptions
 Practitioner’s Misconceptions
• Once the program is written and works, the job is done.
In reality:
• Between 50%-70% of all effort expended on a
program will be expended after it is delivered to
the customer.
• There is no way to access quality until the program is
running.
In reality:
• Formal technical review is one of the most
effective quality assurance tools & can be
applied from the inception of the project.

23. Software Misconceptions
 Practitioner’s Misconceptions
• The only deliverable is the working program(s).
In reality:
• It is only one part of a software configuration
that includes requirements & specification
documents, testing information & other
developmental & maintenance information.

24. What Causes the Need for SE
 Factors contribute to software failure
• Badly design interface
• Creeping featurism
• Unrealistic goals
• Undefined responsibilities
• Missed user requirements
• Misunderstanding

25. What Causes the Need for SE

26. What Causes the Need for SE

27. What Causes the Need for SE

28. What Causes the Need for SE
 Afflicting Problems
• Data has not been collected on the software development process
• thus there can’t be accurate evaluation of the efficiency of
new tools, methods or standards
• Customer dissatisfaction with the completed system is frequently
encountered
• software development is undertaken often with notation of
the customer’s requirements
• Software quality is not suspect
• often there no systematic, complete software testing
• Existing software can be difficult to maintain
• software maintainability has not been emphasized as an
important criteria