![]() |
frequently asked questions |
Scipio provides a clearly defined process for the specification and implementation of business solutions. It is intended to aid organizations in three ways:
1. |
It defines HOW to develop IT solutions to business problems and opportunities. | It increases the success rate of your projects. Each successful project
improves the relationship with end-users within your organization, makes
it easier to gain their support and active participation in future projects.
It increases the confidence of your people, enabling them to deal more effectively with business opportunities. It enables the teams procuring and implementing software tools to focus on aspects of the tool that have a demonstrable effect on your success (e.g. rates of development productivity or component reuse), and not just technological features. |
2. |
It defines WHY to develop IT solutions. | It facilitates the identification and specification of business solutions
that can be provisioned using the capabilities and technologies available
to you. This increases the Return on Investment you can deliver on the
investment your organization has made in these capabilities and technologies.
By providing a clear linkage between business solution and application delivery, Scipio should make it easier to justify further investment in IT capabilities and technologies to business people who may not be impressed with the technological features. |
3. |
It reorientates and reeducates your IT staff to be able to exploit 1) and 2). | It identifies key skills and services, and provides a focus for updating
the skills base of your consulting force.
It orients your IT staff towards projects that bring real business added-value to end-users. It provides a common framework for sharing and reusing ideas and experience from IT staff. |
Anyone who has dabbled in other CBD or OOAD methods, Workflow or ODP, BPR or TQM, will recognize significant chunks of SCIPIO. That’s not a weakness but a strength. SCIPIO does add a few new concepts and insights, but its main breakthrough is one of integration - finding a way to use the same notations and techniques all the way through from business process improvement to component-based development.
For those of you with long memories, this may seem uncannily like Information Engineering. Information Engineering didn’t offer very much in the way of new concepts or techniques. In particular, data modelling had been around for a number of years, although restricted to a fairly small circle of database enthusiasts and early adopters. Where Information Engineering scored was as follows:
We expect Scipio to have the same relationship to OO/CBD techniques as Information Engineering had to relational data modelling techniques . And we want Scipio to have the same relationship to the next generation of software tools as Information Engineering had to the first generation of CASE tools.
SCIPIO regards CBD as an extension to conventional software development and management. In other words, what CBD is saying is that we satisfy SOME of the requirements using components, but we may also satisfy some of the requirements using other (conventional) techniques. Conventional deelopment is then a special case of CBD, which lacks some of the techniques and opportunities (and of course the benefits) that characterize full CBD.
We then get a spread of possibilities, from conventional development at one end, and extreme componentization at the other end. One of the key questions to be addressed by a SCIPIO practitioner is how far does it make sense to componentize in a particular situation. In order for SCIPIO to address this question usefully, we need to say that the entire range of possibilities is included within the scope of SCIPIO.
A similar problem arises with distributed computing. Some people regard distributed systems as an alternative to centralized systems - in other words, centralized systems are not distributed. We prefer to say that all systems are distributed. We regard centralized systems as a special case with only one location. This way of putting it provides explicit foundation for the degree of distribution to be analysed and designed.
The SCIPIO method is intended for three main categories of organization.
SCIPIO is intended to be compatible with other leading methods. It offers an enhanced set of concepts and techniques, which can be plugged in to existing methods and working practices to provide added value, enhanced opportunity and reduced risk.
Within the SCIPIO method, we find it useful to apply component-based thinking to the structure of a project. Systems development involves a number of interacting activities, which provide services to each another. These activities may be carried out in sequence or in parallel. Some of these may be under the direct control of a project manager, while others are provided by separate teams. (For example, physical database design is often provided as an external service to the project, rather than carried out by members of the project team.)
One of the ways of managing the complexity of large projects is to encapsulate information. Whereas in the waterfall model of a project, information and detail accumulates exponentially during a project or series of projects; with the service model, information and detail may be contained within a single ongoing activity. (Again, physical database design is a good example of this. The DBAs have private techniques and notations that are not visible to anyone else.)
Centralized project management is clearly one way of organizing all these project activities. Various forms of twin-track development are also possible, and may be recommended for many organizations. However, a general process framework simply needs to identify the services at a high level.
One of the beauties of object modelling, of course, is that it allows us to show interactions (or collaborations) between several activitities at an abstract level, without specifying method, sequence, or management boundaries. We can then make these decisions explicitly for a given organization or project scenario.
Our policy is to maintain SCIPIO as fully compatible with the Dynamic Systems Development Method (DSDM).
We regard DSDM as one good way of managing projects, applicable to a broad range of situations. SCIPIO is a method for creating components, for creating IT solutions using components, and for creating business improvements using IT. We are therefore happy to use DSDM principles for managing SCIPIO projects, in most cases.
However, we recognize that not all organizations wish to use DSDM principles for project management, and that it is not suitable for all projects. We have therefore avoided including specific project management constraints in the SCIPIO task structure.
Given that SCIPIO is based on UML, this means that several tools support SCIPIO to a reasonable extent.
However, we believe that the methods should drive the tools, rather than the other way around. The needs of component-based developers go far beyond the capabilities of existing tools. Therefore, some of the concepts and techniques of SCIPIO are not yet supported by any tool.
In practice, this means that SCIPIO practitioners have to be pragmatic about the use of these concepts and techniques. We use these concepts and techniques as best we can. At the same time, we aim to put pressure on the tool vendors to implement these concepts and techniques in their tools.
We have introduced a tree diagram to describe and analyse the logical structure of conditions (including states, preconditions, postconditions and invariants). This allows complex logical statements to be presented and checked visually. It also allows branches of the tree to be labelled and reused. This is one of the diagrams we use when decomposing a set of business requirements into software components.
We are a little puzzled that this diagram hasn't already been automated. We can only suppose that the kind of people who build tools are so comfortable with complex expressions in first-order predicate logic, that they fail to appreciate the value of presenting the logic in any other form.
![]() Last updated May 19th, 1999 Copyright © 1998, 1999 SCIPIO Consortium Ltd |
SCIPIO Office Springfield, Standford Hants UK, GU35 8QS phone 01428-751370 |
Posted on behalf of the SCIPIO Consortium by veryard
projects
For more information on SCIPIO, please send a message to info@scipio.org For feedback on this page, please send a message to webmaster@scipio.org |