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