At the beginnings there were only objects as given by nature; then men (and women) saw them as artifacts that could be made on design. As communities set on making more complex products, calling for differentiated and sequenced tasks, they began to think about collaboration, and finally about engineering processes; projects were introduced as an afterthought.
In other words the meaning of work units is to be understood in relation to their arrangement into processes and they should be defined accordingly.
Aristotle’s Principle of the three unities
Likening processes to stories, work units can be defined using Aristotle’s three unities for drama:
- Unity of action: a work unit should have one main objective, be governed by a single authority, with one single outcome.
- Unity of place: developments should be executed into a space within which all resources can be addressed directly and accessed independently of physical constraints, and communication carried out without mediation.
- Unity of time: work units should be set within fixed and continuous time-frames and, once started, should proceed until completion independently of what may happen elsewhere. That is a necessity if innards and synchronization of tasks are to be managed independently of context contingencies.
Factors associated with contexts may also affect the sequencing of work units:
- Decisions falling under the authority of different organizational units.
- Geographical constraints bearing upon execution.
- Unpredictability of contexts and execution making intermediate milestones necessary.
Those rules are applied to project objectives in order to define work units and plan their execution.
That is especially critical if the maturity of development processes has to be assessed and improved. For that purpose work units must be associated to well-defined inputs and outputs and subject to sound metrics.
As far as software engineering is concerned, model based engineering frameworks can be used to define work units in terms of changes in development flows.
Layers & Views
The rationale behind model based system engineering is to replace procedural schemes by declarative ones and to define engineering processes in terms of artifacts transformation. That approach can be refined by regrouping artifacts and models according to architecture layers or views.
The layer perspective is best represented by the Model Driven Architecture (MDA) and its distinction between computation independent (CIMs), platform independent (PIMs), and platform specific (PSMs) models.
The view perspective put the focus on the nature of models and artifacts:
- Physical view: locations, agents, business objects and activities, events.
- Logical view: business domains and symbolic representation of persistent objects.
- Application view: applications, business logic, user interfaces.
- Process view: systems, processes and components.
When views are combined with model layers, the corresponding workshops keep their identity across layers, even if the focus is modified: e.g, agents remain active physical objects from requirements to deployment, whatever their implementation, or messages are symbolic objects independently of supporting communication mechanisms.
Customized tools, e.g UML diagrams, can be used to define work units, e.g requirements capture (use case and activity diagrams), use case realization (sequence and class diagrams), etc.
Yet, while views are well suited for model management, they may be confusing with regard to development due to their non-procedural nature, e.g Class or Sequence diagrams can be used indifferently along the development process. But, as noted above, development processes are all about sequencing tasks and, for that purpose, work units must be directly associated to development flows.
Development Flows & Model Layers
Once business and technical risks are properly assessed, the organization of development workflows should distinguish between internal and external constraints:
- Internal (aka technical) constraints deal with contents: requirements, architectures, models, code, deployment, etc.
- External (aka organizational) constraints deals with responsibilities: stakeholders, users, administrators, contractors, etc.
Ideally projects should go “hand in hand”, with work units consistently defined on both technical and organizational basis. That is seldom the case, as illustrated by arguments about the respective benefits of Agile and Phased development models. Yet, significant advances are possible if development profiles and strategies are designed along model layers.
While that’s the idea behind phased approaches, they often falls short of their objectives due to their coarse granularity: work units are just catch-all development phases without precise anchor to development flows.
From Development Flows to Work Units
Traditional approaches to work breakdown overlook the very issue they are supposed to deal with, namely process design:
- Waterfall approaches take for granted that one-fits-all organization and predefined activities can be configured to the needs of most of the projects.
- Agile approaches assume that expertise and best practices combined with responsibility and team work can do without explicit development processes.
Yet, steady grounds (duly defined procedures) and agility (lean and versatile processes) should bring cross benefits, providing engineering processes were designed from development flows.
Manufacturing processes, built from material flows and engineering constraints, have demonstrated the efficiency of flow-based approaches. As it happens, software engineering hasn’t followed suit and work units are still defined using customized versions of the same catch-all activities.
- Flow-based: work breakdown starts with production steps and builds processes bottom-up, depending upon constraints.
- Activity-based: work breakdown starts with one-fits-all organization, follows top-down with predefined activities, which are then entrusted with production objectives.
Flow-based development can be directly driven by users requests when these can be fully set under a shared ownership, otherwise cross dependencies between organizational units will have to be managed through models.
From Work Units to Development Processes
Work units for each architecture layer can be organized as trees built according a single blueprint:
- Roots support management, acceptance, and communication between layers.
- Intermediate nodes support specifications (top down) and integration and tests (bottom up)
- Leafs support the actual production of artifacts.
Execution is supposed to proceed depth-first from roots but the explicit management of sub-trees is to be set by organization: phased projects will manage all, agile ones will only manage the roots.
With work units directly rooted in development flows, tasks can then be organized according contexts and concerns: enterprise architecture and computation independent models (CIMs), functional architecture and platform independent models (PIMs) , software architecture and platform specific models (PSMs) , technical architecture and deployment models.
With the benefits of such traceability processes can be organized according problems (what is to be developed) and solutions (how it may be done), e.g.:
- Migration: change of technical architecture.
- Refactoring: change of software architecture.
- New client application.
- New application: server and client.
- New service.
Iterative Development Processes
Perhaps the most significant benefit of defining work units bottom up from development artifacts is that it brings iterative and procedural schemes under the same declarative paradigm: if work units can be finely tuned to the granularity of artifacts considered, developments can be carried out step by step or surgically according to the status of artifacts.
- Thread: Project Management
- Thread: MBSE
- Agile and Models
- Conceptual Thesaurus: Overview
- Conceptual Thesaurus: Typical Use Cases