Workshop Overview
|
Business
Process Change with Software Components
— The SCIPIO Method
|
This document introduces
and supports the use of the SCIPIO training material, developed by Veryard
Projects for the SCIPIO Consortium.
The SCIPIO method has been developed
to integrate current best practice in business process change, workflow
management, component-based development, open distributed processing and
legacy systems evolution. It is focused on the development and evolution
of open distributed business systems.
The SCIPIO method is managed
by the SCIPIO Consortium.
Overall Training Objectives
This workshop is intended primarily
for business analysts and systems developers. It is also suitable for technical
project managers, technical support personnel and consultants.
The workshop is divided into
separate units. Each unit has specific objectives. Thus some managers and
support staff may wish to take only those units that are relevant to their
responsibilities.
After completing this workshop
in full, the student should be able to participate in a SCIPIO project,
with some SCIPIO support.
Following suitable experience
in one or more SCIPIO projects, the student may achieve recognition as
a SCIPIO Practitioner. This indicates the ability to take a leading role
in a SCIPIO project.
Senior consultants and other
methods specialists may continue with the training programme to become
SCIPIO Master Practitioners. This indicates the ability to provide a wide
range of methods guidance at all levels, and to take a leading methods
role within an organization. The SCIPIO Master Practitioner Programme is
not described further in this document.
| Day |
Unit |
Session |
Duration |
| 1 |
1:
Introduction |
1 |
Introduction:
Understanding Business Requirements in terms of Components |
45
min |
| 2 |
Business
Background to SCIPIO |
30
min |
| 3 |
Technological
Background to SCIPIO |
30
min |
| 4 |
SCIPIO
Method - Purpose and Structure |
45
min |
| 2:
Management |
1 |
SCIPIO
Method - An Illustrative Case Study |
45
min |
| 2 |
A Service-Based
Approach to Project Management |
30
min |
| 3 |
SCIPIO
Method - Tasks and Project Scenarios |
45
min |
| 4 |
Getting
Started with CBD |
60
min |
| 2 |
3:
Modelling |
1 |
General
Modelling Principles |
45
min |
| 2 |
Modelling
Business Relationships |
60
min |
| 3 |
Modelling
Transactions and Exchanges |
90
min |
| 4 |
Modelling
Services and Behaviour |
90
min |
| 5 |
Review
of Modelling Concepts |
45
min |
| 4:
Design |
1 |
General
Design Principles |
45
min |
| 3 |
2 |
Designing
Interfaces and Components |
90
min |
| 3 |
Specifying
Platforms and Mechanisms |
30
min |
| 4 |
Review
of Design Concepts |
45
min |
| 5:
Implementation |
1 |
Reuse
and Legacy |
45
min |
| 2 |
Verification,
Validation and Testing |
45
min |
| 3 |
SCIPIO
Method - Tasks and Scenarios - Recap |
45
min |
| 4 |
Getting
Started with CBD - Recap |
45
min |
Unit 1: Introduction
Unit Objectives
- To provide an understanding
of the opportunities afforded by CBD.
- To understand the need for a
process/method for CBD.
- To appreciate the added-value
of SCIPIO.
Unit Prerequisites
Assumes some awareness of systems
development.
Overall Comments
This unit may be taken as a stand-alone
half-day seminar.
Session 1.1: Understanding Business
Requirements in terms of Components.
Session Objectives
- To appreciate the relevance
of CBD for business process change.
Suggested Duration
45 minutes
Key Ideas
- Component thinking helps business
change.
- Business organizations can benefit
from clear service-based interfaces between units.
- Business change can benefit
from stepwise implementation of change.
- We can use the same models for
addressing business requirements and computer system requirements.
Session 1.2: Business Background
to SCIPIO.
Session Objectives
- To appreciate current developments
in the business world that affect system requirements.
- To be better able to anticipate
business demands for system adaptation.
Suggested Duration
30 minutes
Key Ideas
- A business enterprise demands
flexibility from its supporting information systems. We can better deliver
this flexibility if we can understand and anticipate business change. We
don't have to regard the business environment merely as a source of random
and unpredictable changes in IS requirements.
- Management hierarchies are increasingly
vulnerable to change. In understanding the requirements of a business organization
or market, it is more important to focus on horizontal relationships (e.g.
with customers) than on vertical command structures.
- Importance of a process-oriented
view of business, supported by workflow and CSCW technologies.
- Business best practices can
be shared by making them into business components.
Session 1.3: Technological Background
to SCIPIO.
Session Objectives
- To appreciate some current technological
developments that extend system development opportunities.
Suggested Duration
30 minutes
Key Ideas
- Component-Based Development
has the potential to improve software quality and productivity.
- Open Distributed Processing
(ODP) has the potential to improve system flexibility.
- Middleware has the potential
to reduce development complexity.
- CBD, ODP and Middleware offer
new modes of reuse.
- These new technologies demand
a design approach that focuses on interfaces.
- Emergence of UML as a standard
modelling notation, with widespread tool support.
Session 1.4: The SCIPIO Method
- its purpose and structure.
Session Objectives
To appreciate the need for a
method.
To appreciate the added-value
of SCIPIO.
Suggested Duration
45 minutes
Key Ideas
- The essential characteristic
of a method is how it bridges business and IT. Many otherwise excellent
methods have an awkward jump at this point, or neglect it completely. We
use the same notations at all levels, to create a common language.
- UML is a notation, not a method.
There are several methods available for CBD, including the proprietary
methods provided by the tool vendors. SCIPIO takes the best bits of these
methods, and shows how they can be integrated more effectively.
- We aim to understand the current
system (As-Is) and the future system (To-Be), and make a controlled transition
from one to the other. We aim to reuse as much as is practical of the current
legacy system and of publicly available components
- SCIPIO improves planning and
design judgements for open distributed business systems.
Unit 2: Management
Unit Objectives
To enable IT and user management
to make informed decisions about the implementation and use of CBD within
their organizations.
Unit Prerequisites
Assumes some awareness of systems
development.
Overall Comments
Units 1 and 2 can be taken as
a stand-alone one-day Management Seminar. Alternatively, management may
be invited to attend the first day of the full course.
Session 2.1: An illustrative case
study.
Session Objectives
To get a broad understanding
of the overall shape of SCIPIO as it may be applied on a real project.
Suggested Duration
45 minutes
Key Ideas
- SCIPIO aims to identify components
that will help improve business relationships.
- SCIPIO uses the same modelling
notations for business and software requirements.
- SCIPIO reuses functionality
and data from legacy systems, wherever possible.
- SCIPIO evolves solutions to
gain early business benefits at reduced risk.
Comments
Alternative case studies may
be used at this point,
For general audiences, we use
the Liam O'Croder Mail Order Co example.
For Government audiences, we
use the Traffic 2001 example.
Session 2.2: A service-based approach
to project management.
Session Objectives
- To understand the impact of
CBD on systems development projects.
Suggested Duration
45 minutes
Key Ideas
- We have already seen that both
business processes and software applications can be designed as collaborating
activities. We now see that the same is true for projects.
- Traditional projects have been
run as relay races, with each activity passing an increasingly heavy baton
(the so-called deliverables) onto the next activity. (This metaphor applies
equally to waterfall and spiral development.)
- The days of the generalist are
numbered. Technological development makes information systems development
dependent on an increasing array of specialist areas.
- Each specialist area needs its
own specialist knowledge and methods. It collects and analyses information
that may not be meaningful elsewhere.
- To make projects more manageable,
the complexity should be hidden behind clearly defined service interfaces.
Session 2.3: Tasks and Project
Scenarios.
Session Objectives
- To understand the SCIPIO task
structure.
- To understand how waterfall
and spiral models map onto the SCIPIO task structure.
- To appreciate how SCIPIO supports
a variety of project scenarios.
Suggested Duration
45 minutes
Key Ideas
- SCIPIO divides into Assessment,
Analysis, Solution Design and Solution Delivery.
- Projects may start anywhere,
but usually end with Solution Delivery.
Comment
This session and the following
one are primarily targeted at a management level. We return to these topics
in Unit 5, when we review the material at a more technical level.
Session 2.4: Getting Started with
CBD.
Session Objectives
- To be able to plan the introduction
of CBD into the organization.
- To appreciate the challenges
of changing the technology base of an organization.
Suggested Duration
45 minutes
Key Ideas
- CBD can yield both short-term
value and longer-term value.
- You can get started quickly,
and start delivering early benefits.
- Your organization can evolve
CBD capability over time.
- Your organization will only
achieve the full potential of CBD after a full change programme.
Comment
This session and the previous
one are primarily targeted at a management level. We return to these topics
in Unit 5, when we review the material at a more technical level.
Unit 3: Modelling
Unit Objectives
- To be able to understand business
and system models.
- To be able to describe the structure
and characteristics of existing business operations and systems.
- To be able to analyse the requirements
for component-based systems.
Unit Prerequisites
Previous exposure to other modelling
techniques, such as Entity Relationship Diagramming or Object Modelling,
is helpful but not essential.
Depending on the background of
the students, the instructor may make reference to other such modelling
techniques, for comparison purposes.
Overall Comments
In this Unit, for training purposes,
we go through the modelling techniques one at a time. Thus it is as if
we were following a waterfall scenario. The student should remember that
this is only one of many scenarios. We will look at alternative scenarios
in other Units.
Session 3.1: General Modelling
Principles
Session Objectives
- To understand the main types
of model.
- To appreciate the need for a
range of perspectives.
Suggested Duration
45 minutes
Key Ideas
- We model three dimensions in
parallel: objects, processes and rules.
- We model five levels in parallel:
business relationships, transactions and exchanges, services and behaviour,
components and interfaces, and platforms and mechanisms.
- We model AsIs and ToBe in parallel,
Session 3.2: Modelling Business
Relationships
Session Objectives
- To be able to identify stakeholders,
and their roles and intentions.
- To be able to model relationships.
- To be able to define and align
business strategy and information system strategy.
Suggested Duration
45 minutes + exercise
Key Ideas
- The requirements for a project
are driven by some notion of objectives and risks for a given set of stakeholders.
- The business relationship diagram
indicates strategic opportunities and threats in a complex business process.
The business relationship diagram indicates opportunities to gain business
advantage.
- New technology often introduces
new roles and opportunities. The business relationship diagram provides
a way of analysing these opportunities, and identifying an appropriate
response.
Session 3.3: Modelling Transactions
and Exchanges
Session Objectives
- To be able to use exchange diagrams
to model interactions between collaborating agents.
- To be able to use object message/sequence
diagrams to model workflow.
Suggested Duration
45 minutes + exercise
Key Ideas
- A business relationship can
often be improved by reducing the Interaction Distance of a transaction.
- We need to understand the gap
between the ideal transaction, that perfectly supports business requirements,
and the actual transaction, as it is currently performed.
- We need to understand the constraints
of the current system. In what ways does the current architecture reduce
flexibility? How can this be addressed?
Session 3.4: Modelling Services
and Behaviour
Session Objectives
- To be able to use class diagrams
to define services and their vocabularies.
- To be able to use pre- and post-condition
logic to define behaviour precisely.
- To be able to use rule diagrams
to depict logical structure hierarchically.
Suggested Duration
45 minutes + exercise
Key Ideas
- System behaviour is composed
of operations. In an object-oriented view, operations are performed in
response to messages passed between objects.
- System behaviour can be specified
in terms of its pre- and post-condition logic. This is sometimes known
as declarative specification (as opposed to procedural specification).
- Each service type can be defined
as a class. Each class may be aware of some other classes, which it references
in its behaviour.
- Complex rules can be defined
once and referenced many times.
- When we draw the logical structure
of a legacy system as a hierarchical rule diagram, we can often spot overlaps
and gaps in the structure. Rationalizing the rule diagram can be a useful
step towards rationalizing the legacy systems themselves.
Session 3.5: Review of Modelling
Concepts
Session Objectives
- To understand the complete set
of modelling concepts used by SCIPIO, and to appreciate the associations
between them.
- To know the associated properties
that need to be documented each time you use a given concept.
- To be able to select and use
appropriate modelling tools to support SCIPIO.
Suggested Duration
45 minutes
Key Ideas
- SCIPIO uses basic UML notations,
with some extensions. This means that SCIPIO is reasonably well supported
by any modelling tool that supports UML.
Comment
We do not formally include product
information in this session. However, it may be possible invite vendors
or third parties to provide product demonstrations, if this is appropriate.
Unit 4: Design
Unit Objectives
To be able to design component-based
systems.
Unit Prerequisites
The unit assumes some basic knowledge
of information systems structures, such as mainframe, database, user interface,
network and client/server.
Previous exposure to other design
techniques is helpful but not essential.
Depending on the background of
the students, the instructor may make reference to other such design techniques,
for comparison purposes.
Overall Comments
None.
Session 4.1: General Design Principles
Session Objectives
- To be able to use common design
patterns.
- To be able to access further
design patterns.
Suggested Duration
45 minutes
Key Ideas
- Some patterns are equally valid
for business organization design and for software system design.
- Reduce complexity by hiding
information and techniques behind service interfaces.
- Use proxies and connectors to
avoid connecting everything with everything.
Session 4.2: Designing Interfaces
and Components
Session Objectives
- To be able to cluster required/available
behaviour into components.
- To be able to design stable
and reusable interfaces.
- To be able to specify component
interfaces precisely.
Suggested Duration
45 minutes + exercise
Key Ideas
- Components are accessed through
their interfaces.
- Operations can be assigned to
components.
- Data structures can be assigned
to components.
- Rules can be assigned to components.
Session 4.3: Specifying Platforms
and Mechanisms
Session Objectives
- To be able to apply the SCIPIO
notations to the design of physical infrastructure and technical architectures.
- To understand the implications
of technical design choices/constraints on quality of service.
Suggested Duration
45 minutes
Key Ideas
- Technical innovation may transform
the characteristics of a system, in ways that are important to the business.
- Quality of service depends on
technical design choices and technical constraints.
Session 4.4: Review of Design Concepts
Session Objectives
- To understand the complete set
of design concepts used by SCIPIO, and to appreciate the associations between
them.
- To know the associated properties
that need to be documented each time you use a given concept.
- To be able to select and use
appropriate design tools to support SCIPIO.
Suggested Duration
45 minutes
Key Ideas
- SCIPIO uses basic UML notations,
with some extensions. This means that SCIPIO is reasonably well supported
by any design tool that supports UML.
Comment
We do not formally include product
information in this session. However, it may be possible invite vendors
or third parties to provide product demonstrations, if this is appropriate.
Unit 5: Implementation
Unit Objectives
- To be able to deliver component-based
solutions in a legacy environment.
Unit Prerequisites
This unit assumes some experience
of systems development.
Depending on the background of
the students, the instructor may make reference to other development platforms,
for comparison purposes.
Overall Comments
None.
Session 5.1: Reuse and Legacy
Session Objectives
- To be able to harvest and reuse
components from legacy systems and databases.
- To be able to reuse data and
process models from earlier structured methods (such as SSADM and Information
Engineering).
Suggested Duration
45 minutes
Key Ideas
- Harvesting components from legacy
systems should be aligned to some notion of business advantage.
- Component interfaces can be
introduced gradually into legacy systems. The potential benefits increase
as the level of componentization increases.
- The older the system, the poorer
the documentation, the greater the risks. Componentization should proceed
cautiously, according to a clear strategy.
Session 5.2: Verification, Validation
and Testing
Session Objectives
- To understand the limitations
of traditional verification, validation and testing (VVT) approaches for
Component-Based Development.
- To be able to specify and perform
VVT activities on a CBD project.
Suggested Duration
45 minutes
Key Ideas
- Components from external sources
may have unknown quality characteristics.
- Components from different sources
may have conflicting features.
- Systems that are composed of
distributed components are almost impossible to test comprehensively.
- Systems managers need proper
controls on the assembly and use of open distributed systems.
Session 5.3: Tasks and Project
Scenarios - Recap
Session Objectives
- To understand the SCIPIO task
structure in the light of the detailed material.
- To be able to select and use
a particular scenario for a given project requirement.
Suggested Duration
45 minutes
Key Ideas
See §2.3
Supporting Material
SCIPIO Development Process Framework
Session 5.4: Getting Started with
CBD - Recap
Session Objectives
- To understand the SCIPIO Implementation
Roadmap in the light of the detailed material.
- To be able to manage the introduction
of CBD for a given organizational environment.
Suggested Duration
45 minutes
Key Ideas
See §2.4
Supporting Material
SCIPIO Implementation Roadmap
Acknowledgements
Thanks to Dalal Al-Ruwaished,
Mohamed Bassyouni, Love Bhabuta, Alan Cooper, Ingar Gronstad, Angela Hakim,
Ian Macdonald, Eric Magnuson, Colston Sanger, Nader Shebini and Aidan Ward.
Contact Details
Last updated April 15th, 1999
Copyright © 1998, 1999 Richard Veryard
