1

Software Engineering - 66312

Chap 1

Instructor : Haya Samamneh

2

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

3

What is CASE (Computer-Aided Software Engineering)

• Software systems which 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

4

Chapter 2

Socio-technical Systems

(Computer-based System Engineering)

5

System Engineering Is the activity of specifying, designing, implementing, deploying, maintaining systems, which include hardware, software , people and interaction of the system with users and its environment.

6

Examples of emergent properties

• The reliability of the system

– This depends on the reliability of system components and the relationships between the components.

• The usability of a system – This is a complex property which depends on

the system operators and the environment where it is used.

7

Types of emergent properties

• Functional properties

– These appear when all the parts of a system work together to achieve some objective.

8

Types of emergent properties

• Non-functional emergent properties– Examples are reliability, performance,

safety, and security.

– These relate to the behaviour of the system in its operational environment.

– They are often critical for computer-based

systems as failure that may make the system unusable.

9

• Because of component inter-dependencies, faults can be propagated through the system, so failure in one component can affect the operation of other components.

• System failures often occur because of unforeseen inter-relationships between component.

Complexity of emergent system properties- reliability

10

– Safety - the system that reflects the system’s ability to operate without danger

– Security - the system should not permit unauthorised use

11

• Using spiral process , each round on the spiral may add more detail to design.

12

The system engineering process

Systemintegration

Sub-systemdevelopment

Systemdesign

Requirementsdefinition

Systeminstallation

Systemevolution

Systemdecommissioning

13

Spiral model of requirements and designSpiral process 2

System Requirements and Design

ProblemDefinition

Review andAssessment

RequirementsElicitation and

Analysis

ArchitecturalDesign

Start

14

Chapter 2 , Cont…

Socio-technical Systems

(Computer-based System Engineering)

15

7 -System evolution• Large and complex systems have a long lifetime. They must

evolve to meet changing requirements[ error in system or change environment]

• Evolution is inherently costly because:– Changes must be analyzed from a technical and business

perspective [after changing must get the same goal of the system]

– Sub-systems interact [change in subsystem may affects on other subsystems]so problems can arise

– As systems Age: System structure is corrupted as changes are made to it, so the cost of making changes increases

• Existing systems which must be maintained are sometimes called legacy systems

16

Critical Systems

Chapter 3

Instructor: Haya Sammaneh

17

Critical Systems

• It is the systems that fail to deliver the expected objective in which any system failure can result in economic losses, physical damage or human life loss.

18

Dependability

• Principal dimensions of dependability are:– Availability;– Reliability;– Safety;– Security;

19

Dimensions of dependability

Dependability

Availability Reliability Security

The ability of the systemto deliver services when

requested

The ability of the systemto deliver services as

specified

The ability of the systemto operate withoutcatastrophic failure

The ability of the systemto protect itelf againstaccidental or deliberate

intrusion

Safety

20

Other dependability properties

• Repairability– Reflects the extent to which the system can be repaired

in the event of a failure

• Maintainability– Reflects the extent to which the system can be adapted

to new requirements;

• Survivability– Reflects the extent to which the system can deliver

services whilst under hostile attack;

• Error tolerance– Reflects the extent to which user input errors can be

avoided and tolerated.

21

Chapter 4 - Part 1

Software Processes

22

The software process

• A set of activities required to develop a software system such as:

– Specification, functionality and constraints must be defined.

– Design and implementation, software meet the specification must be produced.

– Validation, it does what the customer wants.– Evolution, must evolve to meet changes.

23

software process model

• A software process model is an abstract representation of a process.

24

Generic software process models• The waterfall model

– Separate and distinct phases of specification and development

• Evolutionary development– Specification and development are interleaved

• Reuse-based development– The system is assembled from existing

components

25

Waterfall modelRequirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

26

Waterfall model

• Linear sequential model

• Distinct stages with deliverables at the end of each phase

• The main advantage : Each phase is terminated with the approval of a

document.

• high process visibility—it is easy to see where in the process you are.

27

Waterfall model problems• The drawback of the waterfall model is the

difficulty of making changes after the process is underway

• Therefore, this model is only appropriate when the requirements are well-understood

• The waterfall model is mostly used when the project is part of a larger systems engineering projects where a system is developed at several sites.

28

Evolutionary development

• Is based on the idea of developing an initial implementation , exposing this to user and refining it through many versions until a system has been developed.

29

Evolutionary development

ValidationFinal

version

Development Intermediateversions

Specification Initialversion

Outlinedescription

Concurrentactivities

30

Evolutionary development-types

• Exploratory development– Should start with well-understood requirements, and

work with the customer to explore their requirements to deliver a final system.

– The system evolves by adding a new feature proposed by the customer.

• Throw-away prototyping– Objective is to understand the customer’s requirements

and develop a better requirements for the system. Should start with poorly understood requirements

31

Chapter 4

Part-2

Software Processes

32

In Ch4 Lec 5 – Part 1 we discuss:

1- Generic software process model a. waterfall model b. evolutionary model c. Formal systems d. reuse- based component model

In Ch4 Lec 5 – Part 2 we discuss:

2- Iterative process model a. Incremental development (delivery) b. Spiral development

3- software process

4- CASE tools

33

Process iteration• process iteration where earlier stages are

reworked in response to change request is always part of the process for large systems

• The iteration process models that have been designed to support process iteration??

– 1- Incremental development (delivery)– 2- Spiral development

34

1 -Incremental delivery

