1. Introduction Text Books:
1. “Software Engineering” by Ian Sommerville, (6th edition)
2. “Software Engineering: A Practitioner’s Approach” by Roger S. Pressman

2. Chapter: 1 (Introduction- Software Product) What Is Software?
Computer programs and associated documentation
It encompasses:
Instructions “Computer Programs”
Documents “Describe Programs”
What is software engineering?
Software engineering is an engineering discipline that is concerned with all aspects of software production.
Designing, building and maintaining large software systems in a cost-effective way.

3. What is software engineering methods?
Structured approaches to software development which include system models, notations, rules, design advice and process guidance.
Model descriptions
Descriptions of graphical models which should be produced;
Rules
Constraints applied to system models;
Recommendations
Advice on good design practice;
Process guidance
What activities to follow.

4. What is Software Engineering?
Software engineering concerns methods and techniques to develop large software systems.
The engineering metaphor is used to emphasize a systematic approach to developing systems that satisfy organizational requirements and constraints.
First Definition of Software Engineering
Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. 4

5. Alternate Definition of Software Engineering
Software Engineering is a discipline that aims to create fault-free software on time, within budget, to meet the needs of the customer.
The software should be easy to maintain. 5

6. Definition (IEEE)
1) Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software
2) The study of approaches as in 1) 6
© SE, Introduction, Hans van Vliet 6

7. Objectives of Software Engineering
To improve quality of software products
To increase customer satisfaction
To increase productivity
To increase job satisfaction
Software engineering is not programming. Programming is an important part of software engineering.
“This is not a programming course”

8. Essential Characteristics of Software Engineering
Software engineering concerns the development of large programs
The central theme is mastering complexity
Software evolves as opposed to wearing out
The efficiency with which software is developed is of crucial importance
Regular cooperation between people is an integral part of programming-in-the-large
The software has to support its users effectively.
Software engineering is a field in which members of one culture create artifacts on behalf of members of another culture.
Software engineering is a balancing act.

9. What is the difference between software engineering and computer science?
Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.
What is the difference between software engineering and system engineering?
System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system.

10. Types of software product
Software products may be developed for a particular customer or may be developed for a general market
Software products may be
Generic - developed to be sold to a range of different customers
Bespoke (custom) - developed for a single customer according to their specification

11. What are the attributes of good software?
The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable.
Maintainability
Software must evolve to meet changing needs;
Dependability
Software must be trustworthy;
Efficiency
Software should not make wasteful use of system resources;
Acceptability
Software must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems.

12. Software Characteristics (Pressman book)
software is engineered not manufactured
software doesn’t wear out
Figure 1.1 vs Fig 1.2
software is complex
Software is custom built,
rather than being assembled
from existing components.
Hardware wears out over time

13. Hardware vs. Software Hardware Software Manufactured Wears out
Built using components
Relatively simple
Developed/engineered
Deteriorates
Custom built
Complex

14. Software Applications
system software
application software
engineering/scientific software
web applications
AI software
Description: book pressman

15. What is a software process?
A set of activities whose goal is the development or evolution of software.
Generic activities in all software processes are:
Specification - what the system should do and its development constraints
Development - production of the software system
Validation - checking that the software is what the customer wants
Evolution - changing the software in response to changing demands.

16. What is a software process model?
A simplified representation of a software process, presented from a specific perspective.
Examples process models
Waterfall;
Iterative development;
Component-based software engineering.

17. Simple life cycle model
problem
requirements analysis
reqs specification
design
design
implementation
system
testing
working system
maintenance 17

18. Waterfall Life Cycle Model
Figure 2.8

19. Requirements Phase yields a description of the desired system:
which functions
possible extensions
required documentation (artifacts)
performance requirements
requirements are elicited from stakeholders (elicitation techniques include interviews, questionnaires, etc.)
resulting document: Requirements Definition (customer oriented)
document describes what to do not how
- the requirements document often has a legal status too.
- different stakeholders want different documents (the designer/impementer wants a precise, formal document, while the user is best served by a document in her natural language)
- it is important the the requirements document is very precise; no TBD’s (To Be Determined). If you do not know what is being asked, chances are you will not come up with the right answer. 19
© SE, Introduction, Hans van Vliet

20. Analysis Phase also called the Specification Phase
resulting artifact is the Software Requirements Specification (SRS)
document is developer-oriented
in the object-oriented paradigm, developers perform two steps during this phase
They determine what should the product do
They extract the classes for the system
together the Requirements and Analysis Phases comprise the Requirements Analysis Phase

