1

(CSC) Dr. Joe Essien

2

Software Engineering 1
COURSE OUTLINE

Dr Joe Essien - (CSC 314) Operating Systems

3
Software
Engineering 1

Lesson 1

INTRODUCTION
 What is Software Engineering?
4

 Solve Problems
 Software products are large and complex
 Development requires analysis and
synthesis
– Analysis: decompose a large problem into smaller, understandable
pieces
• abstraction is the key
– Synthesis: build (compose) a software from smaller building blocks
• composition is challenging
 What is Software Engineering?
5

 Method: refers to a formal procedure; a formal “recipe” for

accomplishing a goal that is typically independent of the
tools used
 Tool: an instrument or automated system for accomplishing
something in a better way
 Procedure: a combination of tools and techniques to
produce a product
 Paradigm: philosophy or approach for building a product
(e.g., OO vs structured approaches)
 What is Software Engineering?
6

Where Does the Software Engineer Fit In?

 Computer science: focusing on computer

hardware, compilers, operating systems, and
programming languages.

 Software engineering: a discipline that uses

computer and software technologies as a
problem-solving tools
 What is Software Engineering?
7

• Relationship between computer science and software engineering

 What is a Good Software?
8

 The transcendental view: quality is something we can

recognize but not define

 The user view: quality is fitness for purpose

 The manufacturing view: quality is conformance to specification

 The product view: quality tied to inherent product characteristics

 The value-based view: depends on the amount the customers is

willing to pay for it
 What is a Good Software?
9

 Good software engineering must always

include a strategy for producing quality
software
 Three ways of considering quality
 The quality of the product
 The quality of the process
 The quality of the product in the context of the business
environment
 What is a Good Software?
10

The quality of the product

 Users judge external characteristics (e.g., correct functionality, number

of failures, type of failures)

 Designers and maintainers judge internal characteristics (e.g., types of

faults)

 Thus different stakeholders may have different criteria

 Need quality models to relate the user’s external view to developer’s

internal view
 What is a Good Software?
11

The quality of the product

• McCall’s quality model

 What is a Good Software?
12

The quality of the process

 Quality of the development and maintenance process is as important as
the product quality
 The development process needs to be modeled
 Modeling will address questions such as
 Where to find a particular kind of fault
 How to find faults early
 How to build in fault tolerance
 What are alternative activities

• Models for process improvement

– SEI’s Capability Maturity Model (CMM)
– ISO 9000
– Software Process Improvement and Capability dEtermination (SPICE)
 What is a Good Software?
13

The quality of the Context of the Business Environment

 Business value is as important as technical value

 Business value (in relationship to technical value) must be quantified

 A common approach: return on investment (ROI) – what is given up

for other purposes

 ROI is interpreted in different terms: reducing costs, predicting savings,

improving productivity, and costs (efforts and resources)
 Who Does Software Engineering?
14

 Customers: the company, organization, or

person who pays for the software system
 Developers: the company, organization, or
person who is building the software system
 Users: the person or people who will actually
use the system
 Who Does Software Engineering?
15

Participants (stakeholders) in a software development project

 Engineering Approach
16

Building a System
 Requirement analysis and definition
 System design
 Program design
 Writing the programs
 Unit testing
 Integration testing
 System testing
 System delivery
 Maintenance
Software Engineering Process
 Structured set of activities required to develop a
software system
 Specification
 Design
 Validation
 Evolution

 Activities vary depending on the organization

and the type of system being developed.
 Must be explicitly modeled if it is to be
managed.
Engineering Process Model

 Specification: Set out the requirements and

constraints on the system.
 Design: Produce a model of the system.
 Manufacture: Build the system.
 Test: Check the system meets the required
specifications.
 Install: Deliver the system to the customer and
ensure it is operational.
 Maintain: Repair faults in the system as they
are discovered.
 Members of Development Team
19

 Requirement analysts: work with the customers to identify and

document the requirements
 Designers: generate a system-level description of what the
system us supposed to do
 Programmers: write lines of code to implement the design
 Testers: catch faults
 Trainers: show users how to use the system
 Maintenance team: fix faults that show up later
 Librarians: prepare and store documents such as software
requirements
 Configuration management team: maintain correspondence
among various artifacts
 Members of Development Team
20

Typical roles played by the members of a development team

 Progress of Software Engineering
21

 The economies of all developed nations are dependent on

software.

 More and more systems are software controlled.

 Software engineering is concerned with theories, methods

and tools for professional software development.

 Software engineering expenditure represents a

significant fraction of the GNP of developed countries.
 Software Cost
22

 Software costs often dominate system costs. The

costs of software on a PC are often greater than the
hardware cost.

 Software costs more to maintain than it does to

develop.

 Software engineering is concerned with cost-

effective software development.
 Software Products
23

 Generic products:
 Stand-alone systems which are produced by a
development organization and sold on the open market
to any customer.
 Customized products:
 Systems which are commissioned by a specific
customer and developed specially by some contractor.
 Software Products Attributes
24

 Maintainability
 Dependability
 Efficiency
 Usability

 Complex  complicated

 Complex = composed of many simple parts related to one another

 Complicated = not well understood, or explained

Importance of Product
Characteristics
 The relative importance of these characteristics
depends on the product and the environment in which
it is to be used.

 In some cases, some attributes may dominate

 In safety-critical real-time systems, key attributes may
be dependability and efficiency.

 Costs tend to rise exponentially if very high levels of

any one attribute are required.
26
Software
Engineering 1

Lesson 2

AVOIDING COMMON CAUSES

OF SOFTWARE PROJECT
FAILURE
 Learning Objectives
27

 This document is primarily aimed at those managing

or otherwise involved in the delivery of projects
across the Government.

 Addressing the stated issues should enable you to

increase the success rate on software projects

 At the end of this module, you will be able to:

 Identify reasons why projects fail.
 Prevent project failure.
 Be accountable for successful projects.
 Executive Summary
28

 For small businesses holding government contracts, there are

multiple challenges to ensuring a successful engagement. It is
important to identify these challenges and adequately plan to
avoid common causes of project failure.
 Typical causes of project failure occur when the following
criteria for success are not met:
1. on time delivery,
2. on or under budget,
3. acceptance by client based on stated scope of work.
 Only a few projects achieve all three criteria. Many more are
delivered which fail on one or more of these criteria, and a
substantial number fail badly enough that they are cancelled.
 You can take certain actions which will ensure your contracts
do not fail.
 Common Causes of Project Failure
29

Projects often fail because of one or more of the

following five reasons:

1. Poor planning,
2. Lack of leadership,
3. Inadequate knowledge,
4. People problems,
5. Lifecycle problems.
 Reason 1: Poor Planning
30

Poor planning can include:

− Lack of communication.
− Not breaking down development into phases or steps.
− Not prioritizing operational activities, objectives.
− Not obtaining stakeholder approval.
− No business plan or inadequate business plan.
− Unrealistic expectations set, e.g., financial investment,
time required, set-up costs.
− Inadequate funding/capital or poor use of funds/capital.
− Lack of time commitment.
− Unrealistic scheduling.
 Reason 2: Lack of Leadership
31

Lack of leadership can include:

− Not defining ownership or the leadership structure or

not identifying decision makers.
− Not making decisions timely or decisively.
− Lacking relevant business and management expertise in
areas such as finance, purchasing, selling, production,
and hiring and managing employees.
− Neglecting your leadership role.
− Not having a strategic vision.
− Holding unrealistic expectations of others.
 Reason 3: Inadequate Knowledge
32

Inadequate knowledge can include:

− Lacking skills and a proven approach to project

management.
− Failing to price your product or service correctly.
− Not addressing potential risks due to inexperience.
− Not estimating, monitoring, or controlling expenditures.
− Not putting a process in place for measuring and
tracking results.
− Having an incomplete or vague project work plan.
− Using inadequate control systems.
 Reason 4: People Problems
33

People problems can include:

− Lacking contact with senior management.

− Lacking leadership.
− Lacking effective project team integration
between clients, the supplier team, and the
supply chain.
− Being unable to resolve conflicts.
− Not having adequate resources due to
under/over estimation of work.
 Reason 5: Lifecycle Problems
34

Lifecycle problems can include:

− Failing to clearly and completely define the requirements,

resulting in building the wrong features or gaps in the
features needed.
− Using new or state of the art technology that cause
unanticipated problems.
− Using a poor technical design that does not allow for
modification or is not scalable.
− Changing requirements late in the project and continuing
change requests which cause the project to drift.
− Using technology components that do not fit together as
designed.
− Using poor initial testing techniques that cause repeated
errors.
 8 Common Issues To Address
35

1. Lack of clear links between the project and the organization's key
strategic priorities, including agreed measures of success.
2. Lack of clear senior management ownership and leadership.
3. Lack of effective engagement with project stakeholders.
4. Lack of skills and proven approach to project management and risk
management.
5. Too little attention to breaking developments and implementation into
manageable steps.
6. Evaluation of proposals driven by initial price rather than long-term
value for money (especially securing delivery of business benefits).
7. Lack of understanding of, and contact with the industry at senior levels
in the organization.
8. Lack of effective project team integration between clients, the supplier
team and the supply/resource chain.
 8 Common Issues To Address: Issue #1
36

1. Lack of clear links between the project and the organization's key strategic
priorities, including agreed measures of success.

 Do we know how the priority of this project compares and aligns with our other
delivery and operational activities?
 Have we defined the critical success factors (CSFs) for the project?
 Have the CSFs been agreed to by suppliers and key stakeholders?
 Do we have a clear project plan that covers the full period of the planned delivery
and all business change required, and indicates the means of benefits realization?
 Is the project founded upon realistic timescales, taking account of statutory lead-
times, and showing critical dependencies such that any delays can be handled?
 Are the lessons learned from relevant projects being applied?
 Has an analysis been undertaken of the effects of any slippage in time, cost, scope or
quality? In the event of a problem/conflict at least one must be sacrificed.
 8 Common Issues To Address: Issue #2
(Slide 1 of 2)
37

2. Lack of clear senior management ownership and leadership.

 Does the project management team have a clear view of the interdependencies
between projects, the benefits, and the criteria against which success will be
judged?
 If the project traverses organizational boundaries, are there clear governance
arrangements to ensure sustainable alignment with the business objectives of all
organizations involved?
 Are all proposed commitments and announcements first checked for delivery
implications?
 Are decisions taken early, decisively, and adhered to, in order to facilitate
successful delivery?
 8 Common Issues To Address: Issue #2
(Slide 2 of 2)
38

 Does the project have the necessary approval to proceed from

its nominated Oversight Manager either directly or through
delegated authority to a designated Senior Responsible Owner
(SRO)?
 Does the SRO have the ability, responsibility and authority to
ensure that the business change and business benefits are
delivered?
 Does the SRO have a suitable track record of delivery? Where
necessary, is this being optimized through training?
 8 Common Issues To Address:
Issue #3
39

3. Lack of effective engagement with project stakeholders.

 Have we identified the right stakeholders?

 Have we as intelligent customers, identified the rationale for doing so (e.g. the
why, the what, the who, the where, the when and the how)?
 Have we secured a common understanding and agreement of stakeholder
requirements?
 Does the business case take account of the views of all stakeholders including
users?
 Do we understand how we will manage stakeholders (e.g. ensure buy-in, overcome
resistance to change, allocate risk to the party best able to manage it)?
 Has sufficient account been taken of the existing organizational culture?
 While ensuring that there is clear accountability, how can we resolve any
conflicting priorities?
 8 Common Issues To Address: Issue
40
#4 (Slide 1 of 2)
4. Lack of skills and proven approach to project management and risk
management.

 Is there a skilled and experienced project team with clearly defined roles and
responsibilities? If not, is there access to expertise, which can benefit those
fulfilling the requisite roles?
 Are the major risks identified, weighted and treated by the SRO, the Director, and
Project Manager and/or project team?
 Has sufficient resourcing, financial and otherwise, been allocated to the project,
including an allowance for risk?
 Do we have adequate approaches for estimating, monitoring and controlling the
total expenditure on projects?
 8 Common Issues To Address: Issue
41
#4 (Slide 2 of 2)
 Do we have effective systems for measuring and tracking the
realization of benefits in the business case?
 Are the governance arrangements robust enough to ensure that
"bad news" is not filtered out of progress reports to senior
managers until an adequate resolution is highlighted?
 If external consultants (subcontractors) are used, are they
accountable and committed to help ensure successful and
timely delivery?
 8 Common Issues To Address: Issue #5
42

5. Too little attention to breaking developments and implementation into

manageable steps.

 Has the approach been tested to ensure it is appropriate in scope (e.g. in IT-enabled
projects)?
 Has sufficient time been built-in to allow for planning applications in Property &
Construction projects for example?
 Have we done our best to keep delivery timescales short so that change during
development is avoided?
 Have enough review points been built-in so that the project can be stopped, if
changing circumstances mean that the business benefits are no longer achievable
or no longer represent value for money?
 Is there a business continuity plan in the event of the project delivering late or
failing to deliver at all?
 8 Common Issues To Address: Issue #6
43

6. Evaluation of proposals driven by price rather than long-term value

(especially securing delivery of business benefits).

 Do we have a proposed evaluation approach that allows us to balance financial

factors against quality and security of delivery?
 Is the evaluation based on whole-life value for money, taking account of capital,
maintenance and service costs?
 Does the evaluation approach take account of business criticality and affordability?
 Is the evaluation approach business driven?
 8 Common Issues To Address: Issue #7
(Slide 1 of 2)
44

7. Lack of understanding of, and contact with the industry at senior levels in
the organization.

 Have we tested that the industry understands our approach and agrees that it is
achievable?
 Have we asked suppliers to state any assumptions they are making against their
proposals?
 Have we checked that the project will attract sufficient competitive interest?
 Is senior management sufficiently engaged with the industry to be able to assess
supply-side risks?
 Do we have a clear strategy for engaging with the industry or are we making
sourcing decisions on a piecemeal basis?
 8 Common Issues To Address: Issue #7
(Slide 2 of 2)
45

 Are the processes in place to ensure that all parties have a clear
understanding of their roles and responsibilities, and a shared
understanding of desired outcomes, key terms and deadlines?
 Do we understand the dynamics of the industry to determine
whether our acquisition requirements can be met, given
potentially competing pressures in other sectors of the
economy?
 8 Common Issues To Address: Issue #8
46

8. Lack of effective project team integration between clients, the supplier

team and the supply/resource chain.

 Has a market evaluation been undertaken to test market responsiveness to the

requirements being sought?
 Are the procurement routes that allow integration of the project team being used?
 Is there early supplier involvement to help determine and validate what outputs and
outcomes are sought for the project?
 Has a shared risk register been established?
 Have arrangements for sharing efficiency gains throughout the supply team been
established?
 How to Prevent Project Failure (Slide
1 of 2)
47

 Require weekly status reports that include:

 Project start and completion dates.
 Which milestones you’ve passed.
 Percentage of the project that is complete.
 Any accomplishments worth mentioning.
 Important meetings attended.
 Any threats or potential risks to the projected timeline.
 Description of any problems you’ve encountered and resolved.
 Personnel or equipment limitations.
 Budget status.
 Build an effective team by considering:
 Employee skill, experience, participation ability, the projects they are already
working on, and morale.
 Pair newer resources with mentors.
 Set a realistic schedule and stick with it.
 Establish concrete, clear goal planning in project management.
 How to Prevent Project Failure (Slide 2
of 2)
48

 Ensure senior management ownership and leadership from the

beginning.
 Require effective engagement with project stakeholders.
 Ensure adequate skills and proven approach to project
management and risk management.
 Pay attention to breaking developments and implementation
into manageable steps.
 Evaluate proposals based on long-term value rather than price
to secure delivery of business benefits.
 Maintain connectivity with the industry at senior levels.
 Ensure effective project team integration between clients and
the supply/resource chain.
 Key Takeaways from This Module
49

 For small businesses holding government contracts, there are

multiple challenges to ensuring a successful engagement.
 It is important to identify these challenges and adequately
plan to avoid common causes of project failure.
 Project failure can be avoided by:
 Planning properly.

 Hiring the right team.

 Putting the right metrics in place.

 Creating clear links between the project and the

organization's key strategic priorities

50
Software
Engineering 1

Lesson 3

SOFTWARE DEVELOPMENT
METHODOLOGIES
 DEFINITION OF TERMS

Principle = general statement describing desirable properties

Method = general guidelines governing some activity
Technique = more technical and mechanical than method
Methodology = package of methods and techniques packaged

Tools

Methodologies

Methods and Techniques

Principle

— Ghezzi et al. 1991

1.51
Software Development Lifecycle Model

Definition.
A (software/system) lifecycle model is a description
of the sequence of activities carried out in an SE
project, and the relative order of these activities.
Software Lifecycle Models
A software lifecycle model is a standardised
format for
 planning
 organising, and
 Running a new development project.

Hundreds of different kinds of models are known and used.

Many are minor variations on just a small number of basic models. In this
section we:

 survey the main types of model, and

 consider how to choose between them.
Software Development Lifecycle Model

It provides a fixed generic framework that

can be tailored to a specific project.

Project specific parameters will include:

 Size, (person-years)
 Budget,
 Duration.

project plan =
lifecycle model + project parameters
Software Development Lifecycle Model

There are hundreds of different lifecycle models

to choose from, e.g:
 waterfall,
 code-and-fix
 Spiral
 V-Model
 Rapid prototyping
 Agile methods, extreme programming (XP)
 COTS …
But many are minor variations on a smaller number of basic models.
Software Development Lifecycle Model

By changing the lifecycle model, we can

improve and/or tradeoff:

 Development speed (time to market)

 Product quality
 Project visibility
 Administrative overhead
 Risk exposure
 Customer relations, etc, etc.
Generic Process Model and
Artefacts
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
Generic Software Process Models
Following Software Development Life Cycles will be
discussed;
 Waterfall
 Code and Fix
 Iterative or Incremental
 Spiral Model
 Rapid Prototyping
 Agile (XP)
 V-Model
 COTS
Waterfall Method

 Unidirectional, no way back finish this step before moving to the next
 Unidirectional, finish this step before moving to the next

59
 The Waterfall Model

 The waterfall model is the classic lifecycle

 model – it is widely known, understood and
(commonly?) used.
 In some respect, waterfall is the ”common
sense” approach.
Waterfall Model Documents

Activity Output documents

Requirements analysis Feasibility study, Outline requirements
Requirements definition Requirements document
System specification Functional specification, Acceptance test plan
Draft user manual
Architectural design Architectural specification, System test plan
Interface design Interface specification, Integration test plan
Detailed design Design specification, Unit test plan
Coding Program code
Unit testing Unit test report
Module testing Module test report
Integration testing Integration test report, Final user manual
System testing System test report
Acceptance testing Final system plus documentation
Waterfall Advantages
1. Easy to understand and implement.
2. Widely used and known (in theory!)
3. Reinforces good habits: define-before- design,
design-before-code
4. Identifies deliverables and milestones
5. Document driven, URD, SRD, … etc.
Published documentation standards, e.g. PSS-
05.
6. Works well on mature products and weak
teams.
Waterfall Disadvantages I
1. Idealised, doesn’t match reality well.
2. Doesn’t reflect iterative nature of exploratory
development.
3. Unrealistic to expect accurate requirements so
early in project
4. Software is delivered late in project, delays
discovery of serious errors.
Waterfall Disadvantages II
5. Difficult to integrate risk management
6. Difficult and expensive to make changes
to documents, ”swimming upstream”.
7. Significant administrative overhead,
costly for small teams and projects.
Code-and-Fix

This model starts with an informal general

product idea and just develops code until a
product is ”ready” (or money or time runs
out). Work is in random order.

Corresponds with no plan! (Hacking!)

Code-and-Fix Advantages

1. No administrative overhead
2. Signs of progress (code) early.
3. Low expertise, anyone can use it!
4. Useful for small “proof of concept” projects, e.g.
as part of risk reduction.
Code-and-Fix Disadvantages
1. Dangerous!
1. No visibility/control
2. No resource planning
3. No deadlines
4. Mistakes hard to detect/correct
2. Impossible for large projects,
communication breakdown, chaos.
Iterative Development
In practice, development is always iterative, and all activities
progress in parallel.

1.68
Iterative Development
Advantages of Iterative model:
 A high-level design of the application is created before building
the product and defining the design solution for the entire
product.

 Then the design is evolved based on what had been built.

 The product is built and improved step by step. Hence it is easy

to track the defects at early stages. This avoids the downward
flow of the defects.

 In iterative model, a reliable user feedback can be obtained.

 In iterative model less time is spent on documenting and more

time is given for designing.
1.69
Iterative Development
Disadvantages of Iterative model:

 Each phase of an iteration is rigid with no overlaps

 Costly system architecture or design issues may arise
because not all requirements are gathered up front for the
entire lifecycle

When to use iterative model:

 Requirements of the complete system are clearly defined

and understood.
 When the project is big.
 Major requirements must be defined; however, some details
can evolve with time.
1.70
The Unifying the Iterative
Process
Inception Elaboration Construction Transition
Requirements

Analysis

Design

Implementation

Test

Iter. Iter. Iter. Iter.

#1 #2 ... ... ... ... ... ... #n-1 #n

Develop increment of functionality, repeat in a feedback loop

1.71
Boehm’s Spiral Lifecycle

Planning = determination Risk Analysis = Analysis of

of objectives, alternatives alternatives and identification/
and constraints resolution of risks

Risk = something that

initial requirements will delay project or
increase its cost

completion go, no-go decision

first prototype
alpha demo

Customer Evaluation = Engineering =

Assessment of the Development of the
results of engineering evolving system next level product

1.72
 Cumulative cost Evaluate alternatives,
Determine objectives, Identify & resolve risks
alternatives & constraints

Prototypes Operational
Review & Start P1 P2 P3 Prototype
commitment RequirementsConcept
Design, Detailed design
plan Of Operation Validation
Development & Verification
plan Requirements
validation Coding
Integration &
Test plan Unit & Integration
Testing
End Acceptance Develop & verify
Plan next phase
Testing next-level product
Spiral Model

Each cycle follows a waterfall model by:

1. Determining objectives
2. Specifying constraints
3. Generating alternatives
4. Identifying risks
5. Resolving risks
6. Developing next-level product
7. Planning next cycle
Spiral Process Model
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analy sis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
Spiral Model
Advantages

 High amount of risk analysis hence, avoidance of Risk is

enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle
 Focuses attention on reuse options.
 Focuses attention on early error elimination.
 Puts quality objectives up front.
 Integrates development and maintenance.
 Provides a framework for hardware/software
development.
Spiral Model Advantages
1. Realism: the model accurately reflects the
iterative nature of software development on
projects with unclear requirements
2. Flexible: incoporates the advantages of the
waterfal and rapid prototyping methods
3. Comprehensive model decreases risk
4. Good project visibility.
Spiral Model

Disadvantages
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects.
Requires risk assessment expertise.
Contractual development often specifies process model and
deliverables in advance.
Spiral Model Disadvantages
 Needs technical expertise in risk analysis to
really work
 Model is poorly understood by non-technical
management, hence not so widely used
 Complicated model, needs competent
professional management. High administrative
overhead.
 When to use Spiral model

 When costs and risk evaluation is important.

 For medium to high-risk projects.
 Long-term project commitment is unwise due to
changes to economic priorities.
 Users are unsure of their needs.
 Requirements are complex.
 New product line.
 Significant changes are expected (research and
exploration).
Rapid Prototyping

Key idea: Customers are non-technical and

usually don’t know what they want/can have.

Rapid prototyping emphasises requirements

analysis and validation, also called:
 customer oriented development,
 evolutionary prototyping
Rapid Prototype Workflow

Requirements Capture

Iterate
Quick Design

Build Prototype

Customer Evaluation of
Prototype

Engineer Final
Product
Rapid Prototype Advantages

1. Reduces risk of incorrect user requirements

2. Good where requirements are
changing/uncommitted
3. Regular visible progress aids management
4. Supports early product marketing
Rapid Prototype Disadvantages I

1. An unstable/badly implemented prototype

often becomes the final product.
2. Requires extensive customer collaboration
 Costs customers money
 Needs committed customers
 Difficult to finish if customer withdraws
 May be too customer specific, no broad market
Rapid Prototype Disadvantages
II
3. Difficult to know how long project will last
4. Easy to fall back into code-and-fix without
proper requirements analysis, design, customer
evaluation and feedback.
Agile (XP) Manifesto
XP = Extreme Programming emphasizes:
User feedback essential; feedback loops on several
levels of granularity

 Individuals and interactions

 Over processes and tools
 Working software
 Over documentation
 Customer collaboration
 Over contract negotiation
 Responding to change
 Over following a plan
Agile Principles (Summary)
 Continuous delivery of software
 Continuous collaboration with customer
 Continuous update according to changes
 Value participants and their interaction
 Simplicity in code, satisfy the spec
Agile XP Practices (Summary)
 Programming in pairs
 Test driven development
 Continuous planning, change , delivery
 Shared project metaphors, coding standards and
ownership of code
 No overtime! (Yeah right!)
Agile Advantages

 Lightweight methods suit small-medium size

projects
 Produces good team cohesion
 Emphasises final product
 Iterative
 Test based approach to requirements and quality
assurance
Agile Disadvantages

 Difficult to scale up to large projects where

documentation is essential
 Needs experience and skill if not to degenerate into
code-and-fix
 Programming pairs is costly
 Test case construction is a difficult and specialised
skill.
When to use Agile Methodology
 When new changes are needed to be implemented, this can be done at very
little cost because of the frequency of new increments that are produced.

 Unlike the waterfall model in agile model very limited planning is required to
get started with the project. Agile assumes that the end users’ needs are ever
changing in a dynamic business and IT world.
 Changes can be discussed and features can be updated or removed based on
feedback. This effectively gives the customer the finished system they need.

 Both system developers and stakeholders have more freedom of time and
options than if the software was developed in a more rigid sequential way.
Having options gives them the ability to leave important decisions until more
or better data or even entire hosting programs are available.
V-Model
 The V-model is useful in every phase of the software development life
cycle.
 This model determines the complex relationship between each phase
of the software development and ensures that each phase of software
development is associated with testing.
 It emphasizes that testing occurs in every phase of software
development and does not occur only after the coding is completed.
 It determines the software development process within the
organization.
 It determines the activities and the results to be produced in the
software development.
 It describes the products to be created during the software project.
V-Model
V-Model
V-Model advantages:
 It is also called as verification and validation Model. This
means the verification and validation will be done side by
side.
 It emphasises the strict process flow to develop a quality
product. Errors that occur in any phase will be corrected
in that phase itself.

V-Model disadvantages:
 It needs lot of resources and money
 It needs an established process to implement
 It can be implemented by only some big companies
COTS
 COTS =
Commercial Off-The-Shelf software
 Engineer together a solution from existing
commercial software packages using minimal
software ”glue”.
 E.g. using databases, spread sheets, word
proccessors, graphics software, web browsers, etc.
COTS

COTS Advantages
 Fast, cheap solution
 May give all the basic functionality
 Well defined project, easy to run

COTS Disadvantages
 Limited functionality
 Licensing problems, freeware, shareware, etc.
 License fees, maintainance fees, upgrade

compatibility problems
97
Software
Engineering 1

Lesson 4

Project Planning
SE Project Planning
Project planning is the art of scheduling the
necessary activities, in time, space and across
staff in order to optimise:

 project risk [low] (see later)

 profit [high]
 customer satisfaction [high]
 worker satisfaction [high]
 long-term company goals
SE Project Plan Constraints
SE projects usually live with a fixed financial budget. (An exception is
maintainance?)

Additionally, time-to-market places a strong time constraint.

Example of project constraints designers

programmers managers

money staff

Project constraints

Computing
resources time
Cognitive Contents of SE Project Plan
A project plan contains much information,
but must at least describe:
 resources needed

(people, money, equipment, etc)

 dependency & timing of work

(flow graph, work packages)

 rate of delivery (reports, code, etc)

It is impossible to measure rate of progress

except with reference to a plan.
Stakeholders of SE Project
In addition to project members, the following
may need access to parts of the project plan:

 Management,
 Customers
 Subcontractors
 Suppliers
 Investors
 Banks
Visible Artefacts of SE Project
Unlike other engineers (e.g. civil, electronic, chemical … etc.)
software engineers do not produce anything physical.

It is inherently difficult to monitor an SE project due to lack of

visibility.
This means that SE projects must produce additional deliverables
(artifacts)

which are visible, such as:

 Design documents/ prototypes
 Reports
 Project/status meetings
 Client surveys (e.g. satisfaction level)
 Typical Schedule Requirements Analysis
17-May 31-May 13-Jun 27-Jun 11-Jul 25-Jul 11-Aug 25-Aug 8-Sep
Milestones Complete release 0.1 X
Complete release 0.2 X

Develop release 0.1

C-requirements
D-requirements
Architecture
Detailed design
Implementation
Test

Develop release 0.1

C-requirements
D-requirements
Architecture
Detailed design
Implementation
Unit test
Integration
System test
104
Software
Engineering 1

Lesson 5

REQUIREMENT ANALYSIS
CONCEPTS AND PRINCIPLES
Requirements Process

Aspect-Oriented
Requirements

Object-Oriented
Analysis & Design

Requirements Requirements Requirements

gathering analysis specification

Structured
Analysis & Design

Agile
Development User
Stories

105
Requirements Engineering
Components
 Requirements gathering
 (a.k.a. “requirements elicitation”) helps the customer to
