The Projects
The Customer-Supplier Dance
PROJECT 1

Write a specification for a hotel
booking system which keeps
track of current guests, available
rooms, future bookings and
payment of accounts. Include a
part for room service orders
which keeps track of the orders,
bills them to the appropriate
room, and will show the total
sales for a given period.
TEAM 1

Team:
CHARKHAND,
BEHTASH
CHAU, JOHNSON OAI KIEN
FATTAHI,
NAVID
GLOD, EWA JOLANTA
KOCIUBA,
STEVEN MICHAEL
LUU, ANDREW
PEARSON,
MARYELLEN MARIE
PHONE,
CHRISTOPHER
SCHWIEDER,
CAMERON ROBERT
SERAFIN,
LUKASZ
STENNING,
BRADLEY DAVID
STEVENS,
MICHAEL SHAUN
SUGNANAM,
KIRTHI KUMAR NAIDU
THIRSK,
JARED SEAN
VERDONE,
MICHAEL ROBERT
TRAN, D QUE

MO/WED: ICT 221
















PROJECT 2

Write a specification for a system to
manage a real estate catalogue. It
should keep track of properties with
their amenities, selling price or rental
etc, and be able to be queried by
potential customers with different
priorities. Take into account
constraints on the property such as
offers made, terms and conditions
etc.
TEAM 2

BATUWANTUDAWE,
JAMIE SAMAN
CHARKHANDEH,
SHAHIN
DOCKSTEADER,
RYAN
FOX, MICHAEL COREY
HO, VIVIAN WING KEI
LI,
GARY ANTHONY
MAXWELL,
TAMARA ELIZABETH
NELSON,
ROGER ODIN
ROGAN,
BRADLEY PHILLIP
SANDEN,
ANDREW CHARLES
STORBAKKEN, DEREK JAMES
TEMPRO,
CHRISTIAN MARC
TUNUGUNTLA, JAYA DEEP
YIP, KENNETH CHUN MING
CYPRIAN,
NGOLAH

MO: ICT116; WED: ENA 235














MORE…

http://isg.enme.ucalgary.ca/Peo
ple/Ulieru/SENG411-Outline.htm
THE DEVELOPMENT
PHASES





Software Development Process method to organize the activities
related to Creation, Delivery and
Maintenance of software systems
Preliminary Study & Requirement
Analysis
Problem Domain Analysis (coarse
design and component creation)
Iterative Incremental Development
System Test and Introduction
THE CUSTOMER


1) Informal specification of
requirements:
This should outline the project and
customer requirements. Make sure the
project is suitable for completion in one
term. Remember that it is not a
competition; do not aim to destroy the
supplier but give an honest set of
requirements. (Marks will be deducted for a
project considered too easy or too difficult.)
No more than 5 pages (if it were printed),
including the title page.(2%).
TASK DESCRIPTION


THE TASK: “Develop an
information system to support all
customer-related business
processes in a car rental
company”
INITIAL CONDITIONS:
- some business processes are
not at all supported by electronic
data processing;
- the ones supported have very
specialized systems
TASK DESCRIPTION

REQUIREMENTS:
- the system should provide all
functions directly related to handling
customers and other business
partners (e.g. suppliers.)
- remote areas that do not affect
business partners directly (e.g. tariff
planning, internal accounting, vehicle
transfer/status) shall not be part of
the system.
THE SUPPLIER


(1) Functional specification and
management plan (about 15-20
pages):
This should explain what you are
going to do for your project as
opposed to how you will accomplish
it. When writing this, do not assume
that your customer has any deep
knowledge of computer science.
REQUIREMENT ANALYSIS






Needed because the software
developers are not usually
specialists in the application domain
Put themselves in the users’ skin
Users should be actively involved!
WHAT (and WHY) the developed
software system is supposed to do
NOT ‘how’!
Communication developer-user is
essential
WAYS TO DOCUMENT THE
INFOrmation








Use Case Models
Activity Models
Specialized Dictionary
CRC cards
Mind Maps
Materials Collection
Dialog Blueprints
Business Class Models
ANALYSIS...



TECHNICAL DICTIONARY - enables
identification of business classes (
and of domain classes in the
DESIGN stage);
EXPLORATIVE PROTOTYPES
(dialog designs - first ‘view’ of the
system to be delivered + glimpse on
architecture);
CRC CARDS - identify
responsibilities and collaborators
(useful in the design of BUSINESS
class diagrams)
ANALYSIS - OVERVIEW



Analysis - maps from a
perception of the real world into
a representation;
Design - maps from an analysis
representation to an expression
of implementation, that is, from
a problem to a solution
ANALYSIS - states the problem
in terms that enable the
implementation.
RESPONSIBILITIES



THE MOST SINGLE IMPORTANT
ABILITY IN OOAD IS TO SKILFULLY
ASSIGN RESPONSIBILITIES TO
SOFTWARE COMPONENTS!
ANALYSIS - in it essence is all about
identifying CONCEPTS and
suggesting a logical solution
DESIGN - identifies OBJECTS from
the most relevant CONCEPTS (for
the application)
CLASS OR CONCEPT?