21. Design Phase The Design Phase has two sub-phases:
Architectural Design
Detailed Design
During Architectural Design, the modules are decided upon
There is a decomposition into parts/components; what are the functions of, and interfaces between, those components?
The emphasis in Architectural Design is what rather than how. There may be a Design Specification Document.
During the Detailed Design Phase, the data structures and algorithms are determined.
The algorithms may be written in pseudocode.
“my” law: The sooner you start coding, the longer it takes 21
© SE, Introduction, Hans van Vliet

22. Implementation The algorithms are translated to code
goal: a working, flexible, robust, … piece of software
Pareto’s law generally holds here as well; so most local work on efficiency is a waste of time. It makes the software more complex, less portable, less reusable, and more error-prone.
At this stage too, documentation and communication is very important. Undocumented decisions fire back. 22
© SE, Introduction, Hans van Vliet

23. Testing does the software do what it is supposed to do?
are we building the right system?
(validation)
Customer-oriented
are we building the system right (correctly)?
(verification)
Developer-oriented
An artifact such as the design is correct with respect to the SRS
Traceability is a concern – Forward and backward traceability
Testing should not start after the implementation phase.
Cleanroom development: developers are allowed to read the programs they’ve written, they are not allowed to execute them. Testing in Cleanroom is done by others.
Question to students: do you dare to give a warranty on the software you wrote? 23
© SE, Introduction, Hans van Vliet

24. Post-Delivery Maintenance
correcting errors found after the software has been delivered
adapting the software to changing requirements, changing environments, ...
- IBM OS 360: 1000 errors per release, and this number did not really go down over time
- quick and dirty bug fixes increase the system’s entropy
- maintenance is usually done under pressure 24
© SE, Introduction, Hans van Vliet

25. Development distribution of effort
design 15%
coding 20%
requirements
10%
specification 10%
testing 45% 25

26. Development distribution of effort
rule of thumb: distribution of effort. Only about 20% of effort is spent on coding
trend: enlarge requirements specification/design slots; reduce test slot
beware: maintenance alone consumes 50-75% of total effort. 26
© SE, Introduction, Hans van Vliet 26

27. Kinds of maintenance activities
corrective maintenance: fixing errors
Example: a logic error is causing incorrect output
adaptive maintenance: changes due to the environment (both hardware and software)
perfective maintenance: changes to the system based on changing user requirements
Example: The user requests additional functionality or wants a more efficient system.
- adaptive maintenance does not change the functionality of the system
- people often have trouble distinguishing between adaptive and perfective maintenance
- since most present-day development does not start from scratch, part of maintenance resembles development: both concern the evolution of a system; see also exercise 10 of chapter 14. 27
© SE, Introduction, Hans van Vliet 27

28. Distribution of maintenance activities
corrective 21%
perfective 50%
adaptive 25%
preventive 4%
©2008 John Wiley & Sons Ltd.
vliet 28

29. What are the key challenges facing software engineering?
Coping with legacy systems, coping with increasing diversity and coping with demands for reduced delivery times
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

30. What is CASE (Computer-Aided Software Engineering)
Software systems that are intended to provide automated support for software process activities.
CASE systems are often used for method support.
Upper-CASE
Tools to support the early process activities of requirements and design;
Lower-CASE
Tools to support later activities such as programming, debugging and testing.
CASE details at chapter:2

31. What are the costs of software engineering?
Roughly 60% of costs are development costs, 40% 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.
Fig book

32. Professional and ethical responsibility
Software engineering involves wider responsibilities than simply the application of technical skills.
Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals.
Ethical behaviour is more than simply upholding the law.

33. Issues of professional responsibility
Confidentiality
Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.
Competence
Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence.
Intellectual property rights
Engineers should be aware of local laws governing the use of intellectual property such as copyright. They should be careful to ensure that the intellectual property of employers and clients is protected.
Computer misuse
Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).

34. Legacy Software Legacy systems Why must it change?
Old, valuable systems must be maintained and updated
Why must it change?
It must be fixed to eliminate errors.
It must be enhanced to implement new functional and non-functional requirements
Software must be adapted to meet the needs of new computing environments or technology.
Software must be enhanced to implement new business requirements.
Software must be extended to make it interoperable with other more modern systems or databases.
Software must be re-architected to make it viable within a network environment.

35. Software crisis