define what is required: what is to be accomplished,
how the system will fit into the needs of the business,
and how the system will be used on a day-to-day basis
 Requirements analysis
 refining and modifying the gathered requirements
 Requirements specification
 documenting the system requirements in a semiformal
or formal manner to ensure clarity, consistency, and
completeness
106
 Requirements Collection

A process of discovery, refinement, modeling, and specification.

During the process, both the developers and customers take active
roles.

User requirements are often expressed informally:

 features

 usage scenarios

Although requirements may be documented in written form, they

may be incomplete, ambiguous, or even incorrect.

1.107
Requirements Analysis and Specification

Analysis is the process of specifying what a system

will do.

 The intention is to provide a clear understanding of

what the system is about and what its underlying
concepts are.

The result of analysis is a specification document.

Does the requirements
specification correspond to
the users’ actual needs?

1.108
 Specifying Customer Requirements

 Distinguish Customer requirements from Detailed

requirements
 Be equipped with ways to express C-requirements
 exploit use cases
 exploit state diagrams
 exploit data flow diagrams
 sketch user interfaces
 Write first parts of a Software Requirements
Specification
Typical Roadmap for Customer Requirements

1. Identify the customer

2. Interview customer representatives

• identify wants and needs
Review with customer
• exploit tools for expression
• sketch GUI’s
• identify hardware

3. Write C-requirements
in standard document form

For all stages, track metrics, e.g., 4. Inspect

• time spent C-requirements
• quantity accomplished
pages of C-requirements On customer approval ...
mins. of customer interaction per pg.
• self-assessed quality (1-10 scale) 5. Build D-requirements
• defect rates from inspections
Prototyping
A prototype is a software program developed to test,
explore or validate a hypothesis, i.e. to reduce
risks.

An exploratory prototype, also known as a

throwaway prototype, is intended to validate
requirements or explore design choices.
 UI prototype — validate user requirements
 rapid prototype — validate functional requirements
 experimental prototype — validate technical
feasibility
1.111
Design
Design is the process of specifying how the specified
system behavior will be realized from software
components. The results are architecture and
detailed design documents.

Object-oriented design delivers models that describe:

 how system operations are implemented by interacting objects
 how classes refer to one another and how they are related by
inheritance
 attributes and operations associated to classes

Design is an iterative process,

proceeding in parallel with
implementation! 1.112
 Object-Oriented Analysis
An object-oriented analysis results in models of the
system which describe:
 classes of objects that exist in the system
 responsibilities of those classes
 relationships between those classes
 use cases and scenarios describing
 operations that can be performed on the system
 allowable sequences of those operations

1.113
Requirements Analysis Concepts and
Principles
- Requirements Analysis
- Communication Techniques
- Initiating the Process
- Facilitated Application Specification
Techniques
- Analysis Principles
- Information Domain
- Modeling
- Partitioning
- Software Prototyping
- Selecting the Prototyping Approach
- Prototyping Methods and Tools
- The Software Requirements Specification
- Specification Principles
- Representation
 Requirements Analysis

Focus on: “what” instead of “how”

Input: Input of the requirements analysis process:

- Software Project Plan
- System specification (if one exists)

Output: Software requirements specification document

- provides the software engineer with models that can be
translated in to data, architectural, interface, and procedure
design.
- customer and developer can check the quality of the
software
and provide the feedback.

Who perform requirements analysis: Business Analysts

 Requirements Analysis
Major tasks and efforts:
- Problem recognition (or system understanding)
- Discover and understand the system requirements
- Refine the requirements
- Evaluation and synthesis:
- what are the alternative solutions
- focus on what solution should be selected or used
instead of how to implement a solution.
- Modeling: to represent the various aspects of the system
- the required data
- information and control flow
- operation behavior
- Specification of:
- software functions, and performance
- interfaces between system elements
- system constraints
Requirements Engineering Process
- Feasibility study:
- Identify and estimate to see if user needs can be satisfied
using current techniques and technologies.

- Requirements analysis:
- The process of deriving the system requirements
through observation of existing systems, discussion
with users and customers, task analysis, and so on.

Requirements definition:
- Translating the information into a REQ. document.

Requirements specification:
- Define system requirements using a consistent
precise, and complete way.
- Using some requirements specification method
Requirements Engineering Process
Feasibility
Study
Requirements
analysis

Requirements
definition
Feasibility
report System Requirements
models specification
Definition of
requirements

Requirements Specification
documents of requirements
Requirements Analysis Process
- Domain understanding:
- Understanding of application domain.

- Requirements collections:
- The process of interacting with customers, users to discover
the requirements for the system.

- Requirements classification:
- Group and classify the gathered requirements.

- Conflict resolution:
- Resolve the conflict requirements.

- Prioritization:
- Identify and list requirements according to their importance

- Requirements validation:
- Check and validate the gathered requirements to see
if they are complete, correct, and sound.
 Requirements Analysis Process
Requirements
definition and
Requirements
specification
validation

Domain
understanding Prioritization

Requirements Conflict
collection resolution

Classification
 Communication Techniques
Initiating the Process:

Q1 set: Context free questions to lead the basic understanding of the

problem

Who is behind the solution?

Who will use the solution?
…..

Q2 set: Questions to gain a better understanding of the problem and the

customer’s perceptions about a solution.

How would you characterize “good” output that would be generated by a

successful solution?

What problems will this solution address?

Q3 set: Meta-questions focus on the effectiveness of the meeting.

Are you the right person to answer these questions? Are your answers
“official”?
Facilitated Application Specification Techniques
(FAST)
Customers and software engineers often have an unconscious “us and
them” mind set.
This may cause: misunderstandings, miss important information,….
To solve the problem, FAST approach is proposed.

FAST encourages the creation of a joint team of customers and

developers.
They work together
- to identify the problem and proposed and
- to negotiate the different elements of solutions and
approaches

The basic guidelines of FAST:

- hold a meeting at a neutral site
- establish rules for preparation and participation
- have a formal meeting agenda
- control the meeting by a “facilitator”
- use a “definition mechanisms”
- have a common goal to
- identify the problem
- propose elements of solutions and requirements
- negotiate different approaches
 Quality Function Deployment
Quality function deployment (QFD) is quality management technique
- Translate the needs of the customer into technical requirements for
software.

QFD identifies three types of requirements:

- Normal requirements:

Objectives and goals:

examples: types of graphic displays, specific system functions

- Expected requirements:

implicit requirements:

examples: ease of human-machine interaction

ease of software installation

- Exciting requirements:

Features go beyond the customer’s expectations

 Analysis Principles
Each analysis method has a unique point of view.

All analysis methods are related by a set of operational principles:

- represent and understand the information domain

- define the functions that the software
- represent the behavior of the software
- use models to depict information, function, and behavior
--> uncover the details in a layered fashion.
- move from essential information toward to details

A set of guidelines for requirement engineering:

- understand the problem before beginning to create the analysis model
- develop prototypes to help user to understand how human-machine
interactions
- record the origin of and the reasons for every requirement
- use multiple views of requirements
- prioritize requirements
- work to eliminate ambiguity
 The Information Domain
Software is built to process data, to transform data from one form to another.

Software also process events.

The first operational analysis principle requires to exam the information domain.

Information domain contains three different views of the data and control:

- information content and relationship:

information content --> represent the individual data and control objects

there are different relationships between data and objects

- information flow:
represents the manner in which data and control change as each moves
through
a system. Data and control moves between two transformations (functions)

- information structure:
represent the internal organization of various data and control items
- data tree structure
- data table (n-dimension)
 Modeling
During software requirements analysis, we create models of the system to be built.
The models focus on:
- what the system must do, not how it does it.

The models usually have a graphic notation to represent:

- information, processing, system behavior, and other features
The second and third operational analysis principles require:
- build models of function and behavior

- Functional models
Software transforms information. Three generic functions:
- input, processing, output
- Behavior models
Most software responds to events from the outside world
A behavior model creates a representation of the states of the software
and events that cause software to change state

Important roles of models:

- The model aids the analyst in understanding the information, function, and
behavior of a system.
- The model becomes the focal point for review in the aspects of
completeness, consistency, and accuracy of the specification.
- The model becomes the foundation for design, providing the designer
with an essential representation of software.
 Partitioning
Partitioning decomposes a problem into its constituent parts.

Establish a hierarchical representation of information (or function):

- exposing increasing detail by moving vertically in the hierarchy
- decomposing the problem by moving horizontally in the hierarchy.

Horizontal partition

SafeHome Software

Configure system Monitor sensors Interact with user

Vertical partition Poll for sensor eventActivate alarm functions

Activate audible alarm Dial phone number

 Software Prototyping
In some cases, it is possible to apply operational analysis principles and derive a
model of software from which a design can be developed.

Selecting the prototyping approach:

The closed-ended approach is called throwaway prototyping.

- a prototype serves only as a rough demonstration of requirements.

The open-ended approach is called evolutionary prototyping.

- a prototype serves as the first evolution of the finished system.

Figure 11.7 selecting the appropriate prototyping approach.

Prototyping Methods and Tools:

- Fourth Generation Techniques

- Reusable Software Components

- Formal Specification and Prototyping Environments

 Software Specification
Specification principles:
- Separate functionality from implementation
- Develop a model of the desired behavior of a system
- Establish the context in which software operates
- Define the environment in which the system operates
- Create a cognitive model rather than a design or implementation model
- Specification is an abstract model of a real system
- Establish the content and structure of a specification (easy to be
changed)

Guidelines for representation:

- Representation format and content should be relevant to the problem

- Information contained within the specification should be nested
-Diagrams and other notational forms should be restricted in number and
consistent in use.
- Representations should be revisable

Software requirements specification standard:

IEEE (standard No. 830-1984) and U.S. Department of Defense

In many cases, a preliminary user’s manual should be provided to presents

the software as a black box.
 Example System Requirements

Identifier Priority Requirement

The system shall keep the door locked at all times, unless commanded otherwise by authorized
REQ1 5 user. When the lock is disarmed, a countdown shall be initiated at the end of which the lock shall
be automatically armed (if still disarmed).
REQ2 2 The system shall lock the door when commanded by pressing a dedicated button.
REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices.
The system should allow mistakes while entering the key code. However, to resist “dictionary
REQ4 4 attacks,” the number of allowed failed attempts shall be small, say three, after which the system
will block and the alarm bell shall be sounded.
REQ5 2 The system shall maintain a history log of all attempted accesses for later review.
REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones.
The system shall allow configuring the preferences for device activation when the user provides a
REQ7 2
valid key code, as well as when a burglary attempt is detected.
The system should allow searching the history log by specifying one or more of these parameters:
REQ8 1 the time frame, the actor role, the door location, or the event type (unlock, lock, power failure,
etc.). This function shall be available over the Web by pointing a browser to a specified URL.
The system should allow filing inquiries about “suspicious” accesses. This function shall be
REQ9 1
available over the Web. 130
131
Software
Engineering 1

Lesson 6

REQUIREMENT ENGINEERING
Requirements Engineering

Requirements Engineering

Requirements Elicitation Requirements Analysis

Requirements Specification Requirements Verification

Requirements Management
Requirements Engineering

 Stakeholder identification
 Stakeholder interviews
 Contract-style requirement lists
 Measurable goals
 Prototypes
 Use cases
Requirements Engineering

 Requirements Elicitation: the task of communicating with

customers and users to determine what their requirements are.
This is sometimes also called requirements gathering.

 Analyzing requirements: determining whether the stated

requirements are unclear, incomplete, ambiguous, or
contradictory, and then resolving these issues.

 Recording requirements: (specification): This is

documentation of requirements by stating user stories, use
cases or process specifications.
Requirements Elicitation
 Analysts can employ several techniques to elicit the
requirements from the customer.
 interviews,
 focus groups (requirements workshops) and creating
requirements lists.
 prototyping and use cases.
 combination of these methods
Software Requirement Analysis
 Is a Process of studying and analyzing the customer and the
user/stakeholder needs to arrive at a definition of software
requirements.

 It determines the needs or conditions to be met for a new or

altered product,

 Requirements must be actionable, measurable, testable,

related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design.

 Requirements can be functional and non-functional.

Types of Requirements
 Functional requirements
 Performance requirements
 Speed, accuracy, frequency, throughput
 External interface requirements
 Design constraints
 Requirements are usually about “what”, this is
a “how”.
 Quality attributes
 i.e. reliability, portability, maintainability,
supportability
Requirements vs. Design
Requirements Design
Describe what will be Describe how it will be done3
delivered
Primary goal of analysis: Primary goal of design:
UNDERSTANDING OPTIMIZATION
There are more than one There is only one (final)
solution solution
Customer interested Customer not interested
(Most of the time)
Software Quality Attributes
 Correctness
 Reliability
 Efficiency
 Integrity
 Usability
 Maintainability
 Verifiability
 Flexibility
 Portability
 Reusability
 Interoperability
 Expandability
Requirements Analysis
Defining Stakeholder profiles
 Description - brief description of the stakeholder type
 Qualify the expertise, technical background, degree of
sophistication

 Responsibilities - List the key responsibilities with regard to the

system being developed
 Success Criteria - How does the stakeholder define success?
 How is Success rewarded? Comments on issues and problems that
may interfere with success, etc.

 Involvement - involved in the project in what way?

 Requirements reviewer, system tester, ...

 Deliverables - required by the stakeholder

Requirements Analysis
Defining User Profiles

 Description - of the user type

Qualify expertise, technical background, degree of sophistication
 Responsibilities - user’s key responsibilities with respect to
the system being developed
 Success Criteria - how this user defines success? – reward
Comments/Issues - Problems that may interfere with success, etc.
This includes trends that make the user’s job easier or harder

 Involvement - How the user is involved in this project?

What role?
 Deliverables - Are there any deliverables the user produces?
And for who?
Requirements Analysis
Defining User Work Environment

 Number of people involved in doing this now?

Number of people that would be involved after?

 How long is a task cycle now?

How long will be the task cycle after?

 Any unique environmental constraints now? Future?

 Which system platforms are in use today? Future?

 What other applications are in use? Need to integrate?

Requirements Analysis
Product Overview

 Put the product in perspective to other related

products and the user’s environment.
Independent?
As a Component of a larger system?

 How do other subsystems interact with this?

 Specify Known interfaces between them and this
component? Illustrate using a Block diagram
 Requirements Analysis
Other Product Requirements

 Hardware platform requirements

 System requirements -- supported host o.s.’s,
peripherals, companion software
 Environmental requirements -- temperature, shock,
humidity, radiation, usage conditions, resource
availability, maintenance issues, type of error recovery
 applicable standards -- legal, regulatory,
communications
 Requirements Analysis
Fundamental Techniques (Views)
functional view
 hierarchy  function tree and business functional diagram
 process  use cases, collaboration diagram
 information flow  data flow diagram (DFD), sequence diagram

data oriented view

 data structures  data dictionary (DD), Data Schema,
 relations between entities  entity relationship diagram (ER)

object-oriented view
 class structure  class diagram
Requirements Analysis

 algorithmic view
 control structures
 pseudo code, structogram, flow diagram
 conditions  rules, decision table
 state-oriented view
 state machines
 Petri nets
 sequence charts
IEEE Std 830-1998 IEEE Recommended Practice for
Software Requirements Specifications -Description

 Abstract:
The content and qualities of a good software requirements
specification (SRS) are described and several sample SRS
outlines are presented. This recommended practice is aimed
at specifying requirements of software to be developed but
also can be applied to assist in the selection of in-house
and commercial software products. Guidelines for
compliance with 12207.1-1997 are also provided.

 Keywords:
contract, customer, prototyping, software requirements
specification, supplier, system requirements specifications
Software Requirement Specification
 A software requirements specification (SRS) is a complete
description of the behavior of the system to be developed

 A document that clearly and precisely describes, each of the

essential requirements of the software and the external
interfaces.
 (functions, performance, design constraint, and quality attributes)

 Each requirement is defined in such a way that its achievement

is capable of being objectively verified by a prescribed method;
for example inspection, demonstration, analysis, or test.
SRS
 Customer Requirements
 Functional Requirements
 Non-functional Requirements
 Performance Requirements
 Design Requirements
 Derived Requirements
 Allocated Requirements
Data Dictionary

 A data dictionary is a collection of information

about data (metadata).
 It maintains information about the definition,
structure, and use of each data element that an
organization uses.
151
Software
Engineering 1

Lesson 7

REQUIREMENT MANAGEMENT
Introduction to Requirements Management

Requirements management includes all activities intended to

maintain the integrity and accuracy of expected requirements

 Manage changes to agreed requirements

 Manage changes to baseline (increments)
 Keep project plans synchronized with requirements
 Control versions of individual requirements and versions of
requirements documents
 Manage relationships between requirements
 Managing the dependencies between the requirements document
and other documents produced in the systems engineering
process 152

 Requirements Management Activities

Requirements
Management

Change control Version control Requirements Requirements

status tracking tracing
 Proposing  Defining a version  Defining a  Defining links to
changes identification possible other
scheme requirement requirements
 Analyzing impact
statuses
 Identifying  Defining links to
 Making decisions
requirements  Recording the other system
 Updating document status of each elements
requirements versions requirement
documents
 Identifying  Reporting the
 Updates plans individual status distribution
requirement of all
 Measuring
versions requirements
requirements
volatility
 Requirements Development (RD)
versus Requirements Management (RM)
 From Management to Tools

 Changes lead to a need for management

 There is no management without:
 Traceability
 Baselines enabling comparisons
 From a practical point of view, there is no traceability
or management without appropriate tools
 Requirement Management

A systematic approach to eliciting, organizing, and documenting the requirement of

the system, and a process that establishes and maintains agreement between the
customer and the project team on the changing requirements of the system.

 Change Management
 Traceability
 Baselines
 Requirements Management Tools
 A factor present in every successful project and absent in every
unsuccessful project is sufficient attention to requirements.

156
 Why Do Requirements Change?
 Change in software development: as inevitable as difficult to
control!
 Better understanding: new requirements become apparent

 Everything else is changing…

 Business
 Context
 Technologies
 Markets
…
 Possible responses to change
 Add, modify, or remove requirements
157
Changing requirements
Requirements will change!
 inadequately captured or expressed in the first place
 user and business needs may change during the
project

Validation is needed throughout the software

lifecycle, not only when the “final system” is
delivered!
 build constant feedback into your project plan
 plan for change
 early prototyping [e.g., UI] can help clarify 1.158
 Some Problems Due to Changing Requirements

 Requirements changing towards the end of

development without any impact assessment

 Unmatched/outdated requirements specifications

causing confusion and unnecessary rework

 Time spent coding, writing test cases or

documentation for requirements that no longer exist
 Requirements Change Factors (1)

 Requirements errors, conflicts, and inconsistencies

 May be detected at any phase (when requirements are

analyzed, specified, validated, or implemented)

 Evolving customer/user knowledge of the system
 When the requirements are developed,

customers/users simultaneously develop a better

understanding of what they really need
 Technical, schedule, or cost problems
 Difficult to plan and know everything in advance

 We may have to revisit the list of requirements and

adapt it to the current situation

 Requirements Change Factors (2)

Changing customer priorities, new needs

 May be caused by a change in the system environment

(technological, business, political...), i.e., the context

 Business and strategic goals may change

 May be caused by the arrival of a new competitor

 Laws and regulations may change

 Collaborating systems may change

 May also be caused by technology changes in the enterprise

(migration to a new operating system, DBMS…)

 May be caused by organizational changes (organizational

structure, business processes, employees…)

 Stable and Volatile Requirements
 Stable requirements are concerned with the essence of a system
and its application domain
 Derived from the client’s principal business activities or domain

 They change more slowly than volatile requirements

 E.g., a hospital will always have doctors, nurses, patients…

 Volatile requirements are specific to the instantiation of the system

in a particular environment for a particular customer at a particular
time
 E.g., in a hospital, we can think of requirements related to the

policies of the government health system.

162
 Annotation of Requirements

 It is essential for requirements management that every

requirement has a unique identification
 The most common approach is requirements numbering

based on chapter/section in the requirements document

 There are several problems with this approach

 Numbers cannot be unambiguously assigned until the

document is complete
 Assigning chapter/section numbers is an implicit

classification of the requirements  may mislead readers

of the document into thinking that the most important
relationships are with requirements in the same section
163
 Requirements Identification Techniques

 Dynamic renumbering
 Some word processing systems allow for automatic renumbering of

paragraphs and the inclusion of cross references

 As you reorganise your document and add new requirements, the system keeps

track of the cross references and automatically renumbers your requirements

depending on its chapter, section, and position within the section
 Database record identification
 When a requirement is identified, it is entered in a requirements database and a

database record identifier is assigned which is then used for all subsequent
references to the requirement
 Symbolic identification
 Requirements can be identified by giving them a symbolic name which is

associated with the requirement itself (e.g., SEC1, SEC2, SEC3… may be used
for requirements which relate to system security)
164
 Attributes of Requirements
 Apart from an identifier, requirements should have attributes that
establish context and background, and go beyond the requirement
description
 For filtering, analysis, metrics…
 Creation date, Last update, Author, Stakeholders (Owners / Source)

 Version number

 Status, Priority, Importance, Stability

 Rationale, Comments

 Acceptance criteria

 Subsystem / Product release number

 The more complex the project, the richer the attributes…

 Many attributes are predefined in RM tools, others are defined by
requirements engineers as required by the project
 Requirements Attributes

 Classes and attributes of a requirements management database

SYS_MODELS RE QUIREMENT SOURCE_LIST
Model: MODEL Identifier: TEXT People: TEXT
Description: TEXT Statement: TEXT | GRAPHIC Documents: TEXT
Next: MODEL | NULL Date_entered: DATE Reqs: REQ_LIST
Date_changed:DATE
Sources: SOURCE_LIST
RE Q_LIST Rationale: REQ_RATIONALE RE Q_RATIONALE
Status: STATUS
Req: REQUIREMENT Dependents: REQ_LIST Rationale: TEXT
Description: TEXT Is_dependent_on: REQ_LIST Diagrams: GRAPHIC
Next: REQUIREMENT Model_links: SYS_MODELS Photos: PICTURE
| NULL Comments: TEXT

 Select only the necessary attributes

166
 Requirements Status

 Help manage the requirement lifecycle

 Their number and nature depend on the process in place

 Example of a set of statuses:

 Proposed: by some stakeholder

 Approved: part of baseline, committed to implement

 Rejected: after evaluation

 Implemented: designed and implemented

 Verified: Relevant tests have passed

 Deleted: Removed from list

 RM includes amongst its tasks the tracking of the status of all

requirements during the project
 Version Control
 Another essential aspect of requirements management
 Every version of a requirement needs to be uniquely identified

 The last version of a requirement must be available to all team members

 Changes need to be documented and clearly communicated

 A version identifier must be updated with every change to the requirement

 Requirements documents should include

 A revision history: changes, dates, by whom, why...

 Standard markers for revisions (e.g., strikethrough or underlined text,

coloring, line markers…)

 Version control tool may be used
 To store and manage the revision history

 To store justifications (to add, modify, delete, reject a requirement)

169
Software
Engineering 1

Lesson 8

TRACEABILITY
Introduction

 What makes a software project successful?

 Meets stakeholder requirements

 How can this be encouraged?

 Traceability

 Traceability in a nutshell
 Shows forward and backward relationships linking

requirements with design, implementation, test, and

maintenance
 Know reasoning for everything and how to test
 Definitions of Traceability (1)

 Requirements traceability refers to the ability to describe and follow the

life of a requirement
 It covers the origins, through its development and specification, to its
subsequent deployment and use, and through all periods of ongoing
refinement and iteration in any of these phases)”.
 A software requirements specification is traceable if the origin of each of
its requirements is clear and if it facilitates the referencing of each
requirement in future development or enhancement documentation.
 Traceability gives essential assistance in understanding the relationships
that exist within and across software requirements, design, and
implementation
171
 Definitions of Traceability (2)

 Traceability is often mandated by contracts and standards.

 E.g., military and aerospace
 One cannot manage what cannot be traced.
 Traceability information helps assess the impact of changes to
requirements, connecting these requirements as well as requirements
for other representations of the system.
 Requirements cannot be managed effectively without requirements
traceability
Why is Traceability Important?

 Ensures that requirements are met

 Understand relationship between requirements and the
delivered system
 Lowers risk
 Creates an audit trail
 Consistency
 Control
 Change

 Development

 Risk
 Importance of Traceability (2)

Benefits of traceability
 Prevents losing knowledge
 Supports the verification process (certification, localization of defects)
 Impact analysis
 Change control
 Process monitoring (e.g., missing links indicate completion level)
 Improved software quality (make changes correctly and completely)
 Reengineering (define traceability links is a way to record reverse engineering
knowledge)
 Reuse (by identifying what goes with a requirement: design, code…)
 Risk reduction (e.g., if a team member with key knowledge leaves)
 Some Traceability Difficulties

 As various stakeholders require different information Huge

amount of requirements traceability information must be
tracked and maintained

 Manual creation of links is very demanding

 Likely the most annoying problem

 Specialized tools must be used

 Integrating heterogeneous models/information from/to different
sources (requirements, design, tests, code, documentation,
rationales…) is not trivial
 Requires organizational commitment
Some Problems with Traceability

 Manual process
 Viewed by developers as a low priority
 Misunderstood
 No single modeling method
 Poor documentation
How is Tracing Performed?

 Client gives developers rough requirements

 Developers create system, hardware, and software
requirements
 Each element is given a unique identifier
 Element – requirement, design attribute, test, etc
 Linkages done manually and managed by a CASE
tool
 Traceability tables are made
 Matrix
Traceability Example

 SRD – System Requirements Document

 High level requirements
 Done by stakeholders
 SS – System Specification
 More detailed requirements
 Developer interpretation
 Segments
 More detailed portions of the SS
 Includes design information
Traceability Example

System Requirements
Document

System Specification
Interface Control
Document

Segment 1 Segment 2 Segment 3

 Backward and Forward Traceability (1)

 Backward traceability
 To previous stages of development
 Depends upon each element explicitly referencing its source in earlier
documents
 Forward traceability
 To all documents spawned by a document
 Depends upon each element in the document having a unique name or
reference number

Business plan Requ irements Document Design Specification

Forward-to traceability Forward-from traceability
Backward-from traceability Backward-to traceability
 Backward and Forward Traceability (2)

Top to bottom from requirements’ point of view

 Forward-to traceability

 Links other documents (which may have preceded the

requirements document) to relevant requirements

 Help validation

 Help evaluate which requirements are affected by changes to

users’ needs

 Forward-from traceability
 Links requirements to the design and implementation components

 Help assure that all requirements have been satisfied

 Backward and Forward Traceability (3)

Bottom to top from requirements’ point of view

 Backward-to traceability
 Links design and implementation components back to

requirements
 Help determine why each item is designed/implemented

 Backward-from traceability
 Links requirements to their sources in other documents or people

 Help validation

 Help evaluate how changes to requirements impact stakeholders

needs
 Types of Traceability (1)

 Requirements – source traceability

 Links requirements with a person or document

 Requirements – rationale traceability

 Requirements – requirements traceability
 Links requirements with other requirements which are, in some way,

dependent on them
 Requirements – architecture traceability
 Links requirements with the subsystems where these requirements are

implemented (particularly important where subsystems are being

developed by different subcontractors)
 Requirements – design traceability
 Links requirements with specific hardware or software components in the

system which are used to implement the requirement

 Types of Traceability (2)

 Requirements – interface traceability

 Links requirements with the interfaces of external systems

which are used in the provision of the requirements

 Requirements – feature traceability
 Requirements – tests traceability
 Links requirements with test cases verifying them (used to

verify that the requirement is implemented)

 Requirements – code traceability
 Generally not directly established, but can be inferred
 Representation – Traceability Table

 Show the relationships between requirements or between

requirements and other artifacts
 Table can be set up to show links between several different elements
 Backward and forward traceability
 Difficult to capture different types of links
 Representation – Traceability Matrix

 Define links between pairs of elements

 E.g., requirements to requirement, use case to requirement, requirement to test

case…
 Can be used to defined relationships between pairs
 E.g., specifies/is specified by, depends on, is parent of, constrains…

 More amenable to automation than traceability table

Depends-on
R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6
 Representation – Traceability List

 Traceability matrices become more of a problem when there

are hundreds or thousands of requirements as the matrices
become large and are sparsely populated

 A simplified form of a traceability matrix may be used where,

along with each requirement description, one or more lists of
the identifiers of related requirements are maintained
Requirement Depends-on
R1 R3, R4
R2 R5, R6
R3 R4, R5
R4 R2
R5 R6
 Factors to Consider during Planning
Traceability(1)

 Number of requirements
 The greater the number of requirements, the more the need for formal

traceability policies
 Expected system lifetime
 More comprehensive traceability policies should be defined for systems which

have a long lifetime

 Maturity level of organization
 Detailed traceability policies are more likely to be implemented and used

properly in a cost-effective way in organizations which have a higher level of

process maturity
 Size of project and team
 The larger the project or team, the greater the need for formal traceability

policies
 Factors to Consider during Planning (2)

 Type of system
 Critical systems such as hard real-time control systems or safety-critical

systems need more comprehensive traceability policies than non-critical

systems
 Additional constraints from customer
 E.g., compliance to military standard

 Traceability links should be defined by whoever has the appropriate

information available
 Modeling Traceability

The types of links to use (and their attributes) must be defined for different types
of requirements
 It is a design problem!

May be modeled with a UML class diagram (metamodel)

 Object types (classes)
 Object attributes (attributes)
 Structure of folders, modules, objects
 Stereotypes, composition…

 Link types (associations)

 Satisfies, tests, refines, contains, contributes to, threatens, justifies…

 Link attributes (association classes)