There is no universal agreement
on the meaning of class or
concept/entity/type
However they model different
perspectives:
Domain ANALYST - looks at the
real-world CONCEPTS (vehicle,
customer)
Software DESIGNER - specifies
software CLASSES
CONCEPT OR CLASS in
UML



The term ‘concept’ is not defined in
UML - so we will refer to Larman
(1998):
CONCEPT - is an idea, thing or
object. Has a symbol (words or
images), Definition and examples
(suggested by the Use Cases).
CLASS - description of a set of
objects that share the same
attributes, operations, methods,
relationships annd semantics
CONCEPT OR CLASS?...




For US:
the terms ‘concept’ (entity/type) is
used to refer to real-world things
the term ‘class’ is used to refer to
software specifications and
implementations
CONCEPTUAL MODEL (Analysis
Model, ‘Business Class Model’) representation of concepts in a
problem domain
CONCEPTUAL MODEL



In UML is illustrated with
STATIC Diagrams in which NO
OPERATIONS are defined.
Focus is on Domain Concepts,
NOT on software entities.
Consists of: CONCEPTS
(‘Business Class’),
ASSOCIATIONS between them
and ATTRIBUTES of concepts
NO OPERATIONS!!!
CUSTOMER


(2) Evaluate the Functional
specification and
management plan:
This is to be assessed and
evaluated against actual
requirements. Make sure that
you are satisfied at this stage
that your supplier is aiming to
meet your requirements
SUPPLIER


(2a) Overall design document:
Based on the examination of the
module interactions, you should
prepare a set of interface definitions.
For the overall design document,
(about 40-50 pages) you should
define your major data abstractions
and modules, focusing on the
design, submodules, error-handling,
exports and imports of the major
modules.
ANALYSIS - OVERVIEW
(cont...)





USE CASE ANALYSIS:
Identify Use Cases (Business and
System) and Actors;
Group them into packages (useful to
identify components…);
Use Case Description helps to
identify: Activities and their
Sequence; Dialogs
ARCHITECTURE SPECIFICATION
INTERFACES




Concerned with Processes and
Behavior (e.g. SelectCustomer);
Between Domain Classes (e.g.
Customer-Contract: ‘customer
has n contracts’);
At dialog level (association of
dialog components to use cases
helps to identify them!);
Specify the interfaces in detail
(using the interface classes!)
USE CASE ANALYSIS






Serve to analyze the BEHAVIOR
CRC cards - clarify the structure
Use all possible sources of info.
(documentation, special literature,
interviews with domain experts,
etc.)
Ask all possible questions about:
Objects (forms, persons, contracts,
places..)
Properties (of the objects)
ANALYSIS …



BUSINESS CLASSES - ANALYSIS
MODEL (from Use Cases; Dialog
Designs; CRC Cards; Technical
Dictionary;);
ACTIVITY MODELING (from Use
Case descriptions) - result in
operation at Design;
COMPONENT IDENTIFICATION
(Maps Activities to Business
Classes) - behavioral
CUSTOMER


(3) EVALUATE THE Overall design
document:
The functional specification and the overall
design together describe the proposal from
your supplier. When accepted, these
documents are a contract between you and
your supplier about what they intend to
deliver. Changes can be negotiated later
and should be recorded as an appendix.
Mark clearly, in italic or bold type, any
comments or amendments on the
supplier's overall design document. You
may add up to 2 additional pages
SUPPLIER and CUSTOMER


2b) Presentation:
A preliminary review of about 5
minutes will be presented in
class, with up to 5 minutes of
questions and discussion from
the customer
SUPPLIER

The detailed design document
(about 80-100 pages, built on top of
the overall design document) should
include answers to all the questions
for as many levels as possible. Write
pseudocode or code outline for all
modules (this should be in terms of
calls to other high-level functions and
be easy to read). Include test
schedules as part of this document.
Update the sections describing
coding responsibilities.
SUPPLIER


3) User manual (about 20-25
pages):
This should be a self contained
description of how to use your
system. It should have a clear
structure, a table of contents,
and an index. Do not discuss
any implementation.
CUSTOMER

EVALUATE USER’S MANUAL.
Mark clearly, in italic or bold
type, any comments or
amendments on the supplier's
user manual.
SUPPLIER


(4) Demonstration:
This should exhibit the best
features of your system. It will
be followed by questions from
your customer, with suggestions
of input to try, and discussion.
CUSTOMER

EVALUATE DEMO. Use the
demo time to assess the system
and the (possibly revised) user
manual. Everyone should attend
and take part. You should
ensure that the demo relates
closely to what has been
negotiated and agreed in the
contract.
CUSTOMER


7) PROJECT Evaluation:
Write a project evaluation (4-5
pages) which should include a
discussion of how well the project
satisfies your original requirements
or what has been added or
subtracted; how useful the design
process was and what differences (if
any) you propose for the design
assignment.
SUPPLIER


(5) PROJECT Evaluation:
Discussion of how well your project
satisfies your original functional
specifications or what has been
added or subtracted; how useful the
design process was and what
differences (if any) you propose for
the design assignment; how the test
plan worked, how the real
management structure resembled
the planned one