• It is an in between approach which combines the advantages of waterfall and evolutionary models.

• Rather than deliver the system as a single delivery, the software specification, design and implementation is broken down into increments with each increment delivering part of the required functionality.

35

Incremental delivery

• User requirements are prioritized and the highest priority requirements are included in early increments

• Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve

36

Incremental delivery advantages• Customer can gain value from the system with each

increment so system functionality is available earlier

• Early increments act as a prototype to help elicit requirements for later increments

• Lower risk of overall project failure

• The highest priority system services tend to receive the most testing

• it is useful when staffing is unavailable for a complete implementation.

37

2 -Spiral development• Process is represented as a spiral rather than as a

sequence of activities with backtracking from one activity to another.

• Each loop in the spiral represents a phase in the software process.

• The inner loop might be connected to feasibility, next loop with requirements definitions and so on.

• Risks are explicitly assessed and resolved throughout the process

38

Spiral model of the software process

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

39

Spiral model

• The main different between the Spiral model and other Software process model:

is the explicit recognition of the risk (something that can be go wrong)

40

Chapter 5

Project management

41

5.2.2 Activity organization (milestones and deliverables)

• Milestones are the end-point of a process activity, the software process must be broken down into basic activities.

• At the end of each milestone there should be a formal output such as a report.

• Deliverables are project results delivered to customers

• deliverables are milestones but milestones need not be deliverables.

• Milestones are an internal project result used by manager to check project progress that are not delivered to customer

42

5.3 Project scheduling• Split project into tasks and estimate time and resources required to

complete each task

• Organize tasks concurrently (simultaneously or side by side) to make optimal use of workforce.

• Minimize task dependencies to avoid delays caused by one task waiting for another to complete

• Dependent on project managers intuition and experience

• schedules must be continually updated as better progress info becomes available.

43

Scheduling• The maximum a mount of time of any activity is from

8-10 weeks. • The minimum at least 1 week

• If it is larger than this , it must be divided.

44

5.3.1 Bar charts and activity networks

• Graphical notations used to illustrate the project schedule

• Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two

• Network Activity show task dependencies and the the critical path

• Bar charts show schedule against calendar time

• The minimum time required to finish the project is called the critical path, which it is the longest path in the activity graph.

45

Task duration and dependenciesExample: T3 start after T1 finish.

Task Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)

46

Activity networkfor example, if T8 is delayed 2 weeks, it will not affect the completion

date because it does not lie on critical path.The critical path is: T1 T3 T9 T11T12The minimum days

required to complete project is : 8+ 15+ 15+7+10 =55 day

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4

47

Activity timeline4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1T2

M1

T7T3

M5T8

M3

M2T6

T5M4

T9

M7T10

M6

T11M8

T12

Start

Finish

48

Staff allocation4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

49

5.4 Risk management

Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project.

50

Risk management continues..• A risk is a probability that some adverse (unfavorable)

circumstance will occur, such categories are:

– Project risks affect schedule or resources. e.g. Loss of an experienced designer

– Product risks affect the quality or performance of the software being developed.

e.g. the failure of a purchased component.

– Business risks affect the organization developing a software

– e.g. a competitor introducing a new product

51

Chapter 6 Software Requirements

Part - 1

52

Types of requirement (level of description)

• User requirements– Statements in natural language plus diagrams of

the services the system provides and its operational constraints. Written for client and contractor managers.

• System requirements– A structured document setting out detailed

descriptions of the system services and constraints in detail. Written as a contract between a system buyer and developer.

53

Requirements completeness and consistency

• In principle requirements should be both complete and consistent– Complete means, they should include descriptions

of all facilities required– Consistent means, there should be no conflicts or

contradictions in the descriptions of the system facilities

• In practice, it is impossible to produce a complete and consistent requirements document

54

Chapter 7

Requirements Engineering Processes

Haya Sammaneh

55

Topics covered

• Feasibility studies

• Requirements elicitation and analysis

• Requirements validation

• Requirements management

56

c. Scenarios

• Scenarios are descriptions of how a system is used in practice, a real-life examples of how a system can be used.

• Scenarios are particularly useful for adding detail to an outline requirements description

57

Event scenario - start transaction

Validate user

Request PIN

Selectservice

Timeout

Return card

Invalid card

Return card

Stolen card

Retain card

Incorrect PIN

Re-enter PIN

Incorrect PIN

Return card

Card

PIN

Card present

Accountnumber

PIN

Accountnumber

Valid card

User OK

58

c. Use cases

• Use-cases are a scenario based technique for requirement elicitation in the UML notations that used in object-oriented system model (Unified Modelling Language) which identify the actors in an interaction and which describe the interaction itself

• A set of use cases should describe all possible interactions with the system

• Sequence diagrams may be used to add detail to use-cases by showing the sequence of event in the system

59

Use cases, cont..

• The sequence diagram (ch 6) is used to add information to use-case.

• The sequence diagram shows the:

1- actors used in the interaction

2- objects that the actors interact with.

3- operation associated with these objects.

60

Library system , example.

• Interaction for downloading and printing article.

• Objects used in this interaction are:

1. Article

2. Form

3. workspace

4. printer

61

Lending use-case

Lending services

62

use-cases for Library system

Lending services

User administration

Supplier Catalog services

LibraryUser

LibraryStaff

63

Example of sequence diagram of Printing article.

User

item:Article

copyrightForm:Form

request

complete

myWorkspace:Workspace

myPrinter:Printer

request

return

copyright OK

deliver

article OK

print send

confirminform

delete