Other Example of Traceability Links

Business
requirement
modifies
Drives specification of

System requirements, influences

Change modifies
use case, external Business rule
request
interface, quality attribute

Is origin of Is origin of
modifies modifies
Software functional
Depends on another
requirement
Is satisfied by
Is verified by Lead to creation of
Architectrue, Project plan
user interface, or System test
task
functional design
Is verified by Is implemented in

Integration test Code

Is verified by

Unit test
 Cardinality of Traceability Links

 Depending on the traceability information, the cardinality of

traceability links may be
 One-to-one

 e.g., one design element to one code module

 One-to-many

 e.g., one functional requirement verified by multiple test cases

 Many-to-many

 e.g., a use case may lead to multiple functional requirement,

and a functional requirement may be common to several use
cases
 What you should Know!

 What is traceability?
 Why is traceability important?
 How is traceability performed?
 What tools perform traceability?
 What is the future of traceability?
194
Software
Engineering 1
Lesson 9a
Unified Modeling Language
(UML)

1. INTRODUCTION
 Overview

 What is UML?
 Understanding the basics of UML.
 UML diagrams
 UML Modeling tools
 Unified Modeling Language

 Unified Modeling Language (UML) is a standardized general-

purpose modeling language in the field of software
engineering.

 The standard is managed, and was created by, the Object

Management Group.

 UML includes a set of graphic notation techniques to create

visual models of software-intensive systems.
 Origins of UML
 In the 1980s, object-oriented programming moved from research labs into
the real world
 Smalltalk and C++ became popular languages and various people started
thinking about object-oriented graphical design languages
 Between 1988 and 1992, the key authors were Booch, Coad, Jacobson,
Odell, Rumbaugh, Shlaer, Mellor, and Wirfs-Brock
 Each author was informally leading a group of practitioners who liked those
ideas
 The same basic OO concepts would reappear in very different notations, causing
confusion with clients
 When Jim Rumbaugh left GE to join Grady Booch at Rational, an alliance
was formed and a critical mass of market share occurred
 In 1997, Rational released UML 1.0

197
 Origins of UML (continued)
 Consists of a family of graphical notations that help in
describing and designing software systems

 Focuses particularly on software systems built using the

object-oriented style

 Controlled by the Object Management Group, which is an

open consortium of companies

 Comes from the unification of many OO graphical modeling

languages that thrived in the 1980s and early 1990s
198
 What is UML?

 An Standard language for specifying, visualizing, constructing, and

documenting the artifacts of software systems, business modeling and
other non-software systems.

 The UML uses mostly graphical notations to express the OO analysis and
design of the software development process.

 Simplifies the complex process of software design and uses mostly

graphical notations to express the design of software projects.

 The UML represents a collection of best engineering practices that have

proven successful in the modeling of large and complex systems.

 Using the UML helps project teams communicate, explore potential

designs, and validate the architectural design of the software.
 Why UML for Modeling?

 A diagram/picture = thousands words

 Uses graphical notation to communicate more clearly than natural

language (imprecise) and code(too detailed).

 Makes it easier for programmers and software architects to communicate.

 Helps acquire an overall view of a system.

 UML is not dependent on any one language or technology.

 UML moves us from fragmentation to standardization.

Ways of using UML - As a Sketch

 Most common use of UML

 Used to help communicate some aspect of a system and to better

understand it

 Used for both forward engineering (i.e., build diagrams before coding)
and reverse engineering (i.e., build diagrams from existing code)

 Strives to be informal and dynamic

 Only emphasizes those classes, attributes, operations, and relationships

that are of interest

 More concerned with selective communication than complete

specification
201
 Ways of using UML - As a Blueprint

 Goal is completeness
 Is more definitive, while the sketch approach is more explorative
 Used to describe a detailed design for a programmer to follow in
writing source code
 Notation should be sufficiently complete so that a programmer can
follow it in a straightforward manner
 Can be used by a designer to develop blueprint-level models that
show interfaces of subsystems or classes
 Developers then work out the implementation details
 As a reversed engineered product, diagrams convey detailed
information about the source code that is easier for developers to
understand

202
 Ways of using UML - As a Programming
Language

 Specifies the complete system in UML so that code can be

automatically generated
 Looks at UML from a software perspective rather than a conceptual
perspective which concentrates on the domain of study
 Diagrams are compiled directly into executable code so that the UML
becomes the source code
 Challenge is making it more productive to use UML rather than some
another programming language
 Another concern is how to model behavioral logic
 Done with interaction diagrams, state diagrams, and activity diagrams

203
Understanding the Problem Domain

 System to be developed
 Actors
 Agents external to the system
 Concepts/ Objects
 Agents working inside the system
 Use Cases
 Scenarios for using the system

204
 Types of UML Diagrams
205

Diagram Name Purpose

Activity Models procedural and parallel behavior

Class Models classes, attributes, operations and relationships

Communication Models interaction between objects

Component Models structure and connection of components

Composite Structure Models runtime decomposition of a class

Deployment Models deployment of artifacts to nodes

Interaction overview Mixes the sequence and activity diagram

 Types of UML Diagrams (continued)
206

Diagram Name Purpose

Object Models example configurations of instances

Package Models compile-time hierarchical structure

Sequence Models sequence interaction between objects

State Machine Models how events change an object over its life

Timing Models timing interaction between objects

Use Case Models how users interact with a system

 Types of UML Diagrams

Use Case Diagram: capture requirements. Clarify exactly

what the system is supposed to do
Displays the relationship among actors and use cases.
Different from traditional flow chart.

Class Diagram: static relationships between classes.

Describe the types of objects in the system and various kinds
of static relationship that exist among them.

Sequence Diagram:
Displays the time sequence of the objects participating in the
interaction.
 Types of UML Diagrams (Cont.)

Collaboration Diagram
Displays an interaction organized around the objects and
their links to one another.
State Diagram
Displays the sequences of states that an object of an
interaction goes through during its life in response to
received stimuli, together with its responses and actions.

Component Diagram
Illustrate the organizations and dependencies of the
physical components in a system. A higher level than class
diagrams.
Types of UML Diagrams (Cont.)
 Composite structure diagram:
Describes the internal structure of a class and the collaborations
that this structure makes possible.
 Deployment diagram:
Describes the hardware used in system implementations and the
execution environments and artifacts deployed on the hardware.
 Object diagram:
Shows a complete or partial view of the structure of a modeled
system at a specific time.
 Package diagram:
Describes how a system is split up into logical groupings by
showing the dependencies among these groupings.
 Classification of Diagram Types

Class
Diagram
Component
Diagram
Structure Composite
Diagram Structure Diagram
Deployment
Diagram
Object
Diagram
Package
Diagram Diagram

Sequence
Use Case Diagram
Diagram
Behavior Communication
Activity Diagram
Diagram Diagram
Interaction
Interaction Overview
Diagram Diagram
State Machine Timing
Diagram Diagram 210
 Structure Diagrams

 Structure diagrams emphasize the things that must be present

in the system being modeled. Since structure diagrams
represent the structure they are used extensively in
documenting the architecture of software systems.

 Class diagram: describes the structure of a system by showing the

system's classes, their attributes, and the relationships among the
classes.

 Component diagram: describes how a software system is split up into

components and shows the dependencies among these components.
 Behavior Diagrams
 Behavior diagrams emphasize what must happen in the system being
modeled. Since behavior diagrams illustrate the behavior of a system, they
are used extensively to describe the functionality of software systems.

 Activity diagram: describes the business and operational step-by-step

workflows of components in a system. An activity diagram shows the overall
flow of control.

 UML state machine diagram: describes the states and state transitions of the
system.

 Use case diagram: describes the functionality provided by a system in terms of

actors, their goals represented as use cases, and any dependencies among those
use cases.
Types of UML Diagrams (Cont.)

Interaction Diagrams
 Interaction diagrams emphasize the flow of control and data
among the things in the system being modeled:

 Communication diagram: shows the interactions between objects or

parts in terms of sequenced messages. They represent a combination of
information taken from Class, Sequence, and Use Case Diagrams
describing both the static structure and dynamic behavior of a system.

 Interaction overview diagram: provides an overview in which the

nodes represent interaction diagrams.
Types of UML Diagrams (Cont.)

Interaction Diagrams
 Sequence diagram: shows how objects communicate with
each other in terms of a sequence of messages. Also
indicates the life spans of objects relative to those
messages.

 Timing diagrams: are a specific type of interaction diagram,

where the focus is on timing constraints.
 Fitting UML into
Software Requirements Analysis
 A use case diagram helps describe how people interact with the system

 An activity diagram shows the context for use cases and also the details
of how a complicated use case works

 A class diagram drawn from the conceptual perspective is a good way of

building up a rigorous vocabulary of the domain

 It also shows the attributes and operations of interest in domain classes and the
relationships among the classes

 A state diagram shows the various states of a domain class and events
that change that state

215
 Fitting UML into
Software Design
 A class diagram drawn from the software perspective can show
design classes, their attributes and operations, and their relationships
with the domain classes

 A sequence diagram helps to combine use cases in order to see what

happens in the software

 A package diagram shows the large-scale organization of the

software

 A state diagram shows the various states of a design object and events
that change that state

 A deployment diagram shows the physical layout of the software

216
 Fitting UML into
Software Documentation
 Complements the written documentation and in some instances can replace it

 Captures the outcome of the requirements analysis and design activities

 Supplies a software maintainer with an overall understanding of a system

 Provides a good logical roadmap of the system layout

 Describes the various states in which a system may exist

 Details complex algorithms in a more understandable form

 Shows how multiple objects collaborate in the system

217

 UML – Language of Symbols

UML = Unified Modeling Language «interface»

Stereotype
BaseInterface
«» provides
ClassName additional info/
+ operation()
annotation/
# attribute_1 : int explanation
Three common # attribute_2 : boolean
compartments: # attribute_3 : String
1. Classifier name Inheritance
+ operation_1() : void relationship:
+ operation_2() : String Class1Implement Class2Implement
2. Attributes BaseInterface
+ operation_3(arg1 : int) is implemented
+ operation() + operation()
3. Operations by two classes
Software Class
Actor Comment Software Interface Implementation

instance1 : Class1 instance5 : Class2 instance8 : Class3

doSomething()
doSomethingElse()

Interaction Diagram
doSomethingYetElse()
Online information:
http://www.uml.org
218
219
Software
Engineering 1
Lesson 9b
Unified Modeling Language
(UML)

2. ELEMENTS ,
RELATIONSHIPS &
Structural Modeling: Core Elements

Construct Description Syntax

class a description of a set of objects
that share the same attributes,
operations, methods, relationships
and semantics.
interface a named set of operations that
« in te rfa c e »
characterize the behavior of an
element.
component a modular, replaceable and
significant part of a system that
packages implementation and
exposes a set of interfaces.
node a run-time physical object that
represents a computational
resource.
 Structural Modeling: Core Elements
(cont’d)

Construct Description Syntax

constraint¹ a semantic condition or restriction.
{constraint}

¹ An extension mechanism useful for specifying structural elements.

Reference: OMG tutorial on UML by Cris Kobryn

 Structural Modeling: Core
Relationships

Construct Description Syntax

association a relationship between two or more
classifiers that involves connections
among their instances.
aggregation A special form of association that
specifies a whole-part relationship
between the aggregate (whole) and
the component part.
generalization a taxonomic relationship between a
more general and a more specific
element.
dependency a relationship between two modeling
elements, in which a change to one
modeling element (the independent
element) will affect the other modeling
element (the dependent element).
Structural Modeling: Core Relationships
(cont’d)

Construct Description Syntax

realization a relationship between a specification
and its implementation.
Structural Modeling: Core Elements

Construct Description Syntax

class a description of a set of objects
that share the same attributes,
operations, methods, relationships
and semantics.
interface a named set of operations that
characterize the behavior of an « in te rfa c e »

element.
component a modular, replaceable and
significant part of a system that
packages implementation and
exposes a set of interfaces.
node a run-time physical object that
represents a computational
resource.
Introduction to UML 224
Structural Modeling: Core Elements (cont’d)

Construct Description Syntax

constraint¹ a semantic condition or restriction.
{constraint}

¹ An extension mechanism useful for specifying structural elements.

Introduction to UML 225

Structural Modeling: Core Relationships
Construct Description Syntax
association a relationship between two or more
classifiers that involves connections
among their instances.
aggregation A special form of association that
specifies a whole-part relationship
between the aggregate (whole) and
the component part.
generalization a taxonomic relationship between a
more general and a more specific
element.
dependency a relationship between two modeling
elements, in which a change to one
modeling element (the independent
element) will affect the other modeling
element (the dependent element).

Introduction to UML 226

 Structural Modeling: Core Relationships (cont’d)

Construct Description Syntax

realization a relationship between a specification
and its implementation.

Introduction to UML 227

 Attribute

visibility name: type multiplicity = default {property-string}

 Example
+ criticalMsg: String [1] = "Error message" {readonly}
 Syntax
 Visibility marker: public (+) or private (-)
 Name: name of the attribute in the programming language
 Type: Type of the attribute in the programming language
 Multiplicity: how many objects fill the property
 Default: Default value of the attribute at instantiation
 {property-string}: additional properties of the attribute
 Describes a property as a line of text within the class box
 Used for representing value types
228
 Operation
visibility name (parameter-list) : return-type {property-string}
 Example: + computeTotal (account: Account) : float
 Syntax
 Visibility marker: public (+) or private (-)
 Name: name of the operation in the programming language
 Parameter-list: list of parameters passed to the operation
 Syntax: direction name : type = default-value
 Return-type: Type of the return value if there is one
 {property-string}: additional properties of the operation
 Portrays actions that a class knows to carry out
 Corresponds to the methods of a class
 Operations may be queries or modifiers; modifiers change the state of
any object
 Set and get operations are implied and therefore not shown
229
 Associations

 An Association represents a Job 

Company 
family of links employer employee Person

 Binary associations (with two Job boss

salary
ends) are normally represented 0..1
worker 
as a line, with each end
connected to a class box Manages

 Higher order associations can be Person

drawn with more than two ends;
{X or}
in such cases, the ends are Account
connected to a central diamond Corporation
 Association
 Represented by a solid line between two classes directed from the
source class to the target class
 Used for representing (i.e., pointing to) object types
 The name of the association goes at the target end of the association
together
 The target end of the association links to the class that is the type of
the property
 Multiplicities can be shown at both ends but are usually at the target
end
 Arrows may be bidirectional

Source 1..n Target

Name
231
Associations

Job 
Company 
employer employee Person

Job boss
salary
0..1
worker 

Manages

Person

{X or}
Account
Corporation

232
 Aggregation

 It is graphically represented as a hollow diamond shape on the

containing class end of the tree of lines that connect contained
class(es) to the containing class

 Aggregation is a variant of the "has a" or association relationship;

aggregation is more specific than association

 It is an association that represents a part-whole or part-of

relationship.
 Aggregation

 Aggregation can occur when a class is a collection or container of

other classes, but where the contained classes do not have a strong
life cycle dependency on the container

 Essentially, if the container is destroyed, its contents are not.

 As a type of association, an aggregation can be named and have the

same adornments that an association has.
 Composition

 The UML graphical representation of a composition relationship is a filled

diamond shape on the containing class end of the tree of lines that connect
contained class(es) to the containing class

 Composition is a stronger variant of the "owns a" or association relationship;

composition is more specific than aggregation

 Has a strong life cycle dependency between instances of the container class
and instances of the contained class(es)

 Normally if the container is destroyed, every instance that it contains is also

destroyed.
Composition

Window

scrollbar [2]: Slider

title: Header
body: Panel

Window
1
1 1

scrollbar 2 title 1 body 1

Slider Header Panel

Introduction to UML 236

 Aggregation and Composition
 Aggregation and composition are sometimes viewed as special types of
associations and have the symbol of a diamond at the source end of a line
 Aggregation is a part-of relationship
 Composition is more restrictive than aggregation
 The diamond is filled in (i.e. shaded)
 The part pointed to does not continue to exist without the whole

+vertex
1 3..
Contains
Polygon Point
{ordered}
1
GraphicsBundle
1
-bundle color
texture
density
237
 Aggregation vs. Composition
Composition Aggregations
Is a strong form of aggregation Less rigorous than a composition.
Must be an essential part to the May form "part of" the aggregate, but
Composition may not be essential to it.
Components cannot exist independent of They may also exist independent of the
their owner; both have coincident aggregate.
lifetimes

Components have only one owner Components may have many owners
e.g. (1)Each car has an engine that can e.g. (1)Apples may exist independent of
not be shared with other cars. the bag.
(2) If the polygon is destroyed, so are (2)An order is made up of several
the points. products, but the products are still
there even if an order is cancelled.
 Generalization (Kind-of)
 Indicates that one of the two related classes (the subtype) is
considered to be a specialized form of the other (the super
type)
 A supertype is considered a 'Generalization' of subtype

 In practice, this means that any instance of the subtype is

also an instance of the supertype

 The relationship is most easily understood by the phrase 'A

is a B' (a human is a mammal, a mammal is an animal).
 Generalization

 The generalization relationship is also known as the

inheritance or "is a" relationship.

 The supertype in the generalization relationship is also

known as the "parent", superclass, base class, or base
type.

 The subtype in the specialization relationship is also

known as the "child", subclass, derived class, derived
type, inheriting class, or inheriting type.
 Generalization
 Note that this relationship bears no resemblance to the
biological parent/child relationship: the use of these terms
is extremely common, but can be misleading

 Generalization-Specialization relationship

 A is a type of B
 E. g. "an oak is a type of tree", "an automobile is a type
of vehicle"

 Generalization can only be shown on class diagrams and on

Use case diagrams.
 Generalization
 Portrays inheritance between a super class and a subclass
 Is represented by a line with a triangle at the target end as shown below

Super class

Subclass Subclass

242
Generalization (Kind
of)
Shape

Separate Target Style

Polygon Ellipse Spline . ..

Shape
Shared Target Style

...
Polygon Ellipse Spline

243
 Generalization

Vehicle

power venue
power venue
{overlapping} {overlapping}

WindPowered MotorPowered Land Water

Vehicle Vehicle Vehicle Vehicle

Truck Sailboat

Introduction to UML 244

 Dependency
 A dependency exists between two elements if changes to the definition of
one element (i.e., the source or supplier) may cause changes to the other
element (i.e., the client)

 Examples
 One class sends a message to another class
 One class mentions another as a parameter to an operation

 Once a dependency is created, if a class changes its interface, any

message sent to that class may no longer be valid
 A general rule is to minimize dependencies and be wary of cycles
Class Class

245
 Dependencies
ClassA ClassB ClassD
«friend»
«friend»
operationZ()
«instantiate»

«call» ClassC

«refine»
ClassC combines
two logical classes

ClassD ClassE

 Dependency is a weaker form of relationship which indicates that one

class depends on another because it uses it at some point of time
 It exists if a class is a parameter variable or local variable of a method of
another class
Dependencies

ClassA ClassB ClassD

«friend»
«friend»
operationZ()
«instantiate»

«call» ClassC

«refine»
ClassC combines
two logical classes

ClassD ClassE

Introduction to UML 247

Dependencies

Controller
«access»
«access»
«access» Diagram
Elements
«access»
«access»

Domain Graphics
Elements Core

Introduction to UML 248

 Constraints and Comments
 Member-of 
Person {subset} Committee Represents
an incorporated entity.
1 Chair-of 

employee employer
  0..1
Person Company
0..1
boss

{Person.employer =
Person.boss.employer}

Introduction to UML 249

250
Software
Engineering 1
Lesson 9c
Unified Modeling Language
(UML)

3. USE CASE DIAGRAM

Use Case
 use case is a description of a system’s behavior as it responds
to a request that originates from outside of that system.

 it describes "who" can do "what" with the system in question

 use case model presents a view of the system that emphasizes

behavior as it appears to outside users.

 A use case model partitions system functionality into

transactions (‘use cases’) meaningful to users (‘actors’).
 Use Case Diagram

 Use cases serve as a technique for capturing the functional

requirements of a system
 Describes the typical interactions between the users of a system and
the system itself, providing a narrative of how a system is used
 A use case consists of a set of one or more scenarios tied together by a
common user goal
 A scenario is a sequence of steps describing an interaction between a
user and a system; some scenarios describe successful interaction;
others describe failure or errors
 Users are referred to as actors; an actor is a role that carries out a use
case
 An actor need not always be a person; it can also be an external system
that is either automated or manual

252
Use Case Diagram
 A use case diagram
 Is a type of behavioral diagram defined by and created from
a Use-case analysis.

 Its purpose is to present a graphical overview of the

functionality provided by a system in terms of actors, their
goals (represented as use cases), and any dependencies
between those use cases.

 The main purpose

 to show what system functions are performed for which
actor.
 Roles of the actors in the system can be depicted.
Use Case Modeling: Core
Elements

Construct Description Syntax

use case A sequence of actions, including
variants, that a system (or other UseC aseNam e
entity) can perform, interacting with
actors of the system.
actor A coherent set of roles that users
of use cases play when interacting
with these use cases.
A ctorN am e

system Represents the boundary between

boundary the physical system and the actors
who interact with the physical
system.

Introduction to UML 254

 Use Case Modeling: Core
Relationships

Construct Description Syntax

association The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.
extend A relationship from an extension use
case to a base use case, specifying
how the behavior for the extension
use case can be inserted into the <<extend>>
behavior defined for the base use
case.

Introduction to UML 255

 Use Case Modeling: Core Relationships (cont’d)

Construct Description Syntax

include An relationship from a base use case
to an inclusion use case, specifying <<include>>
how the behavior for the inclusion use
case is inserted into the behavior
defined for the base use case.

Introduction to UML 256

 Use Case Diagram(core components)

Actors: A role that a user plays with respect to the system,. e.g.,
humans, an external system that needs information from current system.

Use case: A set of scenarios that describe an interaction between a

user and a system.

 A use case diagram is a graphical table of contents of the use cases for a
system . It shows the use cases, the actors, and their relationships

 Use cases have no correlation to the classes in the system and can serve as
a starting point for writing software validation test cases
 Use Case Diagram(core relationship)

Association: communication between an actor and a use case;

represented by a solid line.

Generalization: relationship between one general use case and

one specific use case.

Represented by a line with a triangular arrow head toward the

parent use case, the more general modeling element.

employee
waitress
Use cases diagram
Use Case Diagram

Telephone Catalog

Check
status

Place Salesperson
order

F ill orders

Customer Shipping Clerk

Establish
credit

Supervisor

Introduction to UML 260

Use Case Diagram(core relationship)

Include: a dotted line labeled <<include>> beginning at base use

case and ending with an arrows pointing to the include use case.
An “Include” relationship is used to indicate that a particular Use Case
must include another use case to perform its function.
<<include>>

or in MS Visio <<uses>>

Example: the <list orders> Use Case may be included

every time when the <modify order> Use Case is run.
Use Case Relationships

Supply Order
Customer Data Product Arrange
Payment

«include» «include» «include»

Place Order

Extension points «extend»

1 * additional requests : the salesperson asks for
after creation of the order the catalog

Request
Catalog

Introduction to UML 262

 Use Case Diagram (core relationship)

 Extend: a dotted line labeled <<extend>> with an arrow toward the base
case.

The extending use case may add behavior to the base use case. The base class
declares “extension points”.
<<extend>>

Used when exceptional circumstances are encountered. For example, the <get
approval> Use Case may optionally extend the regular <modify order> Use
Case.
Note: other expressions. For example, in MS Visio
<<uses>> <<extends>>
Use Case Diagrams(cont.)
 Use Case Diagrams

Boundary Use Case

Actor
Library System

Borrow
Employee
Client

Order Title

Fine Remittance

Supervisor

• A generalized description of how a system will be used.

• Provides an overview of the intended functionality of the system
Use Case Diagram
Use cases diagram
Use cases diagram
 Example Use Case Diagram

Make automated menu

selections Expert Menu
System

Order food and drink

Cook
Notify customer that
food and drink are ready
Customer

Pay for food and drink Payment

System
Actor Relationships

1 * Place
Order
Salesperson

Establish
1 *
Credit
Supervisor
Introduction to UML 270
Example: Use Case Description: Change
Flight

Actors: traveler, client account db, airline reservation system

Preconditions:
· Traveler has logged on to the system and selected ‘change
flight itinerary’ option
Basic course
· System retrieves traveler’s account and flight itinerary from
client account database
· System asks traveler to select itinerary segment she wants to
change; traveler selects itinerary segment.
· System asks traveler for new departure and destination
information; traveler provides information.
· If flights are available then
· System displays transaction summary.
Alternative courses
· If no flights are available then

271
Example: Online HR System: Update Benefits Use
Case

Actors: employee, employee account db, healthcare plan system,

insurance plan system

Preconditions:
· Employee has logged on to the system and selected ‘update
benefits’ option
Basic course
· System retrieves employee account from employee account db
· System asks employee to select medical plan type; include
Update Medical Plan.
· System asks employee to select dental plan type; include Update
Dental Plan.
Alternative courses
· If health plan is not available in the employee’s area the employee
is informed and asked to select another plan...

272
Online HR System: Use Case Relationships

U pdate M edical U pdate D ental

U pdate
P lan P lan
Insurance P lan

<<include>> <<include>> <<include>>

Update Benefits
______________
E xtension points extension point
benefit o ptions: nam e and
after required enrollm ents location
E m ployee

<<extend>> <<extend>>
em ployee requests em ployee requests
reim bursem ent option stock purchase option

E lect
E lect S tock
R eim bursem ent extension
P urchase
for H ealthcare condition

Introduction to UML 273

Example: Online HR System

O n lin e H R S ys te m

L o c a te
E m p lo ye e s

U p d a te
E m p lo ye e M anager
P ro file

{if c u rre n tM o n th = O c t.}

U p d a te B e n e fits

E m p lo ye e H e a lth c a re P la n S ys te m

Ac c e s s T ra v e l
{re a d O n ly}
S ys te m

Ac c e s s P a y In s u ra n c e P la n S ys te m
R e c o rd s

Introduction to UML 274

 When to model use cases

 Model user requirements with use cases.

 Model test scenarios with use cases.

 If you are using a use-case driven method

 start with use cases and derive your structural and
behavioral models from it.

 If you are not using a use-case driven method

 make sure that your use cases are consistent with
your structural and behavioral models.
275
 Use Case Modeling Tips
 Make sure that each use case describes a significant chunk of system usage
that is understandable by both domain experts and programmers

 When defining use cases in text, use nouns and verbs accurately and
consistently to help derive objects and messages for interaction diagrams

 Factor out common usages that are required by multiple use cases
 If the usage is required use <<include>>
 If the base use case is complete and usage is optional, consider use <<extend>>

 A use case diagram should

 contain only use cases at the same level of abstraction
 include only actors who are required

 Large numbers of use cases should be organized into packages

276
277
Software
Engineering 1
Lesson 9d
Unified Modeling Language
(UML)

4. ACTIVITY DIAGRAM
 Activity Diagram
 Serves as a technique to describe procedural logic, business
process logic, and work flow

 Is similar to a flowchart except that it can also show parallel

behavior

 States the essential sequencing rules to follow, thereby

allowing concurrent algorithms to be used
 Consequently, an activity diagram allows whoever is
doing the process to choose the order in which to do
certain things

 Can be used to describe the actions in a use case

278
Example Activity Diagram

Set counter = positive n

Set accumulator = initial value

F
n>1
T
Set accumulator = accumulator * n
Set n = n - 1

F (n mod 5) == 0

T
Display accumulator value

Return accumulator value 279

Activity diagram
UML 2 Activity diagrams
 It helps to describe the flow of control of the
target system, such as the exploring complex
business rules and operations, describing the use
case also the business process.

 It is object-oriented equivalent of flow charts

and data-flow diagrams (DFDs).
Activity diagram
Activity diagram
 Activity Diagram
Start
Fork Activity diagrams describe the
workflow behaviour of a system

Branch

Joint
283
Merge
End
Activity Diagram [Modeling System Workflows]
Initial
node
Select
“Unlock”

Enter Key
Action
Decision
Verify Key

[authorized] [not authorized]

Signal
Success
Notify
Intrusion
Open Lock &
Lit Light
Sound Alarm

Start Autolock
Timer

Activity
Merge
final node
285
Software
Engineering 1
Lesson 9e
Unified Modeling Language
(UML)

5. CLASS DIAGRAM
Class diagram
UML class diagrams
Show the classes of the system, their inter-
relationships, and the operations and attributes of the
classes
 Explore domain concepts in the form of a domain model

 Analyze requirements in the form of a conceptual/analysis

model

 Depict the detailed design of object-oriented or object-

based software
 Class Diagrams

In the diagram these classes are represented with boxes

which contain three parts

 A class with three sections.

 The upper part holds the name of the class

 The middle part contains the attributes of the class

 The bottom part gives the methods or operations the class

can take or undertake
 Class Diagram

 Each class is represented by a rectangle subdivided into three

compartments
 Name
 Attributes
 Operations

 Modifiers are used to indicate visibility of attributes and operations.

 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (friends and derived)
 ‘-’ is used to denote Private visibility (no one)

 By default, attributes are hidden and operations are visible.

 The last two compartments may be omitted to simplify the class
diagrams
 The class icon and steps

 Defines
 Persistent system state
 System behavior
 The class icon has
 Name
 Attributes
 Operations
 It’s a rectangle divided into  Draw class symbol in the editor and name
it
three compartments.
 List the class attributes
 List the class operations/methods
 Make the links and associations
 Give notations
 Class Diagram
 Describes the types of objects in the system and the various kinds of
