Scope
Taking a cue from Chris Aitchison’s post “You are NOT a Software Engineer!“, one can see system engineering more like a gardening activity, growing different kinds of components depending on changing contexts and concerns.
Along that reasoning, it is necessary to keep track of both business and system objects in situ in order to adjust locations along seasons and manage changes according to business weather. That would call for some planning, especially when contexts and objectives are bound to change all along the way, from requirements to deployment. Some language conventions are to be agreed, maps and itineraries should be selected, milestones arranged, crossroads identified, and assessment procedures settled upon.
Application vs System Engineering
Systems architecture combine software components with users and actual devices:
- Users (supposedly human beings) may be granted with organizational status and responsibilities, and possess symbolic communication capabilities.
- Software components and actual devices cannot be granted with organizational status or responsibilities, the former with symbolic communication capabilities, the latter without.
While system engineering is usually understood as dealing with software artifacts (aka applications), organization and communication are clearly critical. Yet, since organization and communication channels are not supposed to change with each application, system engineering must proceed along a dual track, one set by requirements, the other by architecture capabilities. Unfortunately that aspects is usually ignored by development methods.
Applications can be designed and implemented along staged (e.g waterfall) or iterative (aka agile) routines. In both approaches initial (requirements) models become useless once replaced by applications.
Such a fire-and-forget procedure is inadequate for systems because they must cohabit with contexts as described by initial models. As a consequence requirements models must be kept alive all along systems life-cycle.
Hardware vs Software
That view works fine with standalone applications but falls behind when there is no waterproof cordon between existing and planned systems. That, for instance, is the case for complex embedded systems as well as for Service Oriented Architectures (SOA).
Engineering Processes
Model Driven Engineering and Requirements
The proposed approach follows OMG’s Model Driven Architecture and can be implemented using the Unified Modeling Language.
Based upon a more precise understanding of model layers, it is driven by architectural features and, as a corollary, put analysis models at the hub of engineering processes.
Projects can then be characterized by their footprint and dependencies:
- Contexts can be irrelevant (standalone application), symbolic (services or data bases), or physical (embedded or industrial control systems).
- Footprint can be rooted in requirements, analysis, or design; they can include persistency, control, and/or boundaries.
For that purpose requirements should be properly organized as to to identify development profiles. Moreover, archetypal crossroads can be identified with consistent guidelines about modeling alternatives.