Benefits
To provide a whole system of components for the Software Life Cycle (SLF) is just a basic and very important requirement for ISA. It is also one of its breaking key property. The real World components just addresses a very limited set of the software scope : language, test, deployment, build, supervision, specification, etc. Some proprietary solutions that exist around the so called Application Life cycle Management (ALM) : all of them are limited. At least by the A of the Application word, at most by their closed approach and not covering the whole scope of software industry (focused on language, on supervision, …). The open solutions are worse because, among other points, they are generally oriented to a single technology and of their expansion instability.
By its position, ISA can answering all these problems thru an unified way. It can provide a common foundation and a common ground floor for the various aspects required to support and to manage the software life cycle.
| Caution :It is not in ISA scope to provide a complete set of tools, or to build advanced components and the like. There are many providers of any kind are talented enough to make these kind of tools far better than this blog author could do.The purpose of ISA is to provide the basic building blocks for them. A common set of blocks on which any people involved in software can rely at anytime and anywhere. |
In order to elaborate these “software life cycle facilities” and to avoid falling in the pitfall pointed by the challenge above, it appears that distinguishing 2 layers secures the approach :
- A basic layer, the foundations, where a set of artefact, of functions, of capabilities are incorporated in ISA to support all steps in a software life cycle. These blocks should not constrain the built solutions more that the needed elements for them to exist.
This layer is mandatory. The extensions tools and components are always built above of it. - A second common layer, built on top of the foundations, the “ground floor” providing basic functionalities to major types of users.
This layer is optional. The extensions could also be built on top of this layer.
Another aspect ISA should address is the continuity in the problem/solution chain thru specification/realisation and the abstraction levels.
The abstraction levels should be supported via multiples in depth succesive refinements (like in SADT/RT method). This approach should be preferred to isolated levels with traceability links between them.
The specifications and their realisation should be expressed in a global way in order to have a direct link between what thing is implementing what software feature.
All of that must be consistent in the two ways : top-down and bottom-up. The benefit of having that global consistency could be done by imposing a few artifacts and constraints.
Benefits list :
- Encompass the whole software life cycle.
- Provides a common base available anytime and anywhere.
- Be extensible at various levels.
- Global consistency in specifications and abstractions levels without traceability links.
Challenges
The constraints versus the extensibility, in other words reaching the good features mix, as explained above, is the more important challenge.
Identify the life cycle steps applicable at the widest range of software and organisations.
Not over complexify nor over simplify the features.
Well distinguish the foundation and ground floor layers.
Implanting global consistency in specifications and abstractions levels.