static relationships that exist among them

 Also shows the properties and operations of a class and the constraints
that apply to the way objects are connected

 A class box has three parts:

 Name of the class
 Attributes of the class
 Operations of the class

 Properties represent structural features of a class and consist of

attributes and associations
290
Example: Classes
Window
{abstract,
Window author=Joe,
status=tested}
+size: Area = (100,100)
#visibility: Boolean = true
Window +default-size: Rectangle
#maximum-size: Rectangle
-xptr: XWindow*
size: Area
visibility: Boolean
+display ()
+hide ()
display ()
hide () +create ()
-attachXWindow(xwin:Xwindow*)

291
Classes: Compartments with names

Reservation

operations
guarantee()
cancel ()
change (newDate: Date)
responsibilities
bill no-shows
match to available rooms

exceptions
invalid credit card

292
Classes: method body

PoliceStation

alert (Alarm)
1 station

BurglarAlarm

isTripped: Boolean = false

report () { if isTripped
then station.alert(self)}

293
Types and Implementation Classes

«type» «implementationClass»
Object HashTable

* elements 1 body

«type» «implementationClass»
Set HashTableSet
addElement(Object)
removeElement(Object) addElement(Object)
testElement(Object):Boolean removeElement(Object)
testElement(Object):Boolean
setTableSize(Integer)

294
 Notation of Class Diagram: association

Associations represent relationships between instances of classes .

An association is a link connecting two classes.

 Bi-directional association
Associations are assumed to be bi-directional
e.g. Flight and plane
notation:

 Uni-directional association
e.g. Order and item
notation:
 Association: Multiplicity and Roles

student

1 *

University Person

0..1 *

employer teacher
Multiplicity Role
Symbol Meaning “A given university groups many people;
1 One and only one some act as students, others as teachers.
0..1 Zero or one A given student belongs to a single
M..N From M to N (natural university; a given teacher may or may
language) not be working for the university at a
* From zero to any positive
particular time.”
integer
0..* From zero to any positive
integer
1..* From one to any positive
integer
 Notation of Class Diagram: Generalization

Example: Customer
Supertype

Regular Loyalty
Customer Customer

Subtype1 Subtype2 or:

Customer

Generalization expresses a relationship

among related classes. It is a class that
includes its subclasses.
Regular Loyalty
Customer Customer
 Notation of Class Diagram: Composition

COMPOSITION
Whole Class Composition:
Class W
It expresses a relationship where an instance of the
Whole-class has the responsibility to create and
initialize instances of each Part-class.
Class P1 Class P2
Instances of the Whole-class has exclusive access to
Part Classes
control of instances of the Part-classes.

Example
Used to express a relationship where the behavior of
Part instances is undefined without being related to
Automobile an instance of the Whole.

And, conversely, the behavior of the Whole is ill-

defined or incomplete if one or more of the Part
Engine Transmission instances are undefined.
 Notation of Class Diagram: Aggregation

Container Class Aggregation:

Class C
Expresses a relationship among instances of related
AGGREGATION classes.

It is a specific kind of Container- Containee relationship.

Class E1 Class E2

Aggregation should be used to express a more informal

Containee Classes relationship than composition expresses.

That is, it is an appropriate relationship where the

Example Container and its Containees can be manipulated
Bag independently.

Aggregation is appropriate when Container and Containees

have no special access privileges to each other.
Apples Milk
Class diagram
Class diagram
UML Class Diagram Examples 1
UML Class Diagram Examples 2
UML Class Diagram Examples 3
UML Class Diagram Examples 4
UML Class Diagram Examples 5
UML Class Diagram Examples 6
 Class Diagram example 7

Name Order class

-dateReceived
Multiplicity: mandatory
Attributes -isPrepaid Customer
-number :String
-price : Money
* 1 -name
-address
+dispatch() Association +creditRating() : String()
Operations +close()

1
{if Order.customer.creditRating is Generalization
"poor", then Order.isPrepaid must
be true }

Corporate Customer Personal Customer

-contactName -creditCard#
Constraint -creditRating
-creditLimit
Multiplicity: (inside braces{}}
+remind()
+billForMonth(Integer)
Many value
Multiplicity: *
optional 0..1
Employee
*
OrderLine
-quantity: Integer 1
-price: Money * Product
-isSatisfied: Boolean
Class Diagram Example 8
C re d itC a rd
P M C re d itC a rd
{a b s tra c t}

O rd e rB e a n
< < in te rfa c e > > {a b s tra c t}
E n tityB e a n
+ g e tO rd e rS ta tu s
+ s e tO rd e rS ta tu s
P M O rd e r
+ g e tL in e Ite m s
+ s e tL in e Ite m s
o rd e r + g e tC re d itA p p ro ve d
+ s e tC re d itA p p ro ve d
* ...

1 o rd e r

b u ye r 1 * ite m

C u s to m e r L in e Ite m
P M L in e Ite m
{a b s tra c t}
*
* ite m

1 c o m m o d ity

P ro d u c t

309
 Class Diagram Example 9

Accountant Auditor Record

Keeper

Input Production Transaction

Verifier Manager Processor

Report
Error Log Input Handler Generator Account Account List

1..n

Local File Remote File Accounts Accounts

Handler Handler Receivable Payable

310
 When to Use Class Diagrams
 Class diagrams are the backbone of UML and are the most
used diagrams

 Normally use only a subset of the notations available: class

box, attributes, operations, association, aggregation, and
generalization

 Class diagrams only model software structure; consequently,

it is easy to get too focused on class diagrams and ignore
behavior
 Use a state diagram to model the behavior of a class
 Use a sequence diagram to model interactions (i.e.,
behavior) among objects of various classes

311
312
Software
Engineering 1
Lesson 9f
Unified Modeling Language
(UML)

6. SEQUENCE DIAGRAM
 Sequence Diagram: Object interaction

A B

Occurs at the same Synchronous

Does not occurs at the same Asynchronous

Condition: indicates when a message Transmission

is sent. The message is sent only if the delayed
condition is true.
Condition [condition] remove()

Iteration *[for each] remove()

Self-Call: A message that an
Object sends to itself.
Self-Call
 Sequence Diagram
Us er Message Catalog Res ervations
Sequence diagrams demonstrate the
behavior of objects in a use case
1: look up ()

2: title data ()
By describing the objects and the
messages they pass. 3: [not available] res erve title ()

4 : title returned ()
The horizontal dimension shows the
objects participating in the 5: hold title ()
interaction.
5 : title available ()

The vertical arrangement of 6 : borrow title ()

messages indicates their order.

6 : rem ove res ervation ()

The labels may contain the seq. # to

indicate concurrency.
 Sequence Diagram
 Captures the behavior of a single scenario in a use case

 Shows a number of example objects and messages that are passed between
those objects within the use case

 The columns of the diagram represent each object involved in the use case

 The life time of an object progresses from the top of the diagram to the bottom

 Clearly illustrates the calls between participants and the sequence of those calls

 Gives a good picture about which participants are doing which processing

315
 Sequence Diagram (continued)

 When to use a sequence diagram

Use a sequence diagram when you want to look at the behavior of several
objects within a single use case

 When not to use a sequence diagram

 If you want to look at the behavior of a single object across many use
cases, use a state diagram
 If you want to look at the behavior of several objects across many
scenarios, use an activity diagram

316
 Sequence Diagram
Object: Class

 A sequence diagram is
 An interaction diagram that
details how operations are
carried out.
 What messages are sent and
when.
 Sequence diagrams are
organized according to time

Message

Lifeline
Operations

317
Sequence diagram
 UML 2 Sequence diagrams models the collaboration of objects based on
a time sequence. It shows how the objects interact with others in a
particular scenario of a use case.
319
Software
Engineering 1
Lesson 9h
Unified Modeling Language
(UML)

7. INTERACTION
DIAGRAM
Interaction overview diagram
 UML 2 Interaction overview diagrams focuses
on the overview of the flow of control of the
interactions.

 It is a variant of the Activity Diagram where the

nodes are the interactions or interaction
occurrences.

 It describes the interactions where messages and

lifelines are hidden.
 Interaction Diagrams: Collaboration diagrams

 Shows the relationship between objects start

and the order of messages passed
between them.

6: remove reservation
 The objects are listed as rectangles and
arrows indicate the messages being User
3 : [not available] reserve title
Reservations
passed.
5: title available
6 : borrow title
 The numbers next to the messages are 1: look up
2: title data
called sequence numbers. They show
the sequence of the messages as they
are passed between the objects.
4 : title returned
Catalog
 Convey the same information as
sequence diagrams, but focus on object 5 : hold title
roles instead of the time sequence.
 Interfaces: Shorthand Notation

S to re H o m e Store

P O S te rm in a lH o m e -sto re Id : In te g e r
-P O S list: L ist
POSterm inal <<use>> + cre a te ()
+ lo g in (U se rN a m e , P a s sw d )
P O S te rm in a l + fin d (S to re Id )
+ g e tP O S to ta ls (P O S id )
+ u p d a te S to re T o ta ls(Id ,S a le s)
S to re
+ g e t(Ite m )

322
 Interfaces: Longhand Notation

S toreH om e S tore

P O S term inalHom e -storeId: Integer

-P O S list: List

P O S term inal +create()

<<use>> <<interface>> +login(U serN am e, P asswd)
P O S term inal S tore +find(S toreId)
+getP O S totals(P O S id)
+getP O S totals(P O S id) +updateS toreTotals(Id,S ales)
+updateS toreTotals(Id,S ales) +get(Item )
+get(Item )

323
Interaction overview diagram
Interaction Diagram [Door access]
326
Software
Engineering 1
Lesson 9i
Unified Modeling Language
(UML)

8. STATE DIAGRAM
 State Diagrams
(Billing Example)

State Diagrams show the sequences of states

an object goes through during its life cycle
in response to stimuli, together with its
responses and actions; an abstraction of all
possible behaviors.

Start End
Unpaid Paid
Invoice created payin Invoice destroying
g
 Basic rules for State Diagrams

 Draw only one object's chart at a time.

 A state is drawn as a box with rounded corners.

 From each state draw an arrow to another state if the object can
change from one to the other in one step.

 Label the arrow with the event that causes it.

 Show the initial state by drawing an arrow from a black filled circle
to the initial state.

 Show the end state by drawing an arrow to a circle with a filled

circle inside it.
 State Diagrams
(Traffic light example)

Traffic Light Start

State
Transition Red

Yellow

Green

Event
 State Diagrams
(Traffic light example)

Traffic Light Start

State
Transition Red
100

Yellow
011

Event Expiry
Green
001
 State Machine Diagram
 Commonly called a state diagram
 A state diagram describes the behavior of a system
 In object-oriented technology, a state diagram shows the lifetime behavior
of a single object
 A state diagram captures the behavior of a state across several use cases
 A state diagram consists of states and transitions
 Note that a state diagram is NOT a set of processes connected by lines
representing data input and output
 A state is characterized by the current values of an object's attributes and
its name reflects some ongoing activity or state
 A transition indicates a movement from one state to another because an
event has occurred; this transition changes one or more attribute values of
the class

331
State machine diagram
State machine diagram
 Activity State
 In some states, an object is inactive as it waits for the next
event before it does something

 In an activity state, the object is doing some ongoing work

 The work may take a finite amount of time

 A transition from the state cannot occur until the work is

done
 This is represented by "do/ activity" notation in the state

box

334
335
Software
Engineering 1
Lesson 9j
Unified Modeling Language
(UML)

9. COMPONENT DIAGRAM
Component diagram
Shows the dependencies among software components,
including the classifiers that specify them (for example
implementation classes) and the artifacts that implement
them;

Example
such as
 source code files,
 binary code files,
 executable files,
 scripts and tables.
 Component Diagram

 Illustrate the organizations and dependencies of the physical

components in a system.

 Has a higher level of abstraction than a Class diagram -

usually implemented by one or more classes.

Symbols and Notations

Components
a large rectangle with two smaller rectangles on the side.
 Component Diagram (cont.)

Interface
An interface describes a group of operations used or
created by components. It represents a declaration of a set
of coherent public features and obligations, similar to a
contract.

Dependencies

dashed arrows.
 Component Diagram (cont.)

order

customer

account

Order provides a component interface, which is a collection of one

or more methods with or without attributes.

Account and customer components are dependent upon the

interface of the order.
 Component Diagram

 Shows the organizations and dependencies

among software components

 Components may be
 specified by classifiers (e.g., implementation
classes)
 implemented by artifacts (e.g., binary, executable,
or script files)

340
Components

S h o p p in g S e s s io n H o m e

<<S ession >>

S h opp in gS ession
S h o p p in g S e s s io n

<<E ntity>>
030303zak:O rder

O rd e rP K
<<au xiliary>>
O rd e rH o m e :O rderP K
O rd e rH o m e
<<fo cus>>
:O rder
O rd e rIn fo
O rd e r <<au xiliary>>
:O rderInfo
O rd e r

341
 Component Diagram

S hoppingS essionH om e

<<E JB S ession>>
S hoppingS ession S hoppingS ession

<<E JB E ntity>>
C atalog

C atalogP K
<<auxiliary>>
C atalogP K
C atalogHom e C atalogHom e

<<focus>>
C atalog
C atalogInfo
C atalog <<auxiliary>>
C atalogInfo

C atalog

<<file>>
C atalogJAR

S hoppingC artHom e

S hoppingC art
<<E JB E ntity>>
S hoppingCart

342
Component diagram
Component Diagram with Relationships

<<auxiliary>> <<focus>> <<auxiliary>>

C atalogInfo C atalog C atalogPK

< < re s id e > > < < re s id e > > < < re s id e > >

<<ejbEntity>>
C atalog

< < im p le m e n t> >

<<file>>
C atalogJAR

344
345
Software
Engineering 1
Lesson 9k
Unified Modeling Language
(UML)

10. DEPLOYMENT DIAGRAM

Deployment diagram

UML deployment diagram depicts a static view of the

run-time configuration of hardware nodes and the
software components that run on those nodes.

Deployment diagrams show the hardware for your

system, the software that is installed on that
hardware, and the middleware used to connect the
disparate machines to one another.
 Deployment Diagram (1/2)

:Client

<<brow ser>>
:O penS ourceBrow ser

videoStoreServer:AppServer
<<Container>>
V ideoS toreApplication

<<S ession>> <<E ntity>>

S hoppingS ession Catalog
<<Focus>> <<Focus>>
S hoppingS ession Catalog

<<E ntity>>
S hoppingCart
<<Focus>>
S hoppingCart

:DBServer
<<database>>
:V ideoS toreDB

347
Deployment Diagram (2/2)

p rim aryS erver:Ap p S erver

< < d atab ase> >

:Acco u n tsD B
:Q u o teS ervice

p rim aryB ro ker

:B o n d B ro ker

<<becom e>>

b acku p S erver:Ap p S erver

b acku p B ro ker
:B o n d B ro ker

< < d atab ase> >

:Q u o teS ervice
:Acco u n tsD B

348
Deployment diagram
Deployment diagram
 Implementation Diagrams

 Show aspects of model implementation,

including source code structure and run-
time implementation structure

 Kinds
 component diagram
 deployment diagram

351
352
Software
Engineering 1
Lesson 9l
Unified Modeling Language
(UML)

11. MODELING TOOLS &

REFERENCES
 UML Modeling Tools

 Rational Rose (www.rational.com) by IBM

 UML Studio 7.1 ( http://www.pragsoft.com/) by Pragsoft Corporation

Capable of handling very large models (tens of thousands of
classes). Educational License US$ 125.00; Freeware version.

 Microsoft Visio
 Dia: open source, much like visio. (
http://www.gnome.org/projects/dia/)

 ArgoUML (Open Source; written in java )

(http://www.apple.com/downloads/macosx/development_tools/argo
uml.html )

 Others
(http://www.objectsbydesign.com/tools/umltools_byCompany.html )
Microsoft Visio
UML studio 7.1
Poor Design, need more heuristics!
A cleaner design
 Reference
1. UML Distilled: A Brief Guide to the Standard Object Modeling
Language Martin Fowler, Kendall Scott

2. Practical UML --- A Hands-On Introduction for Developers

http://www.togethersoft.com/services/practical_guides/um
lonlinecourse/

3. OO Concepts in UML. Dr. David A. Workman, School of EE

and CS. UCF.

4. Software Engineering Principles and Practice. Second

Edition; Hans van Vliet.
 References
 [UML 1.3] OMG UML Specification v. 1.3, OMG doc# ad/06-08-99
 [UML 1.4] OMG UML Specification v. 1.4, UML Revision Task Force
recommended final draft, OMG doc# ad/01-02-13.
 [Kobryn 01a] C. Kobryn, “UML 2.0 Roadmap: Fast Track or Detours?,”
Software Development, April 2001. To appear.
 [Kobryn 01b] C. Kobryn, “Modeling Distributed Applications with UML,”
chapter in [Siegel 01] Quick CORBA 3, Wiley, 2001. To be published.
 [Kobryn 00] “Modeling CORBA Applications with UML,” chapter 21 in
[Siegel 00] CORBA 3 Fundamentals and Programming (2nd ed.), Wiley, 2000.
 [Kobryn 99] UML 2001: A Standardization Odyssey, Communications of the
ACM, Oct. 1999.
 [EJB 2.0] Enterprise JavaBeans Specification v. 2.0, Sun Microsystems,
March 31, 2000.

359
360
Software
Engineering 1
Lesson 10
Database Fundamentals
Introduction to SQL
Systems Development Database
Life Cycle Development Process
Project Identification Enterprise modeling
and Selection
Project Initiation
and Planning Conceptual data modeling
Analysis

Logical Design Logical database design

Physical database design

Physical Design
and definition
Implementation Database implementation

Maintenance Database maintenance

361
Part Four: Implementation
 Chapter 7 – Introduction to SQL
 Chapter 8 – Advanced SQL
 Chapter 9 – Client/Server Environment
 Chapter 10 – Internet
 Chapter 11 – Data Warehousing

362
Overview
 Define a database using SQL data definition
language
 Work with Views
 Write single table queries
 Establish referential integrity

363
SQL Overview
 Structured Query Language
 The standard for relational database management
systems (RDBMS)
 SQL-92 and SQL-99 Standards – Purpose:
 Specify syntax/semantics for data definition and
manipulation
 Define data structures
 Enable portability
 Specify minimal (level 1) and complete (level 2)
standards
 Allow for later growth/enhancement to standard

364
365
SQL Environment
 Catalog
 A set of schemas that constitute the description of a database
 Schema
 The structure that contains descriptions of objects created by a
user (base tables, views, constraints)
 Data Definition Language (DDL)
 Commands that define a database, including creating, altering,
and dropping tables and establishing constraints
 Data Manipulation Language (DML)
 Commands that maintain and query a database
 Data Control Language (DCL)
 Commands that control a database, including administering
privileges and committing data
366
SQL Data types
(from Oracle 9i)
 String types
 CHAR(n) – fixed-length character data, n characters long
Maximum length = 2000 bytes
 VARCHAR2(n) – variable length character data, maximum 4000
bytes
 LONG – variable-length character data, up to 4GB. Maximum 1
per table
 Numeric types
 NUMBER(p,q) – general purpose numeric data type
 INTEGER(p) – signed integer, p digits wide
 FLOAT(p) – floating point in scientific notation with p binary digits
precision
 Date/time type
 DATE – fixed-length date/time in dd-mm-yy form
367
368
SQL Database Definition
 Data Definition Language (DDL)
 Major CREATE statements:
 CREATE SCHEMA – defines a portion of the database
owned by a particular user
 CREATE TABLE – defines a table and its columns
 CREATE VIEW – defines a logical table from one or
more views
 Other CREATE statements: CHARACTER SET,
COLLATION, TRANSLATION, ASSERTION,
DOMAIN

369
The following slides create tables for this
enterprise data model

370
Relational Data Model

371
Create PRODUCT table
Non-nullable specification
Primary keys
can never have
NULL values

Identifying primary key

372
 Non-nullable specifications

Primary key

Some primary keys are composite –

composed of multiple attributes

373
Controlling the values in attributes
Default value

Domain constraint

374
Identifying foreign keys and establishing relationships

Primary key of
parent table

Foreign key of
dependent table

375
Data Integrity Controls
 Referential integrity – constraint that ensures
that foreign key values of a table must match
primary key values of a related table in 1:M
relationships
 Restricting:
 Deletes of primary records
 Updates of primary records
 Inserts of dependent records

376
377
 Using and Defining Views
 Views provide users controlled access to tables
 Base Table – table containing the raw data
 Dynamic View
 A “virtual table” created dynamically upon request by a user
 No data actually stored; instead data from base table made available
to user
 Based on SQL SELECT statement on base tables or other views
 Materialized View
 Copy or replication of data
 Data actually stored
 Must be refreshed periodically to match the corresponding base
tables

378
 Sample CREATE VIEW
CREATE VIEW EXPENSIVE_STUFF_V AS
SELECT PRODUCT_ID, PRODUCT_NAME, UNIT_PRICE
FROM PRODUCT_T
WHERE UNIT_PRICE >300
WITH CHECK_OPTION;

View has a name

View is based on a SELECT statement
CHECK_OPTION works only for
updateable views and prevents updates that
would create rows not included in the view
379
Advantages of Views
 Simplify query commands
 Assist with data security (but don't rely on views for
security, there are more important security measures)
 Enhance programming productivity
 Contain most current base table data
 Use little storage space
 Provide customized view for user
 Establish physical data independence

380
Disadvantages of Views
 Use processing time each time view is referenced
 May or may not be directly updateable

381
Create Four Views
CREATE VIEW CUSTOMER_V AS SELECT * FROM CUSTOMER_T;

CREATE VIEW ORDER_V AS SELECT * FROM ORDER_T;

CREATE VIEW ORDER_LINE_V AS SELECT * FROM ORDER_LINE_T;

CREATE VIEW PRODUCT_V AS SELECT * FROM PRODUCT_T;

‘*’ is the wildcard

382
Changing and Removing Tables
 ALTER TABLE statement allows you to change
column specifications:
 ALTER TABLE CUSTOMER_T ADD (TYPE
VARCHAR(2))
 DROP TABLE statement allows you to remove
tables from your schema:
 DROP TABLE CUSTOMER_T

383
Schema Definition
 Control processing/storage efficiency:
 Choice of indexes
 File organizations for base tables
 File organizations for indexes
 Data clustering
 Statistics maintenance
 Creating indexes
 Speed up random/sequential access to base table data
 Example
 CREATE INDEX NAME_IDX ON
CUSTOMER_T(CUSTOMER_NAME)
 This makes an index for the CUSTOMER_NAME field of the
CUSTOMER_T table

384
 Insert Statement
 Adds data to a table
 Inserting a record with all fields
 INSERT INTO CUSTOMER_T VALUES (001, ‘Contemporary
Casuals’, 1355 S. Himes Blvd.’, ‘Gainesville’, ‘FL’, 32601);
 Inserting a record with specified fields
 INSERT INTO PRODUCT_T (PRODUCT_ID, PRODUCT_DESCRIPTION,
PRODUCT_FINISH, STANDARD_PRICE, PRODUCT_ON_HAND) VALUES
(1, ‘End Table’, ‘Cherry’, 175, 8);
 Inserting records from another table
 INSERT INTO CA_CUSTOMER_T SELECT * FROM CUSTOMER_T
WHERE STATE = ‘CA’;

385
386
387
388
389
Delete Statement
 Removes rows from a table
 Delete certain rows
 DELETE FROM CUSTOMER_T WHERE STATE =
‘HI’;
 Delete all rows
 DELETE FROM CUSTOMER_T;

390
Update Statement

 Modifies data in existing rows

UPDATE PRODUCT_T SET UNIT_PRICE = 775

WHERE PRODUCT_ID = 7;

391
 SELECT Statement
 Used for queries on single or multiple tables
 Clauses of the SELECT statement:
 SELECT
 List the columns (and expressions) that should be returned from the query
 FROM
 Indicate the table(s) or view(s) from which data will be obtained
 WHERE
 Indicate the conditions under which a row will be included in the result
 GROUP BY
 Indicate columns to group the results
 HAVING
 Indicate the conditions under which a group will be included
 ORDER BY
 Sorts the result according to specified columns
392
Figure 7-8: SQL statement
processing order

393
 SELECT Example
 Find products with standard price less than $275

SELECT PRODUCT_NAME, STANDARD_PRICE

FROM PRODUCT_V
WHERE STANDARD_PRICE < 275;

Product table
394
395
 SELECT Example using Alias

 Alias is an alternative column or table name

SELECT CUST.CUSTOMER AS NAME,

CUST.CUSTOMER_ADDRESS
FROM CUSTOMER_V CUST
WHERE NAME = ‘Home Furnishings’;

396
 SELECT Example
Using a Function
 Using the COUNT aggregate function to find totals
 Aggregate functions: SUM(), MIN(), MAX(), AVG(),
COUNT()

SELECT COUNT(*) FROM ORDER_LINE_V

WHERE ORDER_ID = 1004;

Order line table

397
SELECT Example – Boolean Operators
 AND, OR, and NOT Operators for customizing
conditions in WHERE clause

SELECT PRODUCT_DESCRIPTION, PRODUCT_FINISH,

STANDARD_PRICE
FROM PRODUCT_V
WHERE (PRODUCT_DESCRIPTION LIKE ‘%Desk’
OR PRODUCT_DESCRIPTION LIKE ‘%Table’)
AND UNIT_PRICE > 300;
Note: the LIKE operator allows you to compare strings using wildcards. For
example, the % wildcard in ‘%Desk’ indicates that all strings that have any
number of characters preceding the word “Desk” will be allowed
398
SELECT Example –
Sorting Results with the ORDER BY Clause
 Sort the results first by STATE, and within a state by
CUSTOMER_NAME

SELECT CUSTOMER_NAME, CITY, STATE

FROM CUSTOMER_V
WHERE STATE IN (‘FL’, ‘TX’, ‘CA’, ‘HI’)
ORDER BY STATE, CUSTOMER_NAME;

Note: the IN operator in this example allows you to include rows whose
STATE value is either FL, TX, CA, or HI. It is more efficient than separate
OR conditions
399
SELECT Example –
Categorizing Results Using the GROUP BY Clause

SELECT STATE, COUNT(STATE)

FROM CUSTOMER_V
GROUP BY STATE;

Note: you can use single-value fields with aggregate

functions if they are included in the GROUP BY clause

Customer table
400
SELECT Example –
Qualifying Results by Categories
Using the HAVING Clause
 For use with GROUP BY

SELECT STATE, COUNT(STATE)

FROM CUSTOMER_V
GROUP BY STATE
HAVING COUNT(STATE) > 1;

Like a WHERE clause, but it operates on groups (categories), not on

individual rows. Here, only those groups with total numbers greater
than 1 will be included in final result

401
 Typical Software Eng. Problems
1. User works with computer system 1.a) System transforms input document to output document
(environment irrelevant/ignored)

IN doc System OUT doc

1.b) User edits information stored in a repository

User System
System

Repository
User

2. Computer system controls the environment

(user not involved)

System Environment

3. Computer system intermediates between 3.a) System observes the environment and displays information
the user and the environment

User System Environment

User System Environment 3.b) System controls the environment as commanded by the user

402
User System Environment
 Problem Architecture
Feeding Transformation Receiving
1.a) Transformation: subsyste subsystem subsystem
m

Data
1.b) Simple workpieces: editor
User Data repository

Controlling Controlled
2. Required behavior: subsystem subsystem

Monitoring Monitored
3.a) Information display: subsystem subsystem
Display

Controlling Controlled
3.b) Commanded behavior: subsystem subsystem
Operator 403
Architectural Styles
 World Wide Web architectural style:
REST (Representational State Transfer)
 UNIX shell script architectural style:
Pipe-and-Filter
 Client/Server
 Central Repository (database)
 Layered (or Multi-Tiered)
 Peer-to-Peer
 Model-View-Controller

404
 Architectural Styles – Constituent Parts

1. Components
 Processing elements that “do the work”
2. Connectors
 Enable communication among components
 Broadcast Bus, Middleware-enabled, implicit (events), explicit (procedure
calls, ORBs, explicit communications bus) …

3. Interfaces
 Connection points on components and connectors
 define where data may flow in and out of the components/connectors

4. Configurations
 Arrangements of components and connectors that form an architecture

405
Architectural Style: Pipe-and-Filter
 Components: Filters transform input into output
 Connectors: Pipe data streams
 Example: UNIX shell commands

filter filter filter

pipe pipe

% ls folder-name | grep –v match-string | more

406
Architectural Style: Layered
a.k.a. Tiered Software Architecture

User Interaction User Authentication Archiving

Control of Communicating alerts

Sensors and Devices about intrusion

User Interface Domain Logic Layer Technical Services

Layer (Business Rules) Layer

407
Architectural Style:
Model-View-Controller
¨Model: holds all the data, state and application logic. Oblivious
to the View and Controller. Provides API to retrieve state and
send notifications of state changes to “observer”
¨View: gives you a presentation of the Model. Gets data directly
from the Model
¨Controller: Takes user input and figures out what it means to
the Model
display
5. I need your state (to display)

View
4. I have changed

3. Change your display Model

1. The user did something

user Controller 2. Change your state

input device 408

Model-View-Controller
User Interface
Model
Controller
Input Domain
Event
Event Domain
Domain
device model
Interpreter
Interpreter Model
Model
events action

Notification
Visual feedback
Model
Model about the
User of the altered
Visualizer
Visualizer effects of the
model
action

