1

Introduction to Software Engineering

Lecture 1

2

References

• Chapter 1: Introduction to Software Engineering from Object Oriented Software Engineering: Conquering Complex and Changing Systems

3

Why Engineer Software ?

• Software are complex entities.– Several modules interact to achieve diverse

objectives.– Several participants involved in the development

process.– Validation and verification of software can be

complex and arduous.• Verification focuses on showing that the system and

models comply with the specifications.• Validation ensures that the system addresses client’s

needs.

4

Why Engineer Software ? (Contd…)

• Software are complex entities.– Software development process changes

continuously.– Complex and imprecisely defined requirements may

be understood and interpreted differently throughout the project.

– Technology changes frequently.– Correct execution of software is dependent on the

execution environment.

• Adhering to cost and time schedules of a software project has been extremely challenging.

5

Why Engineer Software ? (Contd…)

• Engineering of high quality software requires gluing together the right off the shelf software components.

• Correct Specification of off the shelf software components is essential for seamless integration and optimum performance of the resulting system.

6

What is Software Engineering

• A modeling activity– Dealing with complexity through models.– Focusing on relevant details at appropriate levels.– Several different models used to represent artifacts

in the problem and solution domains.

• A problem solving activity– Models provide alternate solutions to the problem

being investigated.– Constraints force software engineers to shortlist

solution using empirical techniques.

7

What is Software Engineering (Contd.)

• A knowledge acquisition activity– Modeling helps data collection its organisation into

information and its formulation into knowledge.– A non-linear process, i.e., several models

invalidated by a single finding.

• A rationale driven activity– Software engineering requires recording of context

and rationale of choice of solutions.– Rationale information is represented as a set of

models enabling software engineers to understand the implications of a proposed change.

8

Models for Software Systems

• A model is an abstract representation of a system enabling the participants of an activity to answer questions about the system.

• Models are useful in dealing with systems that are too large, too small, too complicated or too expensive.

• During analysis, software engineers build models of the problem domain.

• During design, software engineers build models of the solution domain.

9

Engg Development Vs. Software Engg

Engineering Development

Software Engineering

Problem Formulation Requirements Elicitation

Problem Analysis System Analysis

Solution Search System Design

Decision on Appropriate Solution

Detailed Design

Solution Specification Implementation

Review

s

10

Challenges in Engineering Software

• Assumptions change frequently.

• Solution domain remains in a constant state of flux.– Bugs– Faults– Misinterpreted requirements– Enhancements

• Changes force the formulation of new functional and non-functional requirements.

11

Challenges in Engineering Software (Contd.)

• Capturing and assessing rationale is non-trivial– One decision may be based on several

alternatives.– Rationale information is not explicit.– Developers commonly use intuition and

experience for guidance.

12

Terminologies

• Model– An abstraction of a real system.

• Activity– A set of tasks performed towards a specific

purpose.

• Task– An atomic unit of work that can be managed.– Tasks consume resources, generate work products

and depend upon work products produced by other tasks.

13

Terminologies (Contd.)

• Resources– Assets used to accomplish work.– In a typical development project, a manager breaks

down work into tasks and assigns resources for their completion.

• Work Product– An artifact produced during development.– Work products can be produced for other

developers or for clients.

• Internal Work Product– Work product developed for internal consumption.

14

Terminologies (Contd.)

• Deliverables– Work products developed for a client.– Defined prior to the start of the project and specified

by a contract binding developers to the clients.

• Goals– High level principles used to guide a project.– Goals specify important attributes of the system.

• Requirements– Features that a system must possess.

• Functional Requirements– An area of functionality that a system must support.

15

Terminologies (Contd.)

• Non-functional Requirements– Constraints on the operation of the system.

• Notation– A graphical or textual set of rules for representing a

model.

• Method– A repeatable technique for solving a specific

problem.

• Methodology– A collection of methods for solving a class of

problems.

16

Software Development Activities

• Requirements Elicitation

• Analysis

• Design

• Implementation

• Test

• Production and Maintenance

17

Requirements Elicitation• Objective is to provide a statement expressed

in business terms defining and describing the problem domain.

• Involves the process of modeling a business process to describe its future business structure and functions.

• Static descriptions can be enhanced by dynamic simulations.

• Information presented during the requirements phase is expanded to provide a complete definition of the problem domain.

18

Requirements Elicitation (Contd.)

• Outputs of the requirements phase include – Functional and process decomposition description, – Logical data models,– Usage and responsibility matrices,– Property descriptions.

• Decomposition of process information describes the business process steps or stages.

• Logical data models define the data requirements of the problem domain.

19

Requirements Elicitation (Contd.)

• Normalisation of data models groups related facts into common entities and removes duplicate definitions.

• Usage and responsibility matrices show relationship between processes, entities, business goals and critical success factors.

• Requirements elicitation produces a record of the business in terms process, information and business rules.

20

Requirements Elicitation (Contd.)

Requirements Elicitations

Processes

Information(Data)

Rules

RequirementsSpecifications

21

Analysis• Analysis phase analyses the business

requirements.

• Several modeling techniques can be used.– Entity-Relationship (ER) modeling used to describe

data structures.– Data flow diagrams (DFD) used to describe the

major functions in the system.– State transition diagrams (STD) describe the

dynamics in real time systems.– Object oriented models describe objects in the

problem domain, their attributes, their relationships and their dynamics.

22

Design• Process of defining the software to implement the

application.• Specification of the computer related aspects of

the application,– Screen designs– Report designs– Logical and physical database structures– Data view for application programs– Pseudo-code and mini-specifications for program modules– Communications and integration considerations

• Prototyping and simulations used to refine these aspects in collaboration with users or domain experts

23

Implement and Produce

• Emphasis on implementation and coding.

• Objective is to transform the output of analysis and design phases into the input required to build an industrial strength application.

• Automatic code generation.

• Languages– Procedural languages– Object oriented languages

24

Testing

• Develop testing strategies.

• Use test data to test the functionality of the software.

• Test software in simulated environments.

• Test software in real environments.

25

Production and Maintenance

• Release software for deployment.

• Monitor operation in warranty period to detect faults and bugs.

• Accommodate changing requirements.

• Provide functional enhancements.