View Model: array of numbers [ 14, 26, 31 ]

31
26 14
14 31
versus
Different Views for the same Model: 26
409
Real System is a Combination of
Styles

Subsystem Central
for device Repository
control

Subsystem
for remote
data access

- Valid keys
- Access history
Subsystem for - Tenant profiles
administration - …

Application Web
Web server
server browser

410
Fitting the Parts Together
 Interface Specification Semantics
 To serve as a contract between component providers and
clients, interfaces must be
 fully documented
 semantics, not just syntax
 understandable, unambiguous, precise
 Adding semantics
 informal description
 design models (e.g., UML interaction diagrams)
 pre/post conditions
411
Documenting Software Architecture:
Architecture Views
 Views are different kinds of “blueprints” created
for the system-to-be
 E.g., blueprints for buildings: construction, plumbing,
electric wiring , heating, air conditioning, …
(Different stakeholders have different information
needs)

1. Module/Subsystem Views
2. Component and Connector Views
3. Allocation Views
412
Module/Subsystem Views
 Decomposition View
 Top-down refinement (e.g., simple “block diagram”)

 Dependency View
 How parts relate to one another

 Layered View
 Special case of dependency view

 Class View
 “domain model” in OOA and “class diagram” in OOD

413
Component and Connector Views
 Process View
 Defined sequence of activities?
System represented as a series of communicating processes

 Concurrency View

 Shared Data View

 …

 Client/Server View
 E.g., in Web browsing

414
Allocation Views
 Deployment View
 Software-to-hardware assignment

 Implementation View
 File/folder structure – “package diagram”

 Work Assignment View

 Work distribution within the development team

415
LECTURE 5: Use Cases

Dr. Joe Essien

Topics
 Actors, Goals
 Sketchy/Summary Use Cases
 Use Case Diagram
 Traceability Matrix
 System Boundary and Subsystems
 Detailed Use Case Specification
 System Sequence Diagrams
 Security and Risk Management
Use Cases
 For Functional Requirements Analysis and
Specification
 A use case is a description of how a user will use
the system-to-be to accomplish business goals
 Detailed use cases are usually written as usage
scenarios or scripts, listing a specific sequence of
actions and interactions between the actors and the
system
 Deriving Use Cases from
System Requirements
1
REQ1: Keep door locked and auto-lock 2
REQ2: Lock when “LOCK” pressed 3
4
REQ3: Unlock when valid key provided
5
REQ4: Allow mistakes but prevent dictionary attacks X
REQ5: Maintain a history log Y
REQ6: Adding/removing users at runtime
REQ7: Configuring the device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries

Actor Actor’s Goal (what the actor intends to accomplish) Use Case Name
Landlord To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Landlord To lock the door & shut the lights (sometimes?). Lock (UC-2)
Landlord To create a new user account and allow access to home. AddUser (UC-3)
Landlord To retire an existing user account and disable access. RemoveUser (UC-4)
To find out who accessed the home in a given interval of
Tenant InspectAccessHistory (UC-5)
time and potentially file complaints.
Tenant To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Tenant To lock the door & shut the lights (sometimes?). Lock (UC-2)
Tenant To configure the device activation preferences. SetDevicePrefs (UC-6)
LockDevice To control the physical lock mechanism. UC-1, UC-2
LightSwitch To control the lightbulb. UC-1, UC-2
[to be To auto-lock the door if it is left unlocked for a given
AutoLock (UC-2)
identified] interval of time.

( Actors already given if working from user stories instead of system requirements )
Types of Actors
 Initiating actor (also called primary actor or
“user”): initiates the use case to realize a goal
 Participating actor (also called secondary actor):
participates in the use case but does not initiate it:
 Supporting actor: helps the system-to-be to complete
the use case
 Offstage actor: passively participates in the use case,
i.e., neither initiates nor helps complete the use case,
but may be notified about some aspect of it (e.g., for
keeping records)
 Use Case Diagram: Device Control
UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

system
boundary First tier use cases Second tier use cases

actor lude
» UC7: AuthenticateUser
«inc
«participate»
«initiate» »
UC1: Unlock t ic i pate
« par
«in
it «particip LockDevice
iat ate»
e»
Tenant
ate»
e» «particip
it iat
«i n
«pa LightSwitch
rtici
«initiate» UC2: Lock pate
»
«initiate + participate»
communication use case
Landlord Timer
Use Case Diagram: Account
Management UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

Account Management Subsystem

«initiate»
UC3: AddUser
« in
«ini clu
tiate de
» »
Landlord »
te «inclu
a UC4: RemoveUser de»
ti c ip
par
« » UC8: Login
c l ude
«in
t e»
«initia UC5: InspectAccessHistory
de»
lu
nc
«initi
ate» «i

Tenant UC6: SetDevicePrefs

GUI for UC6: Set Device Pref’s

Device Preferences
File Configure Help

Activate for valid key Activate for burglary attempt

Lights Air-
Air-conditioning Alarm bell Send SMS
Music Heating Police …

Apply Close

( NOTE: Lock device is mandatory )

Use Case Generalizations
UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

Resident
ManageUsers

Tenant Landlord UC3: AddUser UC4: RemoveUser

Actor Generalization Use Case Generalization

 Optional Use Cases: «extend»
UC1: Unlock
UC2: Lock
UC3: AddUser
Example optional use cases: UC4: RemoveUser
UC5: InspectAccessHistory
UC5: InspectAccessHistory UC6: SetDevicePrefs
»
tend UC7: AuthenticateUser
«ex
UC8: Login
ManageAccount
«ex
tend
»
UC6: SetDevicePrefs

Key differences between «include» and «extend» relationships

Included use case Extending use case
Is this use case optional? No Yes
Is the base use case complete
without this use case? No Yes

Is the execution of this use case conditional? No Yes

Does this use case change the
behavior of the base use case? No Yes

[ Source: Robert Maksimchuk & Eric Naiburg: UML for Mere Mortals, Addison-Wesley, 2005. ]
 Login Use Case?

BAD: GOOD:

Login
«inc
lude
AddUser »
AddUser
Login
Landlord
SetDevicePrefs Landlord SetDevicePrefs lu de»
«inc
 Traceability Matrix (1)
UC1: Unlock
Mapping: System requirements to Use cases UC2: Lock
UC3: AddUser
REQ1: Keep door locked and auto-lock UC4: RemoveUser
REQ2: Lock when “LOCK” pressed UC5: InspectAccessHistory
REQ3: Unlock when valid key provided UC6: SetDevicePrefs
REQ4: Allow mistakes but prevent dictionary attacks UC7: AuthenticateUser
REQ5: Maintain a history log UC8: Login
REQ6: Adding/removing users at runtime
REQ7: Configuring the device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries
Req’t PW UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8

REQ1 5 X X
REQ2 2 X
REQ3 5 X X
REQ4 4 X X
REQ5 2 X X
REQ6 1 X X X
REQ7 2 X X
REQ8 1 X X
REQ9 1 X X

Max PW 5 2 2 2 1 5 2 1

Total PW 15 3 2 2 3 9 2 3

Continued for domain model, design diagrams, …

Traceability Matrix Purpose
 To check that all requirements are covered by the
use cases
 To check that none of the use cases is introduced
without a reason (i.e., created not in response to
any requirement)
 To prioritize the work on use cases
 Schema for Detailed Use Cases
Use Case UC-#: Name / Identifier [verb phrase]

Related Requirements: List of the requirements that are addressed by this use case

Initiating Actor: Actor who initiates interaction with the system to accomplish a goal

Actor’s Goal: Informal description of the initiating actor’s goal

Participating Actors: Actors that will help achieve the goal or need to know about the outcome

Preconditions: What is assumed about the state of the system before the interaction starts
What are the results after the goal is achieved or abandoned; i.e., what must be true
Postconditions:
about the system at the time the execution of this use case is completed
Flow of Events for Main Success Scenario:
The initiating actor delivers an action or stimulus to the system (the arrow indicates the
 1.
direction of interaction, to- or from the system)
The system’s reaction or response to the stimulus; the system can also send a message to a
 2.
participating actor, if any
 3. …
Flow of Events for Extensions (Alternate Scenarios):
What could go wrong? List the exceptions to the routine and describe how they are handled
 1a. For example, actor enters invalid data
 2a. For example, power outage, network failure, or requested data unavailable
…

The arrows on the left indicate the direction of interaction:  Actor’s action;  System’s reaction
Use Case 1: Unlock
Use Case UC-1: Unlock

Related REQ1, REQ3, REQ4, and REQ5 stated in Table 2-1

Requirem’ts:
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To disarm the lock and enter, and get space lighted up automatically.
Participating LockDevice, LightSwitch, Timer
Actors:
• The set of valid keys stored in the system database is non-empty.
Preconditions: • The system displays the menu of available functions; at the door keypad the menu
choices are “Lock” and “Unlock.”
Postconditions: The auto-lock timer has started countdown from autoLockInterval.
Flow of Events for Main Success Scenario:
 1. Tenant/Landlord arrives at the door and selects the menu item “Unlock”
2. include::AuthenticateUser (UC-7)
 System (a) signals to the Tenant/Landlord the lock status, e.g., “disarmed,” (b) signals to
3. LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on
 4. System signals to the Timer to start the auto-lock timer countdown
 5. Tenant/Landlord opens the door, enters the home [and shuts the door and locks]
Subroutine «include» Use Case
Use Case UC-7: AuthenticateUser (sub-use case)
Related REQ3, REQ4 stated in Table 2‑1
Requirements:
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To be positively identified by the system (at the door interface).
Participating AlarmBell, Police
Actors:
• The set of valid keys stored in the system database is non-empty.
Preconditions:
• The counter of authentication attempts equals zero.
Postconditions: None worth mentioning.

Flow of Events for Main Success Scenario:

 1. System prompts the actor for identification, e.g., alphanumeric key
 2. Tenant/Landlord supplies a valid identification key
 3. System (a) verifies that the key is valid, and (b) signals to the actor the key validity
Flow of Events for Extensions (Alternate Scenarios):
2a. Tenant/Landlord enters an invalid identification key
 1. System (a) detects error, (b) marks a failed attempt, and (c) signals to the actor
System (a) detects that the count of failed attempts exceeds the maximum
 1a. allowed number, (b) signals to sound AlarmBell, and (c) notifies the Police actor
of a possible break-in
 2. Tenant/Landlord supplies a valid identification key
3. Same as in Step 3 above
Acceptance Test Case for
UC-7 Authenticate User

Test-case Identifier: TC-1

Use Case Tested: UC-1, main success scenario, and UC-7

The test passes if the user enters a key that is contained in the
Pass/fail Criteria: database, with less than a maximum allowed number of
unsuccessful attempts

Input Data: Numeric keycode, door identifier

Test Procedure: Expected Result:

Step 1. Type in an incorrect System beeps to indicate failure;

keycode and a valid door records unsuccessful attempt in the database;
identifier prompts the user to try again

Step 2. Type in the correct System flashes a green light to indicate success;
records successful access in the database;
keycode and door identifier disarms the lock device
 Use Case 2: Lock
Use Case UC-2: Lock
Related REQ1, REQ2, and REQ5 stated in Table 2-1
Requirements:
Initiating Actor: Any of: Tenant, Landlord, or Timer
Actor’s Goal: To lock the door & get the lights shut automatically (?)
Participating
Actors: LockDevice, LightSwitch, Timer

Preconditions: The system always displays the menu of available functions.

Postconditions: The door is closed and lock armed & the auto-lock timer is reset.
Flow of Events for Main Success Scenario:
 1. Tenant/Landlord selects the menu item “Lock”
System (a) signals affirmation, e.g., “lock armed,” (b) signals to LockDevice to arm the lock (if
 2. not already armed), (c) signal to Timer to reset the auto-lock counter, and (d) signals to
LightSwitch to turn the light off (?)
Flow of Events for Extensions (Alternate Scenarios):
2a. System senses that the door is not closed, so the lock cannot be armed
 1. System (a) signals a warning that the door is open, and (b) signal to Timer to start the alarm
counter
 2. Tenant/Landlord closes the door
System (a) senses the closure, (b) signals affirmation to the Tenant/Landlord, (c) signals to
 3. LockDevice to arm the lock, (d) signal to Timer to reset the auto-lock counter, and (e) signal to
Timer to reset the alarm counter
Use Case 3: Add User
Use Case UC-3: AddUser
Related Requirements: REQ6 stated in Error! Reference source not found.
Initiating Actor: Landlord
Actor’s Goal: To register new or remove departed residents at runtime.
Participating Actors: Tenant
Preconditions: None worth mentioning. (But note that this use case is only available
on the main computer and not at the door keypad.)
Postconditions: The modified data is stored into the database.
Flow of Events for Main Success Scenario:
 1. Landlord selects the menu item “ManageUsers”
2. Landlord identification: Include Login (UC-8)
 3. System (a) displays the options of activities available to the Landlord (including “Add
User” and “Remove User”), and (b) prompts the Landlord to make selection
 4. Landlord selects the activity, such as “Add User,” and enters the new data
 5. System (a) stores the new data on a persistent storage, and (b) signals completion
Flow of Events for Extensions (Alternate Scenarios):
4a. Selected activity entails adding new users: Include AddUser (UC-3)
4b. Selected activity entails removing users: Include RemoveUser (UC-4)
 Use Case 5: Inspect Access History
Use Case UC-5: Inspect Access History
Related
Requirements: REQ8 and REQ9 stated in Table 2-1
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To examine the access history for a particular door.
Participating
Actors: Database, Landlord
Tenant/Landlord is logged in the system and is shown a hyperlink “View Access
Preconditions: History.”
Postconditions: None.
Flow of Events for Main Success Scenario:
 1. Tenant/Landlord clicks the hyperlink “View Access History”
 System prompts for the search criteria (e.g., time frame, door location, actor role, event type, etc.)
2. or “Show all”
 3. Tenant/Landlord specifies the search criteria and submits
 System prepares a database query that best matches the actor’s search criteria and retrieves the
4.
records from the Database
 5. Database returns the matching records

 6. System (a) additionally filters the retrieved records to match the actor’s search criteria; (b) renders
the remaining records for display; and (c) shows the result for Tenant/Landlord’s consideration
 Tenant/Landlord browses, selects “interesting” records (if any), and requests further investigation
7. (with an accompanying complaint description)
System (a) displays only the selected records and confirms the request; (b) archives the request in
 8. the Database and assigns it a tracking number; (c) notifies Landlord about the request; and (d)
informs Tenant/Landlord about the tracking number
 System Boundary & Subsystems
Use Case Variations Example:

Case (a):
Local face recognition

Local
computer

Face
image
Apartment building

Security
camera

Network
Network
Case (b):
Remote face recognition FaceReco, Ltd.
 Modified Use Case Diagram
UC1: Unlock
UC2: Lock
UC3: AddUser

Authentication subsystem (FaceReco, Ltd.) UC4: RemoveUser

UC5: InspectAccessHistory
UC6: SetDevicePrefs
is externalized from the system-to-be: UC7: AuthenticateUser
UC8: Login

UC2: Lock

«p
art UC1: Unlock LockDevice
«inc
Tenant ic ipa lude
»
te»
UC7: AuthenticateUser
«pa
rtic
ipa
te»
UC3: AddUser «participate»
ate»
«initi
«in
clu
«initia ate»
te» de
» «particip
UC4: RemoveUser FaceReco, Ltd.
Landlord «inclu
de»

UC8: Login
Security and Risk Management
 Identifying and preempting the serious risks to
system’s safe and successful functioning
 Risk types:
 Intolerable
 As low as reasonably practical (ALARP)
 Acceptable
 Example abuse case input sequence:
 invalid-key, invalid-key, …  maxNumOfAttempts ;
wait maxAttemptPeriod ; invalid-key, invalid-key, …
 System Sequence Diagram
[Modeling System Workflows]

Use case: Unlock

: System
User LockDevice LightSwitch Timer
«initiating actor» «supporting actor» «supporting actor» «offstage actor»
select function(“unlock")

prompt for the key

enter key
verify key

signal: valid key, lock open

open the lock

turn on the light

start ("duration“)

Main success scenario

Similar to UML sequence diagrams,

but for actor interactions instead of software object interactions
System Sequence Diagram
[Modeling System Workflows]

Use case: Unlock

: System
User AlarmBell Police
«initiating actor» «supporting actor» «offstage actor»
select function(“unlock")

loop prompt for the key

enter key
verify key

signal: invalid key

prompt to try again
sound alarm

notify intrusion

Alternate scenario (burglary attempt)

LECTURE 6: Domain Modeling

Dr Joe Essien
Topics
 Identifying Concepts
 Concept Attributes
 Concept Associations
 Contracts: Preconditions and Postconditions
 Use Cases vs. Domain Model
In use case analysis, we consider In domain analysis, we consider
the system as a “black box” the system as a “transparent box”

(a) (b)
System Domain Model

Use Case 1

Use Case 2

Actor
Actor
Use Case N Actors
Actors
 Example: ATM Machine
System

(b)
1
4 2
7 5 3
0
8
9
6
Domain Model
Actor
(Bank
Actor
(AT (Remote Concept 3
customer) Mm
ach datacenter) Concept 1
ine
)

(a) Concept n

Actor Concept 2

Actor
 Building a Domain Model
Step 1: Identifying the boundary concepts

Boundary concepts Concept 3

Concept 1
Actor C
Actor A

Step 2: Identifying the internal concepts

Concept 2
Concept 4
Actor B Actor D
Concept 3
Concept 1
Actor C
Concept 6
Actor A
Concept 5

Internal
Concept 2 concepts
Concept 4
Actor B Actor D
Use Case 1: Unlock
Use Case UC-1: Unlock

Related Requirements: REQ1, REQ3, REQ4, and REQ5 stated in Table 2-1

Initiating Actor: Any of: Tenant, Landlord

Actor’s Goal: To disarm the lock and enter, and get space lighted up automatically.

Participating Actors: LockDevice, LightSwitch, Timer

• The set of valid keys stored in the system database is non-empty.

Preconditions: • The system displays the menu of available functions; at the door keypad the menu
choices are “Lock” and “Unlock.”
Postconditions: The auto-lock timer has started countdown from autoLockInterval.

Flow of Events for Main Success Scenario:

 1. Tenant/Landlord arrives at the door and selects the menu item “Unlock”
2. include::AuthenticateUser (UC-7)
System (a) signals to the Tenant/Landlord the lock status, e.g., “disarmed,” (b) signals to
 3.
LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on
 4. System signals to the Timer to start the auto-lock timer countdown
 5. Tenant/Landlord opens the door, enters the home [and shuts the door and locks]
Extracting the Responsibilities
Responsibility Description Type Concept Name

Coordinate actions of all concepts associated with a use case, a logical grouping of use cases,
D Controller
or the entire system and delegate the work to other concepts.

Container for user’s authentication data, such as pass-code, timestamp, door identification,
K Key
etc.

Verify whether or not the key-code entered by the user is valid. D KeyChecker

Container for the collection of valid keys associated with doors and users. K KeyStorage

Operate the lock device to armed/disarmed positions. D LockOperator

Operate the light switch to turn the light on/off. D LightOperator

Operate the alarm bell to signal possible break-ins. D AlarmOperator

Block the input to deny more attempts if too many unsuccessful attempts. D Controller

Log all interactions with the system in persistent storage. D Logger

Domain Model (1)

Symbolizes Symbolizes
“worker”-type “thing”-type
concept. concept.
«entity» «entity»
KeyChecker KeyStorage

«boundary» «entity»
KeycodeEntry Key

«boundary» «control»
StatusDisplay Controller LockDevice
«boundary»
HouseholdDeviceOperator

Resident LightSwitch

Domain concepts for subsystem #1 of safe home access

 Domain Model (2)

«boundary»
HouseholdDeviceOperator

«boundary» «boundary» «boundary» «boundary»

LockOperator LightOperator MusicPlayerOperator AlarmOperator
 Domain Model (3a)
Domain model for Associations: who needs to work together, not how they work together
UC-1: Unlock Concept pair | Association description | Association name

«entity» retrieves valid keys «entity»

KeyChecker KeyStorage

verifies
conveys requests

«entity»
obtains Attributes
Key
«boundary»
KeycodeEntry userIdentityCode
timestamp
doorLocation

Association
«boundary» name
StatusDisplay
«control» LockDevice
Controller conveys requests «boundary»
HouseholdDeviceOperator
numOfAttempts
maxNumOfAttempts deviceStatuses

“Reading direction arrow.”

Resident Has no meaning; it only helps reading
LightSwitch
the association label, and is often left out.
Domain Model (3b)

«boundary»
HouseholdDeviceOperator

deviceStatus

«boundary» «boundary» «boundary» «boundary»

LockOperator LightOperator MusicPlayerOperator AlarmOperator
autoLockInterval
holdOpenInterval
asks-illumination provides-play- notifies-members
acceptingInterval
schedule

«boundary» «entity» «entity»

IlluminationDetector PlayList NotificationList
 Use Case 5: Inspect Access History
Use Case UC-5: Inspect Access History

Related Requirements: REQ8 and REQ9 stated in Table 2-1

Initiating Actor: Any of: Tenant, Landlord

Actor’s Goal: To examine the access history for a particular door.

Participating Actors: Database, Landlord

Preconditions: Tenant/Landlord is currently logged in the system and is shown a hyperlink “View Access History.”
Postconditions: None.

Flow of Events for Main Success Scenario:

 1. Tenant/Landlord clicks the hyperlink “View Access History”

 2. System prompts for the search criteria (e.g., time frame, door location, actor role, event type, etc.) or “Show all”

 3. Tenant/Landlord specifies the search criteria and submits

System prepares a database query that best matches the actor’s search criteria and retrieves the records from
 4.
the Database
 5. Database returns the matching records
System (a) additionally filters the retrieved records to match the actor’s search criteria; (b) renders the
6.
 remaining records for display; and (c) shows the result for Tenant/Landlord’s consideration
Tenant/Landlord browses, selects “interesting” records (if any), and requests further investigation (with an
 7.
accompanying complaint description)
System (a) displays only the selected records and confirms the request; (b) archives the request in the Database
8. and assigns it a tracking number; (c) notifies Landlord about the request; and (d) informs Tenant/Landlord about

the tracking number
Extracting the Responsibilities
Responsibility Description Type Concept Name
Rs1. Coordinate actions of concepts associated with this use case and delegate the work to
D Controller
other concepts.

Rs2. Form specifying the search parameters for database log retrieval (from UC-5, Step 2). K Search Request

Rs3. Render the retrieved records into an HTML document for sending to actor’s Web
D Page Maker
browser for display.

Rs4. HTML document that shows the actor the current context, what actions can be done,
K Interface Page
and outcomes of the previous actions.

Rs5. Prepare a database query that best matches the actor’s search criteria and retrieve the
D Database Connection
records from the database (from UC-5, Step 4).

Rs6. Filter the retrieved records to match the actor’s search criteria (from UC-5, Step 6). D Postprocessor

Rs7. List of “interesting” records for further investigation, complaint description, and the
K Investigation Request
tracking number.

Rs8. Archive the request in the database and assign it a tracking number (from UC-5, Step 8). D Archiver

Rs9. Notify Landlord about the request (from UC-5, Step 8). D Notifier
Extracting the Associations
Concept pair Association description Association name

Controller passes requests to Page Maker and receives back

Controller  Page Maker conveys requests
pages prepared for displaying

Page Maker  Database Database Connection passes the retrieved data to Page Maker to
provides data
Connection render them for display
Page Maker  Interface
Page Maker prepares the Interface Page prepares
Page
Controller  Database
Controller passes search requests to Database Connection conveys requests
Connection

Controller passes a list of “interesting” records and complaint

Controller  Archiver description to Archiver, which assigns the tracking number and conveys requests
creates Investigation Request

Archiver  Investigation
Archiver generates Investigation Request generates
Request

Archiver  Database Archiver requests Database Connection to store investigation

requests save
Connection requests into the database
Archiver requests Notifier to notify Landlord about investigation
Archiver  Notifier requests notify
requests
Extracting the Attributes
Concept Attributes Attribute Description

Used to determine the actor’s credentials, which in turn specify what kind of
user’s identity
data this actor is authorized to view.
Search
Request
Time frame, actor role, door location, event type (unlock, lock, power failure,
search parameters
etc.).

Postprocesso Copied from search request; needed to Filter the retrieved records to match
search parameters
r the actor’s search criteria.

records list List of “interesting” records selected for further investigation.

Investigation
complaint description Describes the actor’s suspicions about the selected access records.
Request
tracking number Allows tracking of the investigation status.

Archiver current tracking number Needed to assign a tracking number to complaints and requests.

Contact information of the Landlord who accepts complaints and requests for
Notifier contact information
further investigation.
 Domain Model (4)
Domain model
for UC-5: Inspect Access History

«control» «entity» «entity»

Controller Archiver InvestigationRequest
conveys-requests generates
«boundary» currentTrackNum recordsList
SearchRequest complaintDescr
receives trackingNum
userID
searchParams uses
conveys requests

posts «boundary»
Notifier
«boundary»
InterfacePage saves-data-to
contactInfo
Landlord
conveys-requests
prepares

«entity» «boundary»
PageMaker DatabaseConnection
provides-data
Resident Database
 Domain Analysis:
Looking from Inside Out
Pr o f e s s i onal us e r
Spe a ks Es pe r a nt o
Co nf o r mi t y - dr i v e n Po t e nt i a l us e r
Ex pe c t e d c o mma nds : Spe a ks Kl i ng o n
Ekz e mpl e r o , Al g l ui , Cur i o s i t y - dr i v e n
Re da kt i , Vi ŝi Ex pe c t e d c o mma nds :
nI H, Suq, na w‘ , De g h

CURRENT USER
C Ac c i de nt al us e r
Do e s no t s pe a k
Cha nc e - dr i v e n
Ex pe c t e d c o mma nds :
<me a ni ng l e s s - i g no r e >
 Traceability Matrix (1)
UC1: Unlock
Mapping: System requirements to Use cases UC2: Lock
UC3: AddUser
REQ1: Keep door locked and auto-lock UC4: RemoveUser
REQ2: Lock when “LOCK” pressed UC5: InspectAccessHistory
REQ3: Unlock when valid key provided UC6: SetDevicePrefs
REQ4: Allow mistakes but prevent dictionary attacks UC7: AuthenticateUser
REQ5: Maintain a history log UC8: Login
REQ6: Adding/removing users at runtime
REQ7: Configuring the device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries
Req’t PW UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8

REQ1 5 X X
REQ2 2 X
REQ3 5 X X
REQ4 4 X X
REQ5 2 X X
REQ6 1 X X X
REQ7 2 X X
REQ8 1 X X
REQ9 1 X X

Max PW 5 2 2 2 1 5 2 1

Total PW 15 3 2 2 3 9 2 3
 Traceability Matrix (2)
UC1: Unlock
Mapping: Use cases to Domain model UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
Domain Concepts UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

HouseholdDeviceOperator

DatabaseConnection

InvestigationRequest
SearchRequest
Controller-SS2
Controller-SS1

InterfacePage
KeycodeEntry
StatusDisplay

KeyChecker
KeyStorage

PageMaker

Archiver

Notifier
Use
Key

PW
Case
UC1 15 X X X X X
UC2 3 X X X
UC3 2 X X X X
UC4 2 X X X X
UC5 3 X X X X X X X X
UC6 9 X X X X
UC7 2 X X X X X
UC8 3 X X X X
Contracts:
Preconditions and Postconditions

Operation Unlock
• set of valid keys known to the system is not empty
• numOfAttempts  maxNumOfAttempts
Preconditions
• numOfAttempts = 0, for the first attempt of the current user

• numOfAttempts = 0, if the entered Key  Valid keys

Postconditions
• current instance of the Key object is archived and destroyed

Operation Lock
Preconditions
None (that is, none worth mentioning)

• lockStatus = “armed”, and

Postconditions
• lightStatus remains unchanged (see text for discussion)
 Design: Object Interactions

Design
System Sequence Diagram Sequence Diagram

Controller : Checker : KeyStorage : LockCtrl

User
«initiating actor»
ystem
: System
Timer
«offstage actor»
checkKey()
sk := getNext()
select function(“unlock")

prompt for the key

alt val != null setOpen(true)
enter key
verify key

signal: valid key, lock open [else] val == null : setLit(true)

open the lock,
turn on the light

start ("duration“)
LECTURE 7: Object Oriented Design

Dr. Joe Essien

Topics
 Assigning Responsibilities to Objects
 Design Principles
 Expert Doer
 High Cohesion
 Low Coupling

 Business Policies
 Class Diagram

463
 System Sequence Diagrams
We already worked with interaction diagrams: System Sequence Diagrams

: System
User Timer
«initiating actor» «offstage actor»
select function(“unlock")

prompt for the key

enter key
verify key

signal: valid key, lock open

open the lock,
turn on the light

start ("duration“)

System Sequence Diagrams considered interactions between the actors

464
 Design: Object Interactions
Design
Sequence Diagram

System Sequence Diagram

Controller : Checker : KeyStorage : LockCtrl

User
«initiating actor»
ystem
: System
Timer
«offstage actor»
checkKey()
sk := getNext()
select function(“unlock")

prompt for the key

alt val != null setOpen(true)
enter key
verify key

signal: valid key, lock open

open the lock, [else] val == null : setLit(true)
turn on the light

start ("duration“)

• System Sequence Diagrams considered interactions between the actors

• Object Sequence Diagrams consider interactions between the objects 465
 Metaphor for Software Design:
“Connecting the Dots”

:InterfacePage :SearchRequest :Controller :PageMaker :DatabaseConn :Archiver :Notifier :InvestigRequest

Resident Database Landlord

We start with objects/concepts from the Domain

Model and modify or introduce new objects, as
needed to make the system function work. 466
Types of Object Responsibilities
 Knowing responsibility: Memorizing data or
references, such as data values, data collections, or
references to other objects, represented as a
property
 Doing responsibility: Performing computations,
such as data processing, control of physical
devices, etc., represented as a method
 Communicating responsibility: Communicating
with other objects, represented as message sending
(method invocation)
467
Design: Assigning Responsibilities

? ? : DatabaseConn : PageMaker : Controller : Checker : DeviceCtrl

checkKey()
accessList := retrieve(params : string)

R1.
interfacePage := activate( "lock" )
render(accessList : string) ?
R2.

(a) (b)

468
Characteristics of Good Designs
 Short communication chains between the objects

 Balanced workload across the objects

method_1() method_1()
method_2()
…
 Low degree of connectivity (associations) among
method_N()

the objects

469
Design Principles
 Expert Doer Principle: that who knows should do
the task
 High Cohesion Principle: do not take on too many
computation responsibilities
 Low Coupling Principle: do not take on too many
communication responsibilities

There are many more …

470
Design: Assigning Responsibilities

: Controller : Checker : DevCtrl : Controller : Checker : DevCtrl

checkKey() ok := checkKey()

setOpen(true) setOpen(true)
?

(a) (b)

• Although the Checker is the first to acquire the information about the key validity,
we decide to assign the responsibility to notify the LockCtrl to the Controller.
• This is because the Controller would need to know this information anyway—to
inform the user about the outcome of the key validity checking.
• In this way we maintain the Checker focused on its specialty and avoid assigning
too many responsibilities to it.
471
Cohesion

Low cohesion

High cohesion

472
 Responsibility-Driven Design
1. Identify the responsibilities
 domain modeling provides a starting point
 some will be missed at first and identified in subsequent iterations

2. For each responsibility, identify the alternative assignments

 if the choice appears to be unique then move to the next responsibility
3. Consider the merits and tradeoffs of each alternative by
applying the design principles
 select what you consider the “optimal” choice
4. Document the process by which you arrived to each
responsibility assignment

473
UC-4: View Access Log

«html»
interfacePage : : Controller : PageMaker : DatabaseConnection
Resident Database

specify get( queryRequest : string )

query accessList := retrieve(params : string)
request retrieve records

result

interfacePage := render(accessList : string)

alt accessList != NULL

page :=
renderList()

[else] page :=
warning()

result «post page»

displayed

474
 Example …
Communicating responsibilities identified for the system function “enter key”:

Responsibility Description
Send message to Key Checker to validate the key entered by the user.

Send message to DeviceCtrl to disarm the lock device.

Send message to DeviceCtrl to switch the light bulb on.

Send message to PhotoObserver to report whether daylight is sensed.

Send message to DeviceCtrl to sound the alarm bell.

475
 Unlocking Sequence Diagram

: Controller : Checker : KeyStorage : LockCtrl : LightCtrl : Logger

checkKey()
sk := getNext()

alt val != null setOpen(true)

[else] val == null : setLit(true)

logTransaction(val)

sk = stored key; the process either terminates by matching a stored key or

exhausting the key store.
Key is a dynamic object, unlike others which are static contains keycode, name,
other forms of ID, timestamp, door ID, … -- disposed of after checking 476
Unlock Use Case
: Controller k : Key : Checker : KeyStorage : DeviceCtrl : PhotoObsrv : Logger

enterKey()
«create»

loop [for all stored keys]

val := checkKey( k )
sk := getNext()

compare(k, sk)

logTransaction( k, val )
«destroy»

alt val == true activate( "lock" )

dl := isDaylight()

opt dl == false activate( "bulb" )

[else] numOfAttempts++

alt numOfAttempts == maxNumOfAttempts

denyMoreAttempts()

activate( "alarm" )

[else]

prompt: "try again"

477
 Unlock Seq. Diag. Variation 1

: Controller k : Key : Checker : KeyStorage : LockCtrl

k := create()

checkKey(k) loop
sk := getNext()

setValid(ok)

controlLock(k)
ok := isValid()

opt ok == true

setOpen(true)

To avoid an impression that the above design is the only one possible!!

Sets a boolean attribute of the Key object: ok = true/false;

Business logic (IF-THEN rule) relocated from Controller to LockCtrl 478
 Unlock Seq. Diag. Variations 2&3

: LightCtrl : PhotoSObs : LightCtrl : PhotoSObs

controlLight() checkIfDaylightAndIfNotThenSetLit()
dl := isDaylight() dl := isDaylight()

opt dl == false The caller opt dl == false

could be
Controller or
setLit(true) KeyChecker setLit(true)

Depends on which solution you consider more elegant;

It is helpful that checkIfDaylightAndIfNotThenSetLit() is named informatively (reveals the
intention), but the knowledge encoded in the name of the method is imparted onto the caller.
479
 Summary of Design Variations
c
: Controller k : Key : Checker : KeyStorage : DeviceCtrl : PhotoObsrv : Logger
: DeviceCtrl : PhotoSObs
enterKey()
k := create()

loop [for all stored keys]

val := checkKey(k)
sk := getNext()

compare()
activate( "light" )
logTransaction(k, val) dl := isDaylight()
«destroy»

alt val == true activate(“lock”)

opt dl == false
dl := isDaylight()

a opt dl == false activate(“bulb”) setLit(true)

: Controller k : Key [else]

: Checker
numOfTrials++ : KeyStorage : DeviceCtrl
prompt:
"try again"
k := create()
opt numOfTrials == maxNumOfTrials activate(“alarm”)

loop
b
checkKey(k) : DeviceCtrl : PhotoSObs
sk := getNext()

setValid(ok)
checkIfDaylightAndIfNotThenSetLit()
controlLock(k) dl := isDaylight()

ok := isValid()
The caller opt dl == false
opt ok == true
could be
Controller or
setOpen(true) Checker setLit(true)
480
Business Policies

IF key  ValidKeys THEN disarm lock and turn lights on

ELSE
increment failed-attempts-counter
IF failed-attempts-counter equals maximum number allowed
THEN block further attempts and raise alarm

Should be moved into a separate object:

• Make them explicit part of the model
• Confine the future changes in business policies
481
 Class Diagram
Base Class
Container

PhotoSObsrv Key KeyStorage

1..* 1
– code_ : string
+ isDaylight() : boolean – timestamp_ : long + getNext() : Key
– doorLocation_ : string
1 sensor validKeys 1

Controller
# numOfAttemps_ : long
# maxNumOfAttempts_ : long
+ enterKey(k : Key)
– denyMoreAttempts() KeyChecker
1

checker + checkKey(k : Key) : boolean

1 devCtrl – compare(k : Key, sk : Key) : boolean

DeviceCtrl
1 logger
# devStatuses_ : Vector
Logger + activate(dev : string) : boolean
+ deactivate(dev :string) : boolean
+ logTransaction(k : Key) + getStatus(dev : string) : Object

482
 Traceability Matrix (3)
Mapping: Domain model to Class diagram
Software Classes

«html» interfacePage

DatabaseConnection
SearchRequest
Controller-SS1

Controller-SS2
PhotoSObsrv
KeyChecker
KeyStorage

PageMaker
DeviceCtrl

Logger
Key
Domain Concepts

Controller-SS1 X
StatusDisplay
Key X
KeyStorage X
KeyChecker X
HouseholdDeviceOperator X
IlluminationDetector X
Controller-SS2 X
SearchRequest X
InterfacePage X
PageMaker X
Archiver
DatabaseConnection X
Notifier
InvestigationRequest 483
Types of Object Communication

SS1
1
AA BB

SS2
AA BB PP 2

SSN
N

(a) (b) (c)

484
485
Software
Engineering 1

Lesson 10

SOFTWARE TESTING
Topics
 Overview of Software Testing
 Test Coverage and Code Coverage
 Practical Aspects of Unit Testing
 Integration and System Testing

486
Overview of Software Testing
 “Testing shows the presence, not the absence of bugs.” —
Edsger W. Dijkstra
 A fault, also called “defect” or “bug,” is an erroneous hardware
or software element of a system that can cause the system to fail
 Test-Driven Development (TDD)
 Every step in the development process must start with a plan of how to verify
that the result meets a goal
 The developer should not create a software artifact ( a system requirement, a UML
diagram, or source code) unless they know how it will be tested

 A test case is a particular choice of input data to be used in

testing a program
 A test is a finite collection of test cases
487
Why Testing is Hard
 A key tradeoff of testing:
 testing as many potential cases as possible while
keeping the economic costs limited
 Our goal is to find faults as cheaply and quickly as
possible.
 Ideally, we would design a single “right” test case to
expose each fault and run it
 In practice, we have to run many “unsuccessful”
test cases that do not expose any faults

488
 Logical Organization of Testing
Component
( Not necessarily how it’s actually done! )
code Te
Unit st
e d
test co
m
po
Component ne
code nt
Unit
test Integrated
modules
Integration System
test test
System
in use
Ensures that all
Component components
code work together
Unit
test

Ensure that each Function Quality Acceptance Installation

component works test test test test
as specified

Verifies that functional Verifies non- Customer Testing in

requirements are functional verifies all user
satisfied requirements requirements environment
489
Acceptance Tests - Examples
Input data

 Test with the valid key of a current tenant on his/her apartment

(pass) Expected result
 Test with the valid key of a current tenant on someone else’s
apartment (fail)
 Test with an invalid key on any apartment (fail)
 Test with the key of a removed tenant on his/her previous
apartment (fail)
 Test with the valid key of a just-added tenant on his/ her
apartment (pass)

490
Example: Test Case for Use Case
[ Recall Section 8: Detailed Use Case Specification ]

Test-case Identifier: TC-1

Use Case Tested: UC-1, main success scenario, and UC-7

The test passes if the user enters a key that is contained in the database,
Pass/fail Criteria:
with less than a maximum allowed number of unsuccessful attempts

Input Data: Numeric keycode, door identifier

Test Procedure: Expected Result:

Step 1. Type in an incorrect System beeps to indicate failure;

keycode and a valid door records unsuccessful attempt in the database;
identifier prompts the user to try again

System flashes a green light to indicate success;

Step 2. Type in the correct records successful access in the database;
keycode and door identifier disarms the lock device

491
491
Test Coverage
 Test coverage measures the degree to which the
specification or code of a software program has been
exercised by tests
 Code coverage measures the degree to which the
source code of a program has been tested
 Code coverage criteria include:
 equivalence testing
 boundary testing
 control-flow testing
 state-based testing
492
Code Coverage: Equivalence Testing
 Equivalence testing is a black-box testing method that divides
the space of all possible inputs into equivalence groups such
that the program “behaves the same” on each group
 Two steps:
1. partitioning the values of input parameters into equivalence groups
2. choosing the test input values

Equivalence classes:
valid equivalence class

0 100

invalid equivalence classes

493
Heuristics for Finding Equivalence Classes

 For an input parameter specified over a range of values,

partition the value space into one valid and two invalid
equivalence classes
 For an input parameter specified with a single value, partition
the value space into one valid and two invalid equivalence
classes
 For an input parameter specified with a set of values, partition
the value space into one valid and one invalid equivalence class
 For an input parameter specified as a Boolean value, partition
the value space into one valid and one invalid equivalence class

494
Code Coverage: Boundary Testing
 Boundary testing is a special case of equivalence
testing that focuses on the boundary values of input
parameters
 Based on the assumption that developers often overlook
special cases at the boundary of equivalence classes
 Selects elements from the “edges” of the equivalence
class, or “outliers” such as
 zero, min/max values, empty set, empty string, and null
 confusion between > and >=
 etc.

495
Code Coverage: Control-flow Testing
 Statement coverage
 Each statement executed at least once by some test case
 Edge coverage
 Every edge (branch) of the control flow is traversed at least once by some test case
 Condition coverage
 Every condition takes TRUE and FALSE outcomes at least once in some test case
 Path coverage
 Finds the number of distinct paths through the program to be traversed at least once
Constructing the control graph of a program for Edge Coverage:
a; a; b; if a then b; if a then b else c; while a do b;

a a not a a
a a
b not a b c b

496
Code Coverage: State-based Testing
 State-based testing defines a set of abstract states that a
software unit can take and tests the unit’s behavior by
comparing its actual states to the expected states
 This approach has become popular with object-oriented
systems

 The state of an object is defined as a constraint on the values

of object’s attributes
 Because the methods use the attributes in computing the
object’s behavior, the behavior depends on the object state

497
 State-based Testing Example

event guard condition

invalid-key [numOfAttemps  maxNumOfAttempts] /

signal-failure
action
invalid-key / invalid-key
signal-failure [numOfAttemps  maxNumOfAttempts] /
Locked Accepting sound-alarm

state valid-key /
signal-success

transition Blocked
valid-key /
signal-success

Unlocked

498
State-based Testing Example

invalid-key [numOfAttemps  maxNumOfAttempts] /

signal-failure

invalid-key / invalid-key
signal-failure [numOfAttemps  maxNumOfAttempts] /
Locked Accepting sound-alarm

valid-key /
signal-success

valid-key / Blocked
signal-success

Unlocked

499
Controller State Diagram Elements
 Four states
{ Locked, Unlocked, Accepting, Blocked }
 Two events
{ valid-key, invalid-key }
 Five valid transitions
{ LockedUnlocked, LockedAccepting,
AcceptingAccepting, AcceptingUnlocked,
AcceptingBlocked }

500
Ensure State Coverage Conditions

 Cover all identified states at least once (each state

is part of at least one test case)

 Cover all valid transitions at least once

 Trigger all invalid transitions at least once

501
Practical Aspects of Unit Testing
 Mock objects:
 A test driver simulates the part of the system that
invokes operations on the tested component
 A test stub simulates the components that are called by
the tested component
 The unit to be tested is also known as the fixture
 Unit testing follows this cycle:
1. Create the thing to be tested (fixture), the driver, and
the stub(s)
2. Have the test driver invoke an operation on the fixture
3. Evaluate that the actual state equals expected state
502
 Testing the KeyChecker (Unlock Use Case)

Test driver Tested component Test stubs

: Controller k : Key : Checker : KeyStorage testDriver : : Checker k : Key : KeyStorage

enterKey() start()
k := create() k := create()

loop [for all stored keys]

val := checkKey(k) result :=
sk := getNext() checkKey(k) loop [for all stored keys]
compare() sk := getNext()
compare()

display
result

(a) (b)

503
xUnit / JUnit
 Verification is usually done using the
assert_*_() methods that define the expected
state and raise errors if the actual state differs
 http://www.junit.org/
 Examples:
 assertTrue(4 == (2 * 2));
 assertEquals(expected, actual);
 assertNull(Object object);
 etc.

504
Example Test Case
Listing 2-1: Example test case for the Key Checker class.

public class CheckerTest {

// test case to check that invalid key is rejected
@Test public void
checkKey_anyState_invalidKeyRejected() {

// 1. set up
Checker checker = new Checker( /* constructor params */ );

// 2. act
Key invalidTestKey = new Key( /* setup with invalid code */
);
boolean result = checker.checkKey(invalidTestKey);

// 3. verify
assertEqual(result, false);
}
}

505
Test Case Method Naming

1. Set up
methodName_startingState_expectedResult
2. Act
3. Verify

Example test case method name:

checkKey_anyState_invalidKeyRejected()

506
Another Test Case Example
Listing 2-2: Example test case for the Controller class.

public class ControllerTest {

// test case to check that the state Blocked is visited
@Test public void
enterKey_accepting_toBlocked() {

// 1. set up: bring the object to the starting state

Controller cntrl = new Controller( /* constructor params */ );
// bring Controller to the Accepting state, just before it blocks
Key invalidTestKey = new Key( /* setup with invalid code */ );
for (i=0; i < cntrl.getMaxNumOfAttempts(); i++) {
cntrl.enterKey(invalidTestKey);
}
assertEqual( // check that the starting state is set up
cntrl.getNumOfAttempts(), cntrl.getMaxNumOfAttempts() – 1
);

// 2. act
cntrl.enterKey(invalidTestKey);

// 3. verify
assertEqual( // the resulting state must be "Blocked"
cntrl.getNumOfAttempts(), cntrl.getMaxNumOfAttempts()
);
assertEqual(cntrl.isBlocked(), true);
}
}
507
Integration Testing
 Horizontal Integration Testing
 “Big bang” integration
 Bottom-up integration
 Top-down integration
 Sandwich integration
 Vertical Integration Testing

508
 Horizontal Integration Testing
Controller
Level-4

Level-3
System KeyChecker

hierarchy: Level-2 KeyStorage Key

Level-1 Logger PhotoSObsrv DeviceCtrl

Test
Logger Test Controller &
Bottom-up Test
KeyChecker & KeyStorage &
Key & Logger & PhotoSObsrv

integration PhotoSObsrv & DeviceCtrl

testing: Test
DeviceCtrl Test KeyChecker
& KeyStorage &
Key
Test Key &
KeyStorage

Top-down Test Controller &

Test Test Controller &
integration Test
Controller
Controller &
KeyChecker
KeyChecker &
KeyStorage & Key
KeyChecker & KeyStorage &
Key & Logger & PhotoSObsrv
& DeviceCtrl
testing: 509
 Vertical Integration Testing
User User User
story-1 story-2 story-N inner feedback loop

Write a
Write a failing Make the
failing
acceptance test test pass
unit test

Refactor
outer feedback loop

Developing user stories:

Whole system Each story is developed in a cycle that integrates
unit tests in the inner feedback loop and the
acceptance test in the outer feedback loop

510
 Logical Organization of Testing
Component
( Not necessarily how it’s actually done! )
code Te
Unit st
e d
test co
m
po
Component ne
code nt
Unit
test Integrated
modules
Integration System
test test
System
in use
Ensures that all
Component components
code work together
Unit
test

Ensure that each Function Quality Acceptance Installation

component works test test test test
as specified

Verifies that functional Verifies non- Customer Testing in

requirements are functional verifies all user
satisfied requirements requirements environment
511
 Example of Test Case for Pen
1. Check if all parts of the pen are fitted properly and no loose fitting. [Installation
Testing]
2. Check if the pen’s ball is fitted properly and ball is moving with ease. [Installation
Testing]
3. Check the dimension of the pen as mentioned in the requirement. [UI Testing]
4. Size and shape should be confirmable for writing. [UI Testing]
5. Logo on the pen should be properly printed. [UI Testing]
6. Check if the grip on the pen is firm. [Usability Testing]
7. Check if pen is writing smoothly with continuous flow and not breaking while writing.
[Usability Testing]
8. Check if ink is not getting blemish while writing on the paper. [Usability Testing]
9. Check if pressure needs to be applied on the pen to write down on page with least
efforts. [Usability Testing]
10. Check if pen is usable for similar refills of different brands. [Usability Testing]

51
2
 Example of Test Case for Pen … Cont

11. Check if pen is writing on the page properly. [Functional Testing]

12. Check if the ink on the paper belongs to similar colour as what is seen in the refill. [Functional Testing]
13. Check if writing on paper is not getting faded out after some time. If the requirement says that ink is water
proof then apply water on written text and check the behaviour of the ink. [Functional Testing]
14. Check if the pen is making width of line as per the specified millimetre range. If the pen is coming with two
different sets of millimetre ranges i.e. 0.5 mm and 0.7 mm then make sure that line width is properly
produced by pen as per design. [Validation Testing]
15. Check if pen is working properly in flight with different pressure conditions. [Performance testing]
16. Check that if pen is not used for substantial period of time that the ink is not clotted inside the pen. Check
if user is able to access the pen with ease. [Recovery testing]
17. Check if the material used to manufacture is safe to use for chewing or kept in mouth. Generally some
users put the pen in mouth while writing, so make sure that pen is safe for putting in the mouth or
chewing.
18. Check if ink is not leaking from refill in normal conditions.
19. Check if pen is working with different writing angles; like the notice is displayed on notice board and user
wants to write on the notice board.
20. Check if the flow of ink is consistent while writing. The Badly designed pens have the problem with
uneven ink flows.

513
 Example of Test Case for Pen … Cont

21. Check if the pen’s ink is getting dry very quickly or very slowing. While writing on page, ink coming out of the
pen point should neither dry quickly nor dry too late.
22. Check if the pen is working properly on space environment if it mentioned in the requirement specifications.
[Capability testing]
23. Check how long you can write with a single refill of pen. [Capability testing]
24. Check if the pen is working properly on different type’s surfaces like smooth paper, rough paper, wooden
material, plastic, leather, steel, glass etc. [Compatibility Testing]
25. Check if he pen grips properly on the shirt pocket and user is able to carry on pocket with ease. [Robustness
Testing]
26. Check if the pen writing point is strong enough to bear a load of different users; like some user write with
some extra pressure on the pen tip. [Robustness Testing]
Negative Test Cases for Pen:
26. Check pen stress testing by dropping pen down from practical height and check if anything breaks, no
damage to pen and pen is working without any issues.
27. Hold the pen upwards direction for some time and try to write on paper.
28. Keep the pen in water and try to write on paper.
29. Check how pen is working at different climate environmental conditions like at room temperature, different
climate conditions.

514
SOFTWARE
DEVELOPMENT LIFE
CYCLE (SDLC)
Dr. Joe Essien
“You’ve got to be very careful if you don’t know where you’re going, because you might not get there.”

Yogi Berra
Capability Maturity Model (CMM)
 A bench-mark for measuring the maturity of an
organization’s software process
 CMM defines 5 levels of process maturity based on
certain Key Process Areas (KPA)
 CMM Levels
Level 5 – Optimizing (< 1%)
-- process change management
-- technology change management
-- defect prevention
Level 4 – Managed (< 5%)
-- software quality management
-- quantitative process management
Level 3 – Defined (< 10%)
-- peer reviews
-- intergroup coordination
-- software product engineering
-- integrated software management
-- training program
-- organization process definition
-- organization process focus
Level 2 – Repeatable (~ 15%)
-- software configuration management
-- software quality assurance
-- software project tracking and oversight
-- software project planning
-- requirements management
Level 1 – Initial (~ 70%)
SDLC Model
A framework that describes the activities performed
at each stage of a software development project.
Waterfall Model
 Requirements – defines needed
information, function, behavior,
performance and interfaces.
 Design – data structures, software
architecture, interface
representations, algorithmic
details.
 Implementation – source code,
database, user documentation,
testing.
Waterfall Strengths
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than cost
or schedule
Waterfall Deficiencies
 All requirements must be known upfront
 Deliverables created for each phase are considered
frozen – inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the system
(until it may be too late)
When to use the Waterfall Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
V-Shaped SDLC Model
 A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
 Testing of the product is
planned in parallel with a
corresponding phase of
development
 V-Shaped Steps
 Project and Requirements Planning –  Production, operation and
allocate resources maintenance – provide for
enhancement and corrections
 Product Requirements and
 System and acceptance testing –
Specification Analysis – complete check the entire software system in its
specification of the software system environment

 Architecture or High-Level Design –

defines how software functions fulfill  Integration and Testing – check that
the design modules interconnect correctly

 Detailed Design – develop algorithms  Unit testing – check that each module
for each architectural component acts as expected

 Coding – transform algorithms into

software
V-Shaped Strengths
 Emphasize planning for verification and validation
of the product in early stages of product
development
 Each deliverable must be testable
 Project management can track progress by
milestones
 Easy to use
V-Shaped Weaknesses
 Does not easily handle concurrent events
 Does not handle iterations or phases
 Does not easily handle dynamic changes in
requirements
 Does not contain risk analysis activities
When to use the V-Shaped Model
 Excellent choice for systems requiring high
reliability – hospital patient control applications
 All requirements are known up-front
 When it can be modified to handle changing
requirements beyond analysis phase
 Solution and technology are known
Structured Evolutionary Prototyping
Model
 Developers build a prototype during the
requirements phase
 Prototype is evaluated by end users
 Users give corrective feedback
 Developers further refine the prototype
 When the user is satisfied, the prototype code is
brought up to the standards needed for a final
product.
Structured Evolutionary Prototyping
Steps
 A preliminary project plan is developed
 An partial high-level paper model is created
 The model is source for a partial requirements specification
 A prototype is built with basic and critical attributes
 The designer builds
 the database
 user interface
 algorithmic functions
 The designer demonstrates the prototype, the user evaluates
for problems and suggests improvements.
 This loop continues until the user is satisfied
Structured Evolutionary Prototyping
Strengths
 Customers can “see” the system requirements as they
are being gathered
 Developers learn from customers
 A more accurate end product
 Unexpected requirements accommodated
 Allows for flexible design and development
 Steady, visible signs of progress produced
 Interaction with the prototype stimulates awareness
of additional needed functionality
Structured Evolutionary Prototyping
Weaknesses
 Tendency to abandon structured program
development for “code-and-fix” development
 Bad reputation for “quick-and-dirty” methods
 Overall maintainability may be overlooked
 The customer may want the prototype delivered.
 Process may continue forever (scope creep)
When to use
Structured Evolutionary Prototyping
 Requirements are unstable or have to be clarified
 As the requirements clarification stage of a waterfall
model
 Develop user interfaces
 Short-lived demonstrations
 New, original development
 With the analysis and design portions of object-
oriented development.
Rapid Application Model (RAD)
 Requirements planning phase (a workshop utilizing
structured discussion of business problems)
 User description phase – automated tools capture
information from users
 Construction phase – productivity tools, such as code
generators, screen generators, etc. inside a time-box.
(“Do until done”)
 Cutover phase -- installation of the system, user
acceptance testing and user training
RAD Strengths
 Reduced cycle time and improved productivity with
fewer people means lower costs
 Time-box approach mitigates cost and schedule risk
 Customer involved throughout the complete cycle
minimizes risk of not achieving customer satisfaction
and business needs
 Focus moves from documentation to code
(WYSIWYG).
 Uses modeling concepts to capture information about
business, data, and processes.
RAD Weaknesses
 Accelerated development process must give quick
responses to the user
 Risk of never achieving closure
 Hard to use with legacy systems
 Requires a system that can be modularized
 Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.
When to use RAD
 Reasonably well-known requirements
 User involved throughout the life cycle
 Project can be time-boxed
 Functionality delivered in increments
 High performance not required
 Low technical risks
 System can be modularized
Incremental SDLC Model
 Construct a partial
implementation of a total system
 Then slowly add increased
functionality
 The incremental model prioritizes
requirements of the system and
then implements them in groups.
 Each subsequent release of the
system adds function to the
previous release, until all designed
functionality has been
implemented.
Incremental Model Strengths
 Develop high-risk or major functions first
 Each release delivers an operational product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality early
 Risk of changing requirements is reduced
Incremental Model Weaknesses
 Requires good planning and design
 Requires early definition of a complete and fully
functional system to allow for the definition of
increments
 Well-defined module interfaces are required (some
will be developed long before others)
 Total cost of the complete system is not lower
When to use the Incremental Model
 Risk, funding, schedule, program complexity, or need
for early realization of benefits.
 Most of the requirements are known up-front but are
expected to evolve over time
 A need to get basic functionality to the market early
 On projects which have lengthy development
schedules
 On a project with new technology
Spiral SDLC Model
 Adds risk analysis, and
4gl RAD prototyping to
the waterfall model
 Each cycle involves the
same sequence of steps
as the waterfall process
model
Spiral Quadrant
Determine objectives, alternatives and constraints

 Objectives: functionality, performance, hardware/software

interface, critical success factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.
Spiral Quadrant
Evaluate alternatives, identify and resolve risks

 Study alternatives relative to objectives and constraints

 Identify risks (lack of experience, new technology, tight
schedules, poor process, etc.
 Resolve risks (evaluate if money could be lost by continuing
system development
Spiral Quadrant
Develop next-level product
 Typical activites:
 Create a design

 Review design

 Develop code

 Inspect code

 Test product
Spiral Quadrant
Plan next phase
 Typical activities
 Develop project plan

 Develop configuration management plan

 Develop a test plan

 Develop an installation plan

Spiral Model Strengths
 Provides early indication of insurmountable risks,
without much cost
 Users see the system early because of rapid
prototyping tools
 Critical high-risk functions are developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently
Spiral Model Weaknesses
 Time spent for evaluating risks too large for small or low-risk
projects
 Time spent planning, resetting objectives, doing risk analysis
and prototyping may be excessive
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-development phase
activities
 May be hard to define objective, verifiable milestones that
indicate readiness to proceed through the next iteration
When to use Spiral Model
 When creation of a prototype is appropriate
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because of
potential changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and
exploration)
Agile SDLC’s
 Speed up or bypass one or more life cycle phases
 Usually less formal and reduced scope
 Used for time-critical applications
 Used in organizations that employ disciplined
methods
Some Agile Methods
 Adaptive Software Development (ASD)
 Feature Driven Development (FDD)
 Crystal Clear
 Dynamic Software Development Method (DSDM)
 Rapid Application Development (RAD)
 Scrum
 Extreme Programming (XP)
 Rational Unify Process (RUP)
Extreme Programming - XP
For small-to-medium-sized teams developing
software with vague or rapidly changing
requirements
Coding is the key activity throughout a software
project
 Communication among teammates is done with

code
 Life cycle and behavior of complex objects defined

in test cases – again in code

 XP Practices (1-6)
1. Planning game – determine scope of the next release by
combining business priorities and technical estimates
2. Small releases – put a simple system into production, then
release new versions in very short cycle
3. Metaphor – all development is guided by a simple shared
story of how the whole system works
4. Simple design – system is designed as simply as possible
(extra complexity removed as soon as found)
5. Testing – programmers continuously write unit tests;
customers write tests for features
6. Refactoring – programmers continuously restructure the
system without changing its behavior to remove duplication
and simplify
XP Practices (7 – 12)
7. Pair-programming -- all production code is written with two
programmers at one machine
8. Collective ownership – anyone can change any code
anywhere in the system at any time.
9. Continuous integration – integrate and build the system
many times a day – every time a task is completed.
10. 40-hour week – work no more than 40 hours a week as a
rule
11. On-site customer – a user is on the team and available full-
time to answer questions
12. Coding standards – programmers write all code in
accordance with rules emphasizing communication through
the code
 XP is “extreme” because
Commonsense practices taken to extreme levels

 If code reviews are good, review code all the time (pair programming)
 If testing is good, everybody will test all the time
 If simplicity is good, keep the system in the simplest design that supports
its current functionality. (simplest thing that works)
 If design is good, everybody will design daily (refactoring)
 If architecture is important, everybody will work at defining and refining
the architecture (metaphor)
 If integration testing is important, build and integrate test several times a
day (continuous integration)
 If short iterations are good, make iterations really, really short (hours rather
than weeks)
XP References
Online references to XP at

 http://www.extremeprogramming.org/
 http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
 http://www.xprogramming.com/
Feature Driven Design (FDD)
Five FDD process activities
1. Develop an overall model – Produce class and sequence diagrams from chief
architect meeting with domain experts and developers.
2. Build a features list – Identify all the features that support requirements. The
features are functionally decomposed into Business Activities steps within
Subject Areas.
Features are functions that can be developed in two weeks and expressed in client terms with the
template: <action> <result> <object>
i.e. Calculate the total of a sale
3. Plan by feature -- the development staff plans the development sequence of
features
4. Design by feature -- the team produces sequence diagrams for the selected
features
5. Build by feature – the team writes and tests the code

http://www.nebulon.com/articles/index.html
Dynamic Systems Development Method
(DSDM)

Applies a framework for RAD and short time frames

Paradigm is the 80/20 rule

– majority of the requirements can be delivered in a
relatively short amount of time.
DSDM Principles
1. Active user involvement imperative (Ambassador users)
2. DSDM teams empowered to make decisions
3. Focus on frequent product delivery
4. Product acceptance is fitness for business purpose
5. Iterative and incremental development - to converge on a
solution
6. Requirements initially agreed at a high level
7. All changes made during development are reversible
8. Testing is integrated throughout the life cycle
9. Collaborative and co-operative approach among all
stakeholders essential
DSDM Lifecycle
 Feasibility study
 Business study – prioritized requirements
 Functional model iteration
 risk analysis
 Time-box plan
 Design and build iteration
 Implementation
Adaptive SDLC
Combines RAD with software engineering best
practices
 Project initiation

 Adaptive cycle planning

 Concurrent component engineering

 Quality review

 Final QA and release

Adaptive Steps
1. Project initialization – determine intent of project
2. Determine the project time-box (estimation
duration of the project)
3. Determine the optimal number of cycles and the
time-box for each
4. Write an objective statement for each cycle
5. Assign primary components to each cycle
6. Develop a project task list
7. Review the success of a cycle
8. Plan the next cycle
Tailored SDLC Models
 Any one model does not fit all projects
 If there is nothing that fits a particular project, pick a
model that comes close and modify it for your needs.
 Project should consider risk but complete spiral too
much – start with spiral & pare it done
 Project delivered in increments but there are serious
reliability issues – combine incremental model with
the V-shaped model
 Each team must pick or customize a SDLC model to
fit its project
Agile Web references
DePaul web site has links to many Agile references
http://se.cs.depaul.edu/ise/agile.htm
Quality – the degree to which the software
satisfies stated and implied requirements
 Absence of system crashes
 Correspondence between the software and the users’
expectations
 Performance to specified requirements

Quality must be controlled because it lowers production speed,

increases maintenance costs and can adversely affect business
Quality Assurance Plan

 The plan for quality assurance activities should be in writing

 Decide if a separate group should perform the quality
assurance activities
 Some elements that should be considered by the plan are:
defect tracking, unit testing, source-code tracking, technical
reviews, integration testing and system testing.
Quality Assurance Plan

 Defect tracing – keeps track of each defect found, its source,

when it was detected, when it was resolved, how it was
resolved, etc
 Unit testing – each individual module is tested
 Source code tracing – step through source code line by line
 Technical reviews – completed work is reviewed by peers
 Integration testing -- exercise new code in combination with
code that already has been integrated
 System testing – execution of the software for the purpose of
finding defects.
1. Introduction — The Software Lifecycle

Dr. Joe Essien

Roadmap
 Course Overview
 What is Software Engineering?
 The Iterative Development Lifecycle
 Software Development Activities
 Methods and Methodologies

1.568
Roadmap
 Course Overview
 What is Software Engineering?
 The Iterative Development Lifecycle
 Software Development Activities
 Methods and Methodologies

1.569
Principle Texts
 Software Engineering. Ian Sommerville. Addison-
Wesley Pub Co; ISBN: 020139815X, 7th edition,
2004
 Software Engineering: A Practioner's Approach.
Roger S. Pressman. McGraw Hill Text; ISBN:
0072496681; 5th edition, 2001
 Using UML: Software Engineering with Objects
and Components. Perdita Stevens and Rob J.
Pooley. Addison-Wesley Pub Co; ISBN:
0201648601; 1st edition, 1999
 Designing Object-Oriented Software. Rebecca 1.570
Recommended Literature
 eXtreme Programming Explained: Embrace Change. Kent Beck. Addison-Wesley
Pub Co; ISBN: 0201616416; 1st edition (October 5, 1999)
 The CRC Card Book. David Bellin and Susan Suchman Simone. Addison-Wesley
Pub Co; ISBN: 0201895358; 1st edition (June 4, 1997)
 The Mythical Man-Month: Essays on Software Engineering. Frederick P. Brooks.
Addison-Wesley Pub Co; ISBN: 0201835959; 2nd edition (August 2, 1995)
 Agile Software Development. Alistair Cockburn. Addison-Wesley Pub Co; ISBN:
0201699699; 1st edition (December 15, 2001)
 Peopleware: Productive Projects and Teams. Tom Demarco and Timothy R. Lister.
Dorset House; ISBN: 0932633439; 2nd edition (February 1, 1999)
 Succeeding with Objects: Decision Frameworks for Project Management. Adele
Goldberg and Kenneth S. Rubin. Addison-Wesley Pub Co; ISBN: 0201628783; 1st
edition (May 1995)
 A Discipline for Software Engineering. Watts S. Humphrey. Addison-Wesley Pub
Co; ISBN: 0201546108; 1st edition (December 31, 1994)
1.571
Roadmap
 Course Overview
 What is Software Engineering?
 The Iterative Development Lifecycle
 Software Development Activities
 Methods and Methodologies

1.572
Why Software Engineering?
A naive view: coding
Problem Specification Final
Program
But ...
 Where did the specification come from?
 How do you know the specification corresponds to the
user’s needs?
 How did you decide how to structure your program?
 How do you know the program actually meets the
specification?
 How do you know your program will always work 1.573
What is Software Engineering? (I)
Some Definitions and Issues

“state of the art of developing quality software on time and

within budget”

 Trade-off between perfection and physical

constraints
 SE has to deal with real-world issues
 State of the art!
 Community decides on “best practice” + life-long
education 1.574
What is Software Engineering? (II)
“multi-person construction of multi-version software”
— Parnas
 Team-work
 Scale issue (“program well” is not enough) +
Communication Issue
 Successful software systems must evolve or perish
 Change is the norm, not the exception

1.575
What is Software Engineering?
(III)
“software engineering is different from other engineering
disciplines”
— Sommerville

 Not constrained by physical laws

 limit = human mind

 It is constrained by political forces

 balancing stake-holders

1.576
Roadmap
 Course Overview
 What is Software Engineering?
 The Iterative Development Lifecycle
 Software Development Activities
 Methods and Methodologies

1.577
 Software Development Activities
1.578

Requirements
Establish customer’s needs
Collection
Model and specify the requirements
Analysis
(“what”)
Model and specify a solution
Design
(“how”)

Implementation Construct a solution in software

Validate the solution against the

Testing
requirements
Repair defects and adapt the
Maintenance
solution to new requirements

NB: th are ongoing activities, not sequential phases!

The Classical Software Lifecycle
The classical
Requirements
software lifecycle Collection
models the software Analysis
Design
development as a
Implementation
step-by-step
Testing
“waterfall” between
Maintenance
the various
development phases.

The waterfall model is unrealistic for many reasons:

• requirements must be frozen too early in the life-cycle
• requirements are validated too late

1.579
Problems with the Waterfall
Lifecycle
1. “Real projects rarely follow the sequential flow that the model proposes.
Iteration always occurs and creates problems in the application of the
paradigm”

2. “It is often difficult for the customer to state all requirements explicitly.
The classic life cycle requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many projects.”

3. “The customer must have patience. A working version of the program(s)

will not be available until late in the project timespan. A major blunder,
if undetected until the working program is reviewed, can be disastrous.”
— Pressman, SE, p. 26

1.580
 Iterative Development
In practice, development is always iterative, and all activities
progress in parallel.

Requirements Testing based on requirements

Collection

Maintenance through iteration Testing

Analysis Testing throughout implementation

Validation through prototyping
If the waterfall
Implementation
model is pure
Design fiction, why is it still
Design through refactoring
the dominant
software process?

1.581
Iterative Development
Plan to iterate your analysis, design and
implementation.

 You won’t get it right the first time, so integrate,

validate and test as frequently as possible.

“You should use iterative development only on projects

that you want to succeed.”
 Martin Fowler, UML Distilled
1.582
Incremental Development
Plan to incrementally develop (i.e., prototype) the
system.
 If possible, always have a running version of the
system, even if most functionality is yet to be
implemented.
 Integrate new functionality as soon as possible.
 Validate incremental versions against user
requirements.

1.583
The Unified Process
Inception Elaboration Construction Transition
Requirements

Analysis

Design

Implementation

Test

Iter. Iter. Iter. Iter.

#1 #2 ... ... ... ... ... ... #n-1 #n

How do you plan the number of iterations?

How do you decide on completion?
1.584
Boehm’s Spiral Lifecycle

Planning = determination Risk Analysis = Analysis of

of objectives, alternatives alternatives and identification/
and constraints resolution of risks

Risk = something that

initial requirements will delay project or
increase its cost

completion go, no-go decision

first prototype
alpha demo

Customer Evaluation = Engineering =

Assessment of the Development of the
results of engineering evolving system next level product

1.585
Roadmap
 Course Overview
 What is Software Engineering?
 The Iterative Development Lifecycle
 Software Development Activities
 Methods and Methodologies

1.586
Requirements Collection
User requirements are often expressed informally:
 features
 usage scenarios

Although requirements may be documented in

written form, they may be incomplete, ambiguous,
or even incorrect.

1.587
Changing requirements
Requirements will change!
 inadequately captured or expressed in the first place
 user and business needs may change during the
project

Validation is needed throughout the software

lifecycle, not only when the “final system” is
delivered!
 build constant feedback into your project plan
 plan for change
 early prototyping [e.g., UI] can help clarify 1.588
Requirements Analysis and
Specification
Analysis is the process of specifying what a system
will do.

 The intention is to provide a clear understanding of

what the system is about and what its underlying
concepts are.

The result of analysis is a specification document.

Does the requirements
specification correspond to
the users’ actual needs?

1.589
Object-Oriented Analysis
An object-oriented analysis results in models of the
system which describe:
 classes of objects that exist in the system
 responsibilities of those classes
 relationships between those classes
 use cases and scenarios describing
 operations that can be performed on the system
 allowable sequences of those operations

1.590
Prototyping (I)
A prototype is a software program developed to test,
explore or validate a hypothesis, i.e. to reduce
risks.

An exploratory prototype, also known as a

throwaway prototype, is intended to validate
requirements or explore design choices.
 UI prototype — validate user requirements
 rapid prototype — validate functional requirements
 experimental prototype — validate technical
feasibility
1.591
Prototyping (II)
An evolutionary prototype is intended to evolve in
steps into a finished product.

 iteratively “grow” the application, redesigning and

refactoring along the way

First do it,
then do it right,
then do it fast.

1.592
Design
Design is the process of specifying how the specified
system behaviour will be realized from software
components. The results are architecture and
detailed design documents.
Object-oriented design delivers models that describe:
 how system operations are implemented by
interacting objects
 how classes refer to one another and how they are
related by inheritance
Design is an iterative process,
 attributes and operations
proceeding in parallelassociated
with to classes
implementation!

1.593
Conway’s Law
 “Organizations that design systems are constrained to
produce designs that are copies of the communication
structures of th organizations”

1.594
Implementation and Testing
Implementation is the activity of constructing a
software solution to the customer’s requirements.

Testing is the process of validating that the solution

meets the requirements.

 The result of implementation and testing is a fully

documented and validated solution.

1.595
Design, Implementation and
Testing
Design, implementation and testing are iterative
activities
 The implementation does not “implement the design”,
but rather the design document documents the
implementation!

 System tests reflect the requirements specification

 Testing and implementation go hand-in-hand
 Ideally, test case specification precedes design and
implementation

1.596
Maintenance
Maintenance is the process of changing a system
after it has been deployed.
 Corrective maintenance: identifying and repairing

defects
 Adaptive maintenance: adapting the existing

solution to new platforms

 Perfective maintenance: implementing new

requirements
In a spiral lifecycle, everything after
the delivery and deployment of the
first prototype can be considered
“maintenance”!
1.597
Maintenance activities
“Maintenance” entails:
 configuration and version management

 reengineering (redesigning and refactoring)

 updating all analysis, design and user

documentation

Repeatable, automated
tests enable evolution
and refactoring

1.598
Maintenance costs

“Maintenance” typically
accounts for 70% of software
costs! Changes in
Data Formats
17%

Changes in
User
Emergency Requirement
Fixes s
12%
Means: most Routine
project costs Debugging
9%
concern continued Hardware
Other
3%
development after Changes
6% Efficiency
deployment Improvements
Documentation 4%
6% – Lientz 1979

1.599
Roadmap
 Course Overview
 What is Software Engineering?
 The Iterative Development Lifecycle
 Software Development Activities
 Methods and Methodologies

1.600
Methods and Methodologies

Principle = general statement describing desirable properties

Method = general guidelines governing some activity
Technique = more technical and mechanical than method
Methodology = package of methods and techniques packaged

Tools

Methodologies

Methods and Techniques

Principle

— Ghezzi et al. 1991

1.601
Object-Oriented Methods: a brief
history
First generation:
 Adaptation of existing notations (ER diagrams, state
diagrams ...): Booch, OMT, Shlaer and Mellor, ...
 Specialized design techniques:
 CRC cards; responsibility-driven design; design by
contract
Second generation:
 Fusion: Booch + OMT + CRC + formal methods
Third generation:
 Unified Modeling Language:
 uniform notation: Booch + OMT + Use Cases + ...
 various UML-based methods (e.g. Catalysis)
1.602
What you should know!
 How does Software Engineering differ from
programming?
 Why is the “waterfall” model unrealistic?
 What is the difference between analysis and
design?
 Why plan to iterate? Why develop incrementally?
 Why is programming only a small part of the cost
of a “real” software project?
 What are the key advantages and disadvantages of
object-oriented methods?
1.603
Can you answer the questions?
 What is the appeal of the “waterfall” model?
 Why do requirements change?
 How can you validate that an analysis model
captures users’ real needs?
 When does analysis stop and design start?
 When can implementation start?
 What are good examples of Conway’s Law in
action?

1.604
JIRA Customization for EO
Projects
Advanced Computer Systems ACS SpA
June 2010
 Scopes

 The scope of this document is to provide useful

information on how to use “JIRA” , a web based
tool developed by Atlassian (see
http://www.atlassian.com), for the Project
Management of all ACS Projects.
 Who uses JIRA

• JIRA is used for issue tracking and

project management by over 11,500
organisations in 107 countries around
the globe — across Fortune 1000,
public enterprise, science and
technology sectors.
Some Customers…
 What is JIRA
• JIRA is a bug tracking, issue tracking, and
project management web application
developed to make this process easier for
both Customers and Contractor(s).
• JIRA is based on the concept of generic
“issues”, having each a given workflow with
configurable states and actions.
ACS work : Issue Types
 Typical Project Lifecycle

End of Project Kick

Warran lifecycle Off
ty
Customer requests
Need of changes to SW in Vx
add ons or changes
version
Changes -> design team and restart the Design
loop
Phase

Fix SW in Vx version
Bug -> maintenance team

Tracking

Develop-
Integraton ment
& Deliver SW in
Vx version
Testing Release
Validation &
Delivery of
SW in Vx
version
 Typical Project Lifecycle

Project
End of
lifecycle
Warran Kick
ty Off

Changes Design
Phase

Bug
Tracking

Develop-
Integration ment
& Deliver SW in
Vx version
Testing Release
Issues can link each other
Issues can be moved
 Issues in project reports

JIRA PLUGIN
AVAILABLE! MINUTES OF MEETING

MONTHLY PROJECT REPORT

USE STANDARD
JIRA PLUGIN JIRA EXPORT
AVAILABLE! (WORD,EXCEL)
FICHIE DE DIALOG

DELIVERY NOTE
 PLUGINS : MOM
 A JIRA plugin “Mom Parser” is available to extract and load
Action Items from a Minutes of Meeting.
 The JIRA plugin , developed by ACS, permits to send an
email to a JIRA’s mail box with an xls file (Microsoft
Excel) as attachment, containing decisions and actions
decided in the meeting . It allows then the creation of new
Action Item issues extracted by the xls file;
 The plug-in, after email processing, sends an email back,
with an updated xls file attached, providing to each issue
included in the original excel file the JIRA “unique” identifier

MOM Template EMAIL EMAIL MOM Template

(reply)
(send via email)
MOM PARSER
PLUGINS : MOM
[pag 1-Cover Page]
PLUGINS : MOM
[pag 2- Agenda]
PLUGINS : MOM
[pag 3- Details Page]
PLUGINS : MOM
[pag 4- Summary Page]
as filled by the plugin
 PLUGINS : Delivery
Note
 At each formal SW Delivery, the Contractor has to deliver to
the Customer a formal Delivery note, containing a Company
Protocol Identifier and detailed information on what has been
delivered (i.e. SW installation kits, SW version,…)
 The template form, to be sent via email as xls file, provides
 a list of Installation Kits
 a list of Installation Sites in which the SW Version has to be installed
The plug-in extracts such information and creates corresponding issues
in JIRA connected to such SW version.
 The plug-in then “fills” the third page of the xls file with
some Revision and Release Notes information, providing all
the issues “closed” or at least set with “Fix Version” having
the same identifier then the one set in the form itself. The
plugin then reply to the original email with the updated xls
file.
EMAIL EMAIL
Delivery Note Delivery Note Plug-in Delivery Note
Template (send via email) Template (reply)
PLUGINS :
Delivery Note
[pag 1-Cover Page]
PLUGINS :
Delivery Note
[pag 2- Installation
Kits]
PLUGINS :
Delivery Note
[pag 3-Release Note
Page]
as filled by the plug-in
 HOW TO CREATE A
PROJECT
 The JIRA administrator to contact ?
Claudio Nasuti and as a back up solution contact Antonio Vollono.

 The Users that have to be created ?

ACS users already configured in the System. Only Customer and Subcontractors have to be created.
Each project has a number or “Roles” that are normally mapped into Groups.

 The information’s to provide to create it ?

For each new User, an email address have to be specified. The password will be set as default to
“12qwas” to be changed after first login.
For each project, a “3 ascii digit” code for the proprietary issues has to be defined (e.g. “ACQ”).
Also the appointed Project Manager has to be specified.

 The Groups in which they have to be arranged and their Permissions ?

The list of users to access the new Project has to include the specification to which “groups” they
have to be assigned to within the Project scopes.
Groups are: “Developers”, “Customer”, “Subcontractors” and “Project Managers”.
Belonging to a specific group implies a specific permission scheme.
HOW TO CREATE A
PROJECT

the form is available

on http://jira.acsys.it
 Project Roles
 Project Managers, a group having at least the Project Manager, the
System Engineer and the AIV manager. In large Projects, also
Facility Responsible(s) maybe part of this group.
 Developers team, formed by all the (ACS) staff working on the
Project.
 Customer team, a group in which all Customer users have to be
included.
 Sub-contractors team (occasionally), to group all users
participating to the Project as subcontractors.
 Prime Contractor, for all those Projects in which ACS is not
“prime”.

Other Roles are set for Quality and Managerial issue and are shown in
figure. They can be set also without creating a specific Group.

To each Project Role JIRA provide permission to carry on actions

(the PERMISSION SCHEME)
 HOW TO LOG ON JIRA
 URL ?
http://jira.acsys.it

 How the tool is organized?

It is organized in html pages:
 a Dashboard page,
 a Browse Project page,
 a Create New Issue page.

Dashboard is used to browse “issues” status and to have an high level view of them, such as :
 how many,
 which issue type,
 to whom they are assigned to,
 unassigned issues,
 my unresolved issues,
 issues assigned to me

Browse Project is used to have a view at “project level” of the issues.

Create New Issue, drives the user to create an issue with dedicated screens.
 HOW TO CREATE AN
ISSUE (1)

 Roles & Notifications

Issues maybe created by Customers but also by the Contractor

(i.e. ACS).
Important roles are the “Reporter”, being the User creating an
issue, and the “Assignee”, being the User having assigned the
resolution of the issue. They’ll receive emails automatically
upon each change of issue status. Also configured “Default
Watchers” shall receive an email. For some issues, while
creating, one can also add a list of user in the “Notify to”
area.
 HOW TO CREATE AN
ISSUE(2)

 Responsibilities

Responsibilities on any issue are regulated by the “workflow”

assigned to each issue type. Nominally:
• Reporter open the issue and will receive emails
• Project Managers will have the duty to assign the issue to a
user
• Assignee has to resolve the issue at “unit level”
• Project Managers and Customer (e.g. Reporter) have to verify
that the issue is effectively closed at “system level”.
• Project Managers (AIV) have the duty to then install the fix
into the Reference and/or Operational System.
 HOW TO CREATE AN
ISSUE(3)

 Internal, Private and Public Issues

It is in fact possible to create issue which are not “published”

to all Users having rights to browse the project.
This is useful to memorize and trace anything it is observed in
the System, events requiring investigation which may not be
“issues” for the “Project” at contractual level or which are not
yet declared as “bugs” but only suspects.
In order to do this JIRA Users, having permission to do it,
have to use the “Security Level” field .
 HOW ISSUE IS EVOLVING
(1)

 Workflows each issue has to undertake

Each issue has its own “statuses”. For each issue,

statuses have to undertake to a “workflow” (see
[JIRA_SUM]3.4.1 for generalities and following
subsections for each issue workflow).
JIRA controls the statuses for each issue and
“guide” the user in the correct sequencing during
the issue lifecycle.
 HOW ISSUE IS EVOLVING
(2)
 Who receives email warning on the issues

JIRA emits an email on each status change or comment to :

 The Reporter of the issue
 The Assignee to the issue
 All the Watchers of the issue

Watchers are :
- those users having seen an issue in which they are interested in and have
requested JIRA (in the left pane of the “issue detail” page) to add their
login to the watchers list.
- default watchers set in the Project Role while creating the Project
- users that while creating the issue have been set into the “Notify To” field
(field available only for specific issues like SPRs).
 HOW ISSUE IS EVOLVING
(3)
 How to monitor periodically issues evolution and….a
number of GOOD PRACTISES!!!!

 Each User is suggested to log on JIRA daily and check the “issues” to
which he has been assigned for.
 It is a good practise anyway to have a look to the recent issues opened
in each Project for which the User is granted to access in JIRA to
participate to the issue discussion.
 Each user is requested to subscribe to a special “filter”, the “Overdue
in the next 5 days”. In this way he’ll be warned via email on the issues
having a “Due Date” (i.e. AIL) going to expire (see “important note” in
section 3.1.1.1).
 Force all the Project Team to discuss the issues in the tool and not (at
least not only) via email. This shall allow a full log of all the
discussions held over an issue.
WORKFLOWS
:
SPRs
WORKFLOWS
:
HWI
WORKFLOWS
:
RID
 HOW TO MANAGE
SW VERSIONS (1)
 Create a new Version

JIRA provides the monitoring of “issues” in a project, all

along its phases and can apportionate them to a period or a
milestone.
JIRA issues (e.g. SPRs) are “open” quite often on a SW
Version, a commonly called “Release” and shall be “fixed”
on another.
 HOW TO MANAGE
SW VERSIONS (2)
 Check Release details
JIRA provides which issues have been fixed on which
Release
 HOW TO MANAGE
SW VERSIONS (3)
 Administering a Release
JIRA provides the capability to create but also to officially
declare as “released” a SW Version
SW Configuration Management : CVS

 How CVS is linked to JIRA

 Each time a Project is created, a member of the Project

Managers has to link CVS modules used by the Project itself.
[N.B. All CVS modules under “components” and “applications” in ACS
CVS are already pre-loaded in JIRA (but need to be anyway assigned to
become “monitored” by JIRA for such Project).]

 In case new modules have to be created and then linked by a

specific Project, a member of the Project team has to contact
the JIRA system administrator
 SW Configuration
Management : CVS
 How CVS is linked to JIRA
 Each time an issue is fixed by a SW modification, the
Developer has to make a “CVS tag” and report the JIRA issue
identifier as a comment (see next sections for details).
 JIRA will then automatically log into the issue which CVS
module has been corrected and therefore link the source code
to the JIRA issues.
 JIRA External Integration

General Software Development

• Email • CVS
 RSS • Subversion
 Excel • Perforce
• Visual SourceSafe
 LDAP
• FishEye
 Active Directory
WHY SOFTWARE
PROJECTS FAIL

Dr. Joe Essien

 Software projects often fail
 Standish “Chaos Chronicles” (2004 edition):
 18% of projects “failed”; (cancelled before completion)
 53% of projects “challenged” (operational, but over budget and/or over
time with fewer features or functions than initially specified…)
 Typical Standish figures:
 Cost overruns on 43% of projects; and
 Time overruns on 82% of projects.
Why Projects overrun:
MANAGEMENT ISSUES
 The requirements were not properly understood, recorded,and
analysed - so there were many unnecessarily late changes
 Related hardware or business changes and risks were not
planned, budgeted and managed competently
 Requirement changes were not kept under control and budgets
and timescales were not adjusted to reflect essential changes
 Stakeholder conflicts were not resolved before the computing
project started
Stakeholder Example: eFDP
 European Flight Data Processing
 Requirements under development for 2 years
 Several issues could not be agreed between European
ATC authorities
 ...so they left them to be resolved by the chosen suppliers.
 The project was cancelled 6 months later.
Example: A Military Network
When I looked at this system, I was told that it was:
 “A systems integration of COTS components”
 but with a million lines of custom software
 “Required to be the infrastructure for time-critical
and safety-critical communications”
 but not designed to guarantee message delivery
These were management, not technical issues
- but they could have been avoided through better engineering
The project was more than ten years late
From Needs to Systems [1]
 Need: A digital automobile odometer for recording
trips and total mileage
 Requirements: The system shall record and display
total mileage travelled. The user shall not be able to
reset the total. The system shall record and display
trip mileages. The user shall be able to set the trip
counter to zero ...
 From Needs to Systems [2]

Traditional methods Strong methods

 Needs: English  Needs: English
 Req: English  Req: English AND rigorous
logic
 Design: diagrams, English,  Design: diagrams, English
pseudocode AND rigorous logic
 Code: (e.g. C)  Code: (e.g. Ada)
 Test: based on Req  Tests based on Req AND
Proof
 System: >10 faults/KLoC  System: <1 fault/KLoC
Why Projects overrun:
SOFTWARE ISSUES [1]
 No Formal Specification, so:
 no rigorous analysis for contradictions and omissions in the
requirements
 so requirements errors are found late
 a weak basis for verifying the design
 so design errors are found late
 a weak basis for designing tests
 acceptance testing will be controversial
 likelihood of ambiguity
 misunderstandings will cause rework, especially around interfaces.
Why Projects overrun:
SOFTWARE ISSUES [2]
 Chosen development methods are error-prone, and
allow errors to propagate
 design languages with weak or no analysis tools to
support them
 programming languages with weak type-systems and
weak analysis tools
 Reliance on the conventional development
philosophy: “Test and Fix”
Beware “agile methods”
 Excellent for prototyping or where the required
product is not complex and can be allowed to fail in
service.
 Dangerous where
 they are an excuse for delaying agreement on the
requirements
 the system is safety-critical or security-critical or where in-
service failures would be very damaging
 the system architecture is likely to be complex and
expensive to change
 the system will have a long in-service lifetime
Beware “output-based specifications”

 A good idea: say what you need to happen not how

to achieve it.
 BUT often an excuse to leave most of the
requirements analysis until after the budget and
timescales have been agreed and the contract is in
place
 every change will now increase cost, delay and risk
OBS example:A customer information and
billing system for a major utility
 Package and supplier chosen on the basis of an Output Based
Specification. Target duration, 15 months
 Detailed requirements analysis took a year
 detailed interfaces to other systems
 statutory report formats
 statutory constraints of handling of delinquent accounts
 special charging tariffs with hundreds of allowed combinations
 statutory constraints on which users had access to which customer data
 etc
 Timescales slipped by 18 months and nearly bankrupted the
company
Software Systems are usually not
dependable
 Security vulnerabilities
 e.g. Code Red and Slammer worms caused $billions of
damage and infected ATMs etc
 Safety-critical faults
 current certification requirements are completely
inadequate
 Requirements errors
 the important requirements lie well outside the software!
 Programming mistakes
 COTS software contains thousands of faults
Example:
Requirements Problem
 what happened
 Airbus A320, Warsaw 1993
 aircraft landed on wet runway
 aquaplaned, so brakes didn’t work
 pilot applied reverse thrust, but disabled
 why
 REQ: airborne ⇔ disabled
 ASSUME not WheelPulse⇔ airborne ⇔ disabled
 simplified; for full analysis, see [Ladkin 96]
Coding Errors (even when you know the fault
you can’t write a test to demonstrate it!)
type Alert is (Warning, Caution, Advisory);
function RingBell(Event : Alert) return Boolean
-- return True for Event = Warning or Event = Caution,
-- return False for Event = Advisory
is
Result : Boolean;
begin
if Event = Warning then
Result := True;
elsif Event = Advisory then
Result := False;
end if;
return Result;
end RingBell;
-- C130J code: Caution returns uninitialised (usually
TRUE, as required).
Don’t trust demonstrations ...

Wolfgang von Kempelen’s Mechanical Turk

Customer beta-testing has become
accepted practice
Almost all software contains very
many faults
 Typical industrial / commercial software
development:
 6-30 faults delivered / 1000 lines of software
 1M lines: 6,000-30,000 faults after acceptance testing

source: Pfleeger& Hatton, IEEE Computer, pp33-42, February 1997.

Even Safety-Critical Software
contains faults
 The standard for avionics software is DO-178B.
 For the most safety-critical software it calls for
MC/DC testing.
 requirements-based testing that is shown to test every
statement, every conditional branch, and every valid
combination of Boolean variables in compound conditions.
 BUT testing does not show the absence of errors
Example:
Safety Related Faults
 Erroneous signal de-activation.
 Data not sent or lost
 Inadequate defensive programming with respected to
untrusted input data
 Warnings not sent
 Display of misleading data
 Stale values inconsistently treated
 Undefined array, local data and output parameters
More safety related faults
-Incorrect data message formats
-Ambiguous variable process update
-Incorrect initialisation of variables
Errors found in C130J
-Inadequate RAM test
software after
-Indefinite timeouts after test failure
certification.
-RAM corruption
-Timing issues - system runs backwards Source: Andy German,
-Process does not disengage when required Qinetiq. Personal
-Switches not operated when required communication.
-System does not close down after failure
-Safety check not conducted within a suitable time frame
-Use of exception handling and continuous resets
-Invalid aircraft transition states used
-Incorrect aircraft direction data
-Incorrect Magic numbers used
-Reliance on a single bit to prevent erroneous operation
Testing can never be the answer
 How many valid paths in 100 line module?
 Tens of thousands in some real systems
 How big are modern systems?
 Windows is ~100M LoC; Oracle talk about a
“gigaLoC code base”.
 How many paths is that? How many do you
think they have tested? With what proportion
of the possible data? What proportion will
ever be executed?
 “Tests show the presence not the absence
of bugs”. E. W. Dijkstra, 1969.
Testing software tells you that the tests work –
not that the software works

Continuous behaviour Discrete behaviour means

means you can interpolate that you can’t!
between test results
 Why don’t companies adopt methods
that avoid these faults?

Traditional
cost

Strong

degree of dependability
 Why don’t companies adopt methods
that avoid these faults?

Traditional
cost

Strong

Current demand

degree of dependability
 Why don’t companies adopt methods
that avoid these faults?

Traditional
cost
Future demand

Strong

Current demand

degree of dependability
Most spec changes arise from poor
requirements capture
 Most software costs flow from error
detection and correction
 The cost of correcting an error rises steeply with time
 Up to 10 times with each lifecycle phase
 The only way to reduce costs, duration and risks is to
greatly reduce errors and to find almost all the rest
almost immediately.
Strong Software Engineering

 Objective: Avoid errors and omissions

 … and detect errors before they grow in cost
 How? The same way other engineers do
 Explore what you should build. Create precise but high-
level descriptions. Models.
 Gradually add detail in the design, doing the hardest things
first
 Use powerful software tools at every stage to check for
errors and omissions
 Result: < 1 error / KLoC at no extra cost!
How do you get the right technical solution to a
business requirement?

USE AN ARCHITECT!

See the Royal Academy of Engineering

report on complex IT Systems.
Role of the Systems Architect
 Help the customer to understand the requirements and
possibilities
 Propose appropriate and technically feasible high-level
solutions (architectures)
 Help resolve stakeholder conflicts and agree requirements and
architecture
 Complete and FORMALISE the technical specification This
will eliminate most requirements risk.
 Manage supplier selection
 Manage the supply contract for the customer
 Manage requirement changes
 Manage the user acceptance phase
Then use Correct by Construction
development
Proof of Formal
Security Formal Specification
(Z)
Properties Specification

Proof of Security Refinement Proof

Properties Formal Design of Formal Design
(Z) (Z)

Proof of
Proof of Security Functional
Properties Properties
INFORMED (SPARK Proof)
(SPARK Proof)
Design

System Test
Specification

SPARK
System Test Static Analysis
Implementation
Key

Assurance
Activity
 OVERVIEW- Correct by Construction (C
by C) Process
 A software engineering process employing good
practices and languages
 SPARK (Ada 95 subset with annotations)
 math based formalisms (Z) at early stages for verification
of partial correctness.
 A supporting commercial toolset (Z/Eves, Examiner,
Simplifier, Proof Checker) for specifying, designing,
verifying/analyzing, developing safety or security
critical software.

Taken from an NSA presentation

Example SPARK specification
package Odometer
--# own Trip, Total: Integer;
is
procedure Zero_Trip;
--# global out Trip;
--# derives Trip from ;
--# post Trip = 0;

function Read_Trip return Integer;

--# global in Trip;

function Read_Total return Integer;

--# global in Total;

procedure Inc;
--# global in out Trip, Total;
--# derives Trip from Trip & Total from Total;
Conclusions

1. The weak development methods that are

currently widespread are unprofessional
2. As the demand for dependability increases,
strong methods will take over
3. The role of System Architect is key to the
introduction of formal specifications
Questions?
Quotations
31% of application development projects are cancelled, 53% cost 189 percent
over their original estimates, and only one third of projects are completed on
time and on budget
Stephen Lynn (Projects at Work) Nov 2006

By 2010, 40 per cent of existing enterprise architecture programmes will be

stopped due to poor execution
Gartner

The firm failed to ensure that adequate project management procedures were
in place
FSA January 2007
Fact finding
 Part 1: Divide
 those who do, and those who don’t
 Part 2: 5 minutes only
 attributes for success
 attributes for failure
 Part 3: Present failure – 1 minute
 Discussion around failure
APM Group’s 10 reasons for
failure
Why, why, why, why, why?

 Principle of 5 whys
 Use an Ishikawa diagram (fishbone)
 Start with a WBS, for example:

People Technical Political

Process External Economic
Technology Organisational Social
Project Management Technological
Legal
Environmental
Recipe for success
 Part 4 – Present success – 1 minute
 Discussion around success
 Now measure it
 Group & sort success data
 What is the characteristic of a successful project?
 Choose five ingredients
 Ignore risks at your peril
 Identify who will benefit from the project
 Appoint a champion
 Get a good Project Manager
 Identify “quick wins”
Gartner’s 4 Questions
1. Is the enterprise architecture programme delivering what it said it
would?

2. How mature is the enterprise architecture programme compared to

best and common practices?

3. How does the enterprise architecture programme affect IT directly?

4. How does the enterprise architecture programme affect the business

directly?

 The enterprise architecture must:

 Support business change
 Focus on strong leadership and human behaviour
 Include effective metrics
Using Best Practice
P3M3
 Released Feb 2006 Portfolio, Programme and Project Management Maturity Model (P3M3)

5 Optimising
5.1 5.3
5.2
 Based on OGC Best Proactive
Problem
Management
Technology
Management
Continuous
Process
Improvement

Practice and various Bodies

4 Managed
4.3
4.1 4.2 4.4
Organisational

of Knowledge Management
Metrics
Quality
Management
Cultural
Growth
Capacity
Management

 Some KPAs common to 3.3

Information
Management
3.6
Training Skills &
Competency
3.9
Inter-group
Co-ordination &
3.12
Organisational
Portfolio
Development Networking Establishment

projects, programmes and

3 Defined
3.2 3.5 3.8 3.11
Centre of
Transition Process Lifecycle
portfolio Management Definition Control
Excellence Role
Deployment

3.7
3.1 3.4 3.10
Integrated
 Each KPA includes Benefits
Management
Organisational
Focus
Management
& Reporting
Quality
Assurance

 Goals 2.2 2.4

2.6
Stakeholder
2.8
2.10
Programme
2 Repeatable

Programme Project Risk

Management Planning &
 Approach Organisation Establishment
& Comms
Management
Control
2.1 2.5 2.11
2.3 2.7 2.9
 Deployment Business
Case
Programme
Project Plan’g,
Monitoring &
Requirements Configuration
Management of
suppliers &
Definition Management Management external parties
Development Control
 Review 1.2
1.1
1 Initial

Programme
 Perception Project
Definition
Management
Awareness
 Measures
Use P3M3 to Improve
Performance
Metrics Portfolio, Programme and Project Management Maturity Model (P3M3)

4 Managed 5 Optimising
5.1 5.3
5.2
Proactive Continuous
Technology
Problem Process
Management
Management Improvement

4.3
4.1 4.2 4.4
Organisational
Management Quality Capacity

Improvement Plan
Cultural
Metrics Management Management
Growth

3.3 3.6 3.9 3.12

Training Skills & Inter-group Organisational
Information
Competency Co-ordination & Portfolio
Management Development Networking Establishment

3 Defined
3.2 3.5 3.8 3.11
Centre of
Transition Process Lifecycle Excellence Role
Management Definition Control Deployment

3.7
3.1 3.4 3.10
Integrated
Benefits Organisational Quality
Management
Management Focus Assurance
& Reporting

2.6 2.10
2.2 2.4 2.8
Stakeholder Programme

2 Repeatable
Programme Project Risk
Management Planning &
Organisation Establishment Management
& Comms Control
2.1 2.5 2.11
2.3 2.7 2.9
Business Project Plan’g, Management of
Programme Requirements Configuration suppliers &
Case Monitoring &
Definition Management Management external parties
Development Control

1.2
1.1

1 Initial
Programme
Project
Management

Appropriate KPAs
Definition
Awareness

Step 4
Portfolio, Programme and Project Management Maturity Model (P3M3)
How will you know?
4 Managed 5 Optimising

5.1 5.3
5.2
Proactive Continuous
Technology
Problem Process
Management
Management Improvement

4.3

Baseline Assessment
4.1 4.2 4.4
Organisational
Management Quality Capacity
Cultural
Metrics Management Management
Growth

3.3 3.6 3.9 3.12

Training Skills & Inter-group Organisational
Information
Competency Co-ordination & Portfolio

Step 3
Management Development Networking Establishment
3 Defined

3.2 3.5 3.8 3.11

Centre of
Transition Process Lifecycle Excellence Role
Management Definition Control Deployment

3.7
3.1 3.4 3.10
Integrated
Benefits Organisational Quality
Management

How will you

Management Focus Assurance
& Reporting

2.6 2.10
2.2 2.4 2.8
Portfolio, Programme and Project Management Maturity Model (P3M3) Stakeholder Programme
2 Repeatable

Programme Project Risk

Management Planning &
Organisation Establishment Management
& Comms Control
5 Optimising

5.1 5.3

get there?
2.1 2.5 2.11
5.2 2.3 2.7 2.9
Proactive Continuous Business Project Plan’g, Management of
Technology Programme Requirements Configuration suppliers &
Problem Process Case Monitoring &
Management Definition Management Management external parties
Development Control
Management Improvement
1.2
1.1
1 Initial

Programme
4 Managed

4.3 Project
4.1 4.2 4.4 Management
Organisational Definition
Management Quality Capacity Awareness
Cultural
Metrics Management Management
Growth

3.6 3.9 3.12

Step 2
3.3
Training Skills & Inter-group Organisational
Information
Competency Co-ordination & Portfolio
Management Development Networking Establishment
3 Defined

3.2 3.5 3.8 3.11

Centre of
Transition Process Lifecycle
Excellence Role
Management Definition Control Deployment

Where do you
3.7
3.1 3.4 3.10
Integrated
Benefits Organisational Quality
Management
Management Focus Assurance
& Reporting

2.6 2.10

want to be?
2.2 2.4 2.8
Stakeholder Programme
2 Repeatable

Programme Project Risk

Management Planning &
Organisation Establishment Management
& Comms Control
2.1 2.5 2.11
2.3 2.7 2.9
Business Project Plan’g, Management of
Programme Requirements Configuration
Case Monitoring & suppliers &
Definition Management Management external parties
Development Control

1.2
1.1
1 Initial

Programme
Project
Management
Definition
Awareness
Good planning?
AVOIDING A
SUCCESSFUL PROJECT
FAILURE
Dr Joe Essien
Successful Project Failure ?
 Contradiction in terms

?????
Have we experienced this?

691
Two Types of Failure
 Technical
“It doesn’t work”
 Effective
“There’s no payoff”

692
Avoiding Failure
 Technical Failure
 Use the PMBOK
 Good project planning
 Good technical execution
 Manage scope, cost, time, …
 Effective Failure
 Address the people issues
 Early and often
 First thought – not a later bolt on

693
Manage The Triangle
Cost

Scope Time

694
Manage The Triangle
Technology

No Change Is An Island™

Process People

695
Research and Experience
 Leavitt – 1965
 Chaos Study – 1994, 2000
 Kasser and Williams – 1997
 2004 CIO Magazine Survey
 Beer – 1980

696
Why are people the issue?
 They don’t like change!
 Specifically: They don’t like unknown or unanticipated
change
 Prefer control
 But will settle for involvement and warning
 Their Reactions
 Apathy
 Passive Aggression
 Resistance
 Sabotage
697
Usual Solution: Coercion
 Because I’m the Mommy; that’s why!
 Didn’t work for us as adolescents
 Still doesn’t work
 Wess Roberts, Leadership Secrets of Attila the Hun
 John Kotter: Leading Change
 Makes the Project Manager
the Compliance Cop

698
Needed Solution: Involvement
 Involve the people in shared success
 Promote buy–in
 Need to inspire the people

 Successful change isn’t imposed.

 It is grown by the affected people.

699
Secret to Involvement
 Communication!

 Key to Communication is –

 Listening!

 Active listening
 Not passive
 Includes others “in”

700
Communicate What?

Vision
 For the project
 For the team

No one succeeds unless everyone succeeds

 Not the All Star Game –

but the World Championship

701
How Do Leaders Communicate?
F I S H

Frequent

Integrated

Supportive

Honest
702
What Messages?
 About the business – Why?
 About the change – What?
 About the impact – WIIFM?
 About the schedule – When?

 When people are satisfied about the personal

effects,
they will accept the other messages.

703
Not Just Words
Communication = Involvement

 Adults learn by doing

 Interactive exercises
 Team efforts start small
 Logo selection – making decisions
 Presenting the old system – analysis, empathy

 Skills are grown, not delivered

704
Key Project Team Skills for
Success
 Communication
 Decision making
 Conflict management
 Analysis

705
Necessary Role Change
Project Manager

Project Leader

“You can't manage a man into combat; you must

lead him.
You manage things;
you lead people.”

706
Transformation To Leadership
 Doesn’t happen overnight
 Vision is paramount
 Must believe in what can be, not what is
 Goal Oriented
 No one succeeds unless everyone succeeds
 Key actions
 Inspire
 Involve
 Inform
 Influence
707
 Some Project Leadership Tasks

 Ensure people tasks are in the WBS

 Don’t cut training and communication
 Not learning by “osmosis”
 Be sentry for people problems
 Keep your eye on the prize
 It’s not about the BOK or the plan
 Marry every issue with a solution so all succeed.

708
Four Key Concepts
 No Change Is An Island™
 No one succeeds
unless everyone succeeds
 Communicate,
communicate,
communicate!
 Systems don’t change – People do!

709
Don’t Manage; Lead!

To manage a project

Lead the people!

710
DR JOE ESSIEN
AVOIDING THE
COMMON CAUSES OF
PROJECT FAILURE
Take actions to ensure project success
Learning Objectives
 This document is primarily aimed at those managing
or otherwise involved in the delivery of projects
across the Government.
 Addressing the stated issues should enable you to
increase the success rate on government projects
 At the end of this module, you will be able to:
 Identify reasons why projects fail.
 Prevent project failure.
 Be accountable for successful projects.

713
Executive Summary
 For small businesses holding government contracts, there are
multiple challenges to ensuring a successful engagement. It is
important to identify these challenges and adequately plan to
avoid common causes of project failure.
 Typical causes of project failure occur when the following
criteria for success are not met:
1. on time delivery,
2. on or under budget,
3. acceptance by client based on stated scope of work.
 Only a few projects achieve all three criteria. Many more are
delivered which fail on one or more of these criteria, and a
substantial number fail badly enough that they are cancelled.
 You can take certain actions which will ensure your contracts
do not fail.
714
Common Causes of Project Failure
Projects often fail because of one or more of the
following five reasons:
1. Poor planning,
2. Lack of leadership,
3. Inadequate knowledge,
4. People problems,
5. Lifecycle problems.

715
Reason 1: Poor Planning
Poor planning can include:
− Lack of communication.
− Not breaking down development into phases or steps.
− Not prioritizing operational activities, objectives.
− Not obtaining stakeholder approval.
− No business plan or inadequate business plan.
− Unrealistic expectations set, e.g., financial investment,
time required, set-up costs.
− Inadequate funding/capital or poor use of funds/capital.
− Lack of time commitment.
− Unrealistic scheduling.

716
Reason 2: Lack of Leadership
Lack of leadership can include:
− Not defining ownership or the leadership structure or
not identifying decision makers.
− Not making decisions timely or decisively.
− Lacking relevant business and management expertise in
areas such as finance, purchasing, selling, production,
and hiring and managing employees.
− Neglecting your leadership role.
− Not having a strategic vision.
− Holding unrealistic expectations of others.

717
Reason 3: Inadequate Knowledge
Inadequate knowledge can include:
− Lacking skills and a proven approach to project
management.
− Failing to price your product or service correctly.
− Not addressing potential risks due to inexperience.
− Not estimating, monitoring, or controlling expenditures.
− Not putting a process in place for measuring and
tracking results.
− Having an incomplete or vague project work plan.
− Using inadequate control systems.

718
Reason 4: People Problems
People problems can include:
− Lacking contact with senior management.
− Lacking leadership.
− Lacking effective project team integration
between clients, the supplier team, and the
supply chain.
− Being unable to resolve conflicts.
− Not having adequate resources due to
under/over estimation of work.

719
 Reason 5: Lifecycle Problems
Lifecycle problems can include:
− Failing to clearly and completely define the requirements,
resulting in building the wrong features or gaps in the
features needed.
− Using new or state of the art technology that cause
unanticipated problems.
− Using a poor technical design that does not allow for
modification or is not scalable.
− Changing requirements late in the project and continuing
change requests which cause the project to drift.
− Using technology components that do not fit together as
designed.
− Using poor initial testing techniques that cause repeated
errors.

720
 8 Common Issues To Address
1. Lack of clear links between the project and the organization's key
strategic priorities, including agreed measures of success.
2. Lack of clear senior management ownership and leadership.
3. Lack of effective engagement with project stakeholders.
4. Lack of skills and proven approach to project management and risk
management.
5. Too little attention to breaking developments and implementation into
manageable steps.
6. Evaluation of proposals driven by initial price rather than long-term
value for money (especially securing delivery of business benefits).
7. Lack of understanding of, and contact with the industry at senior levels
in the organization.
8. Lack of effective project team integration between clients, the supplier
721
team and the supply/resource chain.
 8 Common Issues To Address: Issue #1

1. Lack of clear links between the project and the organization's key
strategic priorities, including agreed measures of success.
 Do we know how the priority of this project compares and aligns with our other
delivery and operational activities?
 Have we defined the critical success factors (CSFs) for the project?
 Have the CSFs been agreed to by suppliers and key stakeholders?
 Do we have a clear project plan that covers the full period of the planned delivery
and all business change required, and indicates the means of benefits realization?
 Is the project founded upon realistic timescales, taking account of statutory lead-
times, and showing critical dependencies such that any delays can be handled?
 Are the lessons learned from relevant projects being applied?
 Has an analysis been undertaken of the effects of any slippage in time, cost, scope
or quality? In the event of a problem/conflict at least one must be sacrificed.

722
 8 Common Issues To Address: Issue #2
(Slide 1 of 2)

2. Lack of clear senior management ownership and leadership.

 Does the project management team have a clear view of the interdependencies
between projects, the benefits, and the criteria against which success will be
judged?
 If the project traverses organizational boundaries, are there clear governance
arrangements to ensure sustainable alignment with the business objectives of all
organizations involved?
 Are all proposed commitments and announcements first checked for delivery
implications?
 Are decisions taken early, decisively, and adhered to, in order to facilitate
successful delivery?

723
8 Common Issues To Address: Issue #2
(Slide 2 of 2)

 Does the project have the necessary approval to proceed from

its nominated Oversight Manager either directly or through
delegated authority to a designated Senior Responsible Owner
(SRO)?
 Does the SRO have the ability, responsibility and authority to
ensure that the business change and business benefits are
delivered?
 Does the SRO have a suitable track record of delivery? Where
necessary, is this being optimized through training?

724
 8 Common Issues To Address:
Issue #3

3. Lack of effective engagement with project stakeholders.

 Have we identified the right stakeholders?
 Have we as intelligent customers, identified the rationale for doing so (e.g. the
why, the what, the who, the where, the when and the how)?
 Have we secured a common understanding and agreement of stakeholder
requirements?
 Does the business case take account of the views of all stakeholders including
users?
 Do we understand how we will manage stakeholders (e.g. ensure buy-in, overcome
resistance to change, allocate risk to the party best able to manage it)?
 Has sufficient account been taken of the existing organizational culture?
 While ensuring that there is clear accountability, how can we resolve any
conflicting priorities?

725
 8 Common Issues To Address: Issue
#4 (Slide 1 of 2)
4. Lack of skills and proven approach to project management and risk
management.
 Is there a skilled and experienced project team with clearly defined roles and
responsibilities? If not, is there access to expertise, which can benefit those
fulfilling the requisite roles?
 Are the major risks identified, weighted and treated by the SRO, the Director, and
Project Manager and/or project team?
 Has sufficient resourcing, financial and otherwise, been allocated to the project,
including an allowance for risk?
 Do we have adequate approaches for estimating, monitoring and controlling the
total expenditure on projects?

726
 8 Common Issues To Address: Issue
#4 (Slide 2 of 2)
 Do we have effective systems for measuring and tracking the
realization of benefits in the business case?
 Are the governance arrangements robust enough to ensure that
"bad news" is not filtered out of progress reports to senior
managers until an adequate resolution is highlighted?
 If external consultants (subcontractors) are used, are they
accountable and committed to help ensure successful and
timely delivery?

727
 8 Common Issues To Address: Issue #5

5. Too little attention to breaking developments and implementation into

manageable steps.
 Has the approach been tested to ensure it is appropriate in scope (e.g. in IT-enabled
projects)?
 Has sufficient time been built-in to allow for planning applications in Property &
Construction projects for example?
 Have we done our best to keep delivery timescales short so that change during
development is avoided?
 Have enough review points been built-in so that the project can be stopped, if
changing circumstances mean that the business benefits are no longer achievable
or no longer represent value for money?
 Is there a business continuity plan in the event of the project delivering late or
failing to deliver at all?

728
 8 Common Issues To Address: Issue #6

6. Evaluation of proposals driven by price rather than long-term value

(especially securing delivery of business benefits).
 Do we have a proposed evaluation approach that allows us to balance financial
factors against quality and security of delivery?
 Is the evaluation based on whole-life value for money, taking account of capital,
maintenance and service costs?
 Does the evaluation approach take account of business criticality and affordability?
 Is the evaluation approach business driven?

729
 8 Common Issues To Address: Issue #7
(Slide 1 of 2)

7. Lack of understanding of, and contact with the industry at senior levels in
the organization.
 Have we tested that the industry understands our approach and agrees that it is
achievable?
 Have we asked suppliers to state any assumptions they are making against their
proposals?
 Have we checked that the project will attract sufficient competitive interest?
 Is senior management sufficiently engaged with the industry to be able to assess
supply-side risks?
 Do we have a clear strategy for engaging with the industry or are we making
sourcing decisions on a piecemeal basis?

730
8 Common Issues To Address: Issue #7
(Slide 2 of 2)

 Are the processes in place to ensure that all parties have a clear
understanding of their roles and responsibilities, and a shared
understanding of desired outcomes, key terms and deadlines?
 Do we understand the dynamics of the industry to determine
whether our acquisition requirements can be met, given
potentially competing pressures in other sectors of the
economy?

731
 8 Common Issues To Address: Issue #8

8. Lack of effective project team integration between clients, the supplier

team and the supply/resource chain.
 Has a market evaluation been undertaken to test market responsiveness to the
requirements being sought?
 Are the procurement routes that allow integration of the project team being used?
 Is there early supplier involvement to help determine and validate what outputs and
outcomes are sought for the project?
 Has a shared risk register been established?
 Have arrangements for sharing efficiency gains throughout the supply team been
established?

732
How to Prevent Project Failure (Slide
1 of 2)

 Require weekly status reports that include:

 Project start and completion dates.
 Which milestones you’ve passed.
 Percentage of the project that is complete.
 Any accomplishments worth mentioning.
 Important meetings attended.
 Any threats or potential risks to the projected timeline.
 Description of any problems you’ve encountered and resolved.
 Personnel or equipment limitations.
 Budget status.
 Build an effective team by considering:
 Employee skill, experience, participation ability, the projects they are already
working on, and morale.
 Pair newer resources with mentors.
 Set a realistic schedule and stick with it.
 Establish concrete, clear goal planning in project management.
733
How to Prevent Project Failure (Slide 2
of 2)

 Ensure senior management ownership and leadership from the

beginning.
 Require effective engagement with project stakeholders.
 Ensure adequate skills and proven approach to project
management and risk management.
 Pay attention to breaking developments and implementation
into manageable steps.
 Evaluate proposals based on long-term value rather than price
to secure delivery of business benefits.
 Maintain connectivity with the industry at senior levels.
 Ensure effective project team integration between clients and
the supply/resource chain.

734
Key Takeaways from This Module
 For small businesses holding government contracts, there are
multiple challenges to ensuring a successful engagement.
 It is important to identify these challenges and adequately
plan to avoid common causes of project failure.
 Project failure can be avoided by:
 Planning properly.

 Hiring the right team.

 Putting the right metrics in place.

 Creating clear links between the project and the

organization's key strategic priorities

735
Sources and Citations
 TechRepublic.com, Avoid these Common Causes for Project Failure
 American Express Open: Common Causes of Project Failure
 Adrian Woolcock, ProSidian Consulting, Avoiding the Common Causes
of Project Failure
 Project Smart, Top Three Causes of Project Failure
 gaebler.com, Why Businesses Fail
 Baseline, 4 Steps to Prevent Project Failure
 eCommerce Guide, Prevent Project Failure

736
737
Software
Engineering 1

Lesson 7

Implementation and Testing

Implementation and Testing
Implementation is the activity of constructing a
software solution to the customer’s requirements.

Testing is the process of validating that the solution

meets the requirements.

 The result of implementation and testing is a fully

documented and validated solution.

1.738
Design, Implementation and
Testing
Design, implementation and testing are iterative
activities
 The implementation does not “implement the design”,
but rather the design document documents the
implementation!

 System tests reflect the requirements specification

 Testing and implementation go hand-in-hand
 Ideally, test case specification precedes design and
implementation

1.739
Maintenance
Maintenance is the process of changing a system
after it has been deployed.
 Corrective maintenance: identifying and repairing

defects
 Adaptive maintenance: adapting the existing

solution to new platforms

 Perfective maintenance: implementing new

requirements
In a spiral lifecycle, everything after
the delivery and deployment of the
first prototype can be considered
“maintenance”!
1.740
Maintenance activities
“Maintenance” entails:
 configuration and version management

 reengineering (redesigning and refactoring)

 updating all analysis, design and user

documentation

Repeatable, automated
tests enable evolution
and refactoring

1.741
Maintenance costs

“Maintenance” typically
accounts for 70% of software
costs! Changes in
Data Formats
17%

Changes in
User
Emergency Requirement
Fixes s
12%
Means: most Routine
project costs Debugging
9%
concern continued Hardware
Other
3%
development after Changes
6% Efficiency
deployment Improvements
Documentation 4%
6% – Lientz 1979

1.742
What you should Know (1)
 Why do requirements change?
 How can you validate that an analysis model
captures users’ real needs?
 When does analysis stop and design start?
 When can implementation start?

1.743
What you should know (2)

 How does Software Engineering differ from programming?

 Why is the “waterfall” model unrealistic?
 What is the difference between analysis and design?
 Why plan to iterate? Why develop incrementally?
 Why is programming only a small part of the cost of a “real”
software project?
 What are the key advantages and disadvantages of object-
oriented methods?

1.744
745

End of Lessons
Be prepared for your exams!
Dr Joe Essien - (CSC 314) Operating Systems