While the scope of agile principles extends far beyond the eponymous methods, some of them are more specific and their applicability contingent on contexts and objectives; two of them are especially important as they entail very specific assumptions with regard to time and space:
Continuous delivery of valuable software.
Direct collaboration between software users and developers all along the development process.
Continuity and collaboration (H. Zamora)
Time Capsules vs Time Scales
If time is seen as a discrete gauge introduced to sequence events, it ensues that continuity indicates that no external events are to be taken into account. In other words, once its objectives have been set, software development must be carried out according its own pace, whatever happens in business context and enterprise organization. That’s a pretty strong assumption that should be explicitly endorsed by stakeholders and users.
Interestingly, this assumption can be set against fixed requirements and upfront design associated with waterfall approaches, as if development policies were to be set between two alternative options:
Time capsules: projects deal with changing requirements subject to frozen business context and organization.
Time scales: projects deal with frozen requirements subject to planned changes in business context and organization.
A pragmatic approach should take the best of each option: put limited and self-contained objectives into capsules and organize capsules along scales.
Collaborative vs Procedural Spaces
The reason for processes is that tasks cannot be carried out simultaneously, and the reason for human contribution is that some tasks involve decision-making based on circumstances and provisos that cannot be determined upfront.
Those decisions may concern different domains of concerns with their respective objectives and roles: business requirements, systems functionalities, or technical implementations. Agile and phased approaches clearly disagree about how those decisions are to be taken and conveyed along processes and across organizational spaces, the former ruling that all the parties should deal with them jointly, the latter opting for a separation of concerns. As a counterpart to time continuity, agile recommendation implies some continuity across organizational spaces that cannot be taken for granted. Whether that proviso can be met will determine the choice of a development policy:
Collaborative: problems are solved and decisions taken through collaboration between parties within a single organizational space.
Procedural: parties deal separately with problems and decision-making within their respective organizational spaces, and communication between those spaces is carried out through prearranged channels.
Those options clearly depend on organizational and technical environments, hence the benefits of charting projects with regard to constraints on ownership and delivery.
Charting projects: Ownership and Delivery
Given that choosing the right development model is a primary factor of success, decision-making should rely on simple and robust criteria. First, if decisions are to be taken and implemented collectively, shared governance has to be secured. Second, if deliveries are to be carried out continuously, projects shouldn’t be dependent on external events.
When charted with regard to ownership and delivery, projects can be regrouped into four basic categories:
Business requirements with distinct stakeholders and objectives directly associated with business value (a).
Business requirements with objectives and business value involving separate stakeholders (b).
Functional requirements targeting features used by different applications (c).
Non functional requirements targeting features used by different applications across different systems (d).
Charting projects with regard to ownership and delivery constraints
That straightforward taxonomy provide clear guidelines for project managers: options (a) and (d) associated respectively with agile and phased approaches, and options (b) and (c) to be decided with regard to actual projects, the ability of organizations to accomodate particular development schemes, and long term objectives regarding engineering processes.
The Agile development model as pioneered by the eponymous Manifesto is based both on universal principles meant to be applied in any circumstances, and on more specific ones subject to some prerequisites. Sorting out the provisos may help to extend and improve the agile footprint.
The flexibility of Agile principles (E. de Souza)
Checklist
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Scope: Specific to agile development model.
Requisite: Iterative and incremental development.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Scope: Universal.
Requisite: Requirements traceability and modular design.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Scope: Universal.
Requisite: Modular design and incremental development.
4. Business people and developers must work together daily throughout the project.
Scope: Specific to agile development model.
Requisite: Shared ownership, no external dependencies.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Scope: Universal.
Requisite: Dedicated organization and human resources policy.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Scope: Universal.
Requisite: Corporate culture.
7. Working software is the primary measure of progress.
Scope: Universal.
Requisite: Quality management and effective assessment of returns and costs.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Scope: Universal.
Requisite: Dedicated project management and human resources policy.
9. Continuous attention to technical excellence and good design enhances agility.
Scope: Universal.
Requisite: Corporate culture and human resources policy.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
Scope: Universal.
Requisite: Quality management and corporate culture.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Scope: Universal.
Requisite: Shared ownership and no external dependencies.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Scope: Universal.
Requisite: Dedicated organization and corporate culture
Assessment
Perhaps surprisingly, only two (#1 and #4) out of twelve principles cannot be applied universally as they clearly conflict with phased processes and tasks differentiation. In other words ten out of twelve of the agile principles could bring benefits to all and every type of project.
When interacting with systems, users do things they aren’t supposed to do and walk along irrelevant, even unthinkable, paths that can put tests designers at a loss. This apparent chink between users’ conscious self and their fingertips can be explained by the way humans assess situations and make decisions. Curtailing it is the aim of ergonomics.
Anatomy of Errors: from brain to fingers (Rembrandt)
Taking a leaf from A. Tversky and D. Kahneman (who received the 2002 Nobel Prize in Economics), decision-making relies on two cognitive mechanisms:
The first one “operates automatically and quickly, with little or no effort and no sense of voluntary control”. It’s put in use when actual situations must be assessed and decisions taken rapidly if not instantly.
The second one “allocates attention to the effortful mental activities that demand it, including complex computations”. It’s put in use when situations can be assessed with regard to past experience in order to support informed decisions making.
That distinction can be directly applied to users’ behaviors interacting with systems:
Intuitive behavior: decisions are taken on the basis of the visual context and options as presented by users interfaces before taking into account underlying business contents and logic.
Rational behavior: decisions are taken on the basis of business contents and logic disregarding supporting systems interfaces.
Set in context, that distinction can be put in parallel (but not confused) with the one between domain and functional requirements, the former dealing rationally with business objects and logic, the latter putting the former to use through interactions with supporting systems.
Functional requirements describe the part played by supporting systems
Assuming that business logic should not be contingent on supporting systems interfaces, the best option would be to test its implementation independently of users interactions; moreover, tests targeting intuitive behaviors (i.e not directly based on domain specific contents), could then be generated automatically.
Looking for Errors
Given that testing is meant to find flaws in deliverables, tests are certainly more effective when designers know what they are looking for.
For that purpose phased approaches rely on sequences of differentiated tests dealing successively with programming (unit tests), functional requirements (integration tests), and business requirements (acceptance tests). The unfortunate downside of those policies is that the most wide-ranging flaws are the last to be looked for, with the risk of being found after cascading and costly consequences for functionalities and programs.
Phased and Iterative approaches to tests
Conversely, agile approaches follow iterative policies, with each development cycle combining the definition, programming, and tests of software products. When properly implemented those policies significantly improve the early detection and correction of errors whatever their origin. Yet, since there is no explicit management of intermediate outcomes, it’s difficult to differentiate the tests according the kind of errors to look for, e.g faulty business rules implementation or flawed user interface.
Architecture driven approaches may provide an answer, with requirements unambiguously sorted out depending on their architectural footprint: business contents or system functionalities. As a corollary, tests could also be designed along the same lines, targeting business rationale or human behavior.
Errors in Mirrors
Acceptance tests being performed with regard to requirements, they should be designed along requirements taxonomy, respectively for business logic, users’ interactions, quality of services, and components implementation. Being aligned on requirements, those tests can be neatly defined with regard to closed sets of specifications, functional or otherwise.
Functional tests have to expect the unexpected
But that’s not the case for users’ interactions because people behaviors are not fully predictable; hence, while tests can be systematically designed with regard to the set of users’ actions framed by business and functional requirements, there is no way to comprehensively and unambiguously check for all and every possible behavioral contingencies. That will make for three levels of functional tests:
Implementation of business logic: tests should be designed directly from business requirements, independently of interactions with users.
Implementation of scenarii: while interactions are defined in reference to business logic, their validation should focus on the presentation of contents and dialog control.
Users exceptions: in addition to inputs validity, already checked with business logic, and users’ actions, supposedly secured by interaction scenarii, it is necessary to check that unexpected behaviors have been properly considered .
How to check that unexpected behaviors have been properly considered ?
In other words, functional tests will have to look simultaneously for errors in software (defined with regard to a finite set of requirements), and for users’ mistakes (set in an open range of behaviors). As if tests designers were to mirror users errors in order to look for software ones. So, assuming that errors in business logic and interactions have been considered, what should still be checked, and how ?
Fingertips Errors
When faced with choices, users bank on mental maps combining graphical and business layers, with the implicit assumption that maps’ contexts and concerns are kept up to date. Those maps combine three communication mechanisms:
Languages, natural or specific, use syntax and semantics to define business contents, logic, and operations.
Icons use similarity for the visual representation of business operations or functional primitives (e.g create, delete, etc).
Signals use proximity to draw users’ attention to predefined events (e.g sounds for operations completion or incoming emails).
While language-based interactions are supposedly fully covered by business and functional tests, icons and signals make room for “fingertips” reactions which cannot be directly framed within business logic or functional scenarii, and therefore cannot be comprehensively checked for erroneous behaviors.
Icons and signal based communication can trigger unexpected behaviors.
Yet, if instinctive reactions preclude rational considerations, decisions may be swayed by analogies and associations before being informed by the relevant business contents. To prevent that risk, test scenarii built on business logic and functional interactions should be extended in order to take into account the intuitive aspects of users’ behaviors.
Mental Maps & Automated Tests
As noted above, mental maps are built on three layers, one deep (language semantics) and two shallow (icons and signals). While the shallow layers are supposed to reference the deep one, icons and signals may induce instinctive behaviors independently of the referenced business logic. Those behaviors can be triggered by two kinds of mechanisms:
Analogy: users will look for similarities and familiar configurations.
Proximity: users will look for continuity with regard to scope and operations.
Clearly, lapses in such behaviors will normally escape tests designed for business and functional requirements; yet, by being driven by self-contained mechanisms, intuitive behaviors can be checked independently of references to business contents. And that may open the door to automated tests generation.
With regard to similarities, tests should look for possible confusion between:
Objects with common representation but specific features (inheritance).
Operations with shared semantics but different scope (polymorphism).
Sequences with shared operations but different timing .
With regard to proximity, tests should look for possible confusion between:
Objects and their parts, or between their parts (structural proximity).
Operations usually associated into the same activity (functional proximity).
Operations usually executed successively (chronological proximity).
Scripts for such tests could be generated through pattern-matching and run by wizard applications.
A theory (aka model) is a symbolic description of contexts and concerns. A practice is a set of activities performed in actual contexts. While the latter may be governed by the former and the former developed from the latter, each should stand on its own merits whatever its debt to the other.
Good practices hold sway without showing off theoretical subtext (Demetre Chiparus)
With regard to Software Engineering, theory and practice are often lumped together to be marketed as snake oil, with the unfortunate consequence of ruining their respective sways.
Software Engineering: from Requirements heads to Programs tails
While computer science deals with the automated processing of symbolic representations, software engineering uses it to develop applications that will support actual business processes; that may explain why software engineering is long on methods but rather short on theory.
Yet, since there is a requirements head (for business processes) to the programming tail (for automated processing), it would help to think about some rationale in between. Schools of thought can be summarily characterized as formal or procedural.
How to make program tails from requirements heads
Formal approaches try to extend the scope of computing theories to functional specifications; while they should be the option of choice, their scope is curtailed by the lack of structure and formalism when requirements are expressed in natural languages.
Procedural approaches deal with the difficulty of capturing users requirements by replacing theoretical assumptions about software artifacts with guidelines and best practices for modus operandi. The fault here is that the absence of standardized artifacts makes the outcomes unyielding and difficult to reuse.
Procedural (p), formal (f), and agile (a) approaches to software development.
Pros and cons of those approaches point to what should be looked for in software engineering:
As illustrated by Relational theory and State machines, formal specifications can support development practice providing requirements can be directly aligned with computing.
As illustrated by the ill-famed Waterfall, development practices should not be coerced into one-fits-all procedures if they are to accommodate contexts and tasks diversity.
Agile answers to that conundrum have been to focus on development practices without making theoretical assumptions about specifications. That left those development models halfway, making room for theoretical complements. That situation can be clarified using Scott Ambler’s 14 best practices of AMDD:
Active Stakeholder Participation / How to define a stakeholder ?
Architecture Envisioning / What concepts should be used to describe architectures and how to differentiate architecture levels ?
Document Continuously / What kind of documents should be produced and how should they relate to life-cycle ?
Document Late / How to time the production of documents with regard to life-cycle ?
That would bring the best of two world, with practices inducing questions about the definition of development artifacts and activities, and theoretical answers being used to refine, assess and improve the practices.
Takes Two To Tango
Debates about the respective benefits of theory and practice are meaningless because theory and practice are the two faces of engineering: on one hand the effectiveness of practices depends on development models (aka theories), on the other hand development models are pointless if not validated by actual practices. Hence the benefits of thinking about agile practices.
Along that reasoning, some theoretical considerations appear to be of particular importance for good practice:
Enterprise architecture: how to define stakes and circumscribe organizational responsibilities.
Systems architecture: how to factor out shared architecture functionalities.
Products: how to distinguish between models and code.
Metrics: how to compare users’ value with development charge.
Release: how to arbitrage between quality and timing.
Such questionings have received some scrutiny from different horizons that may eventually point to a comprehensive and consistent understanding of software engineering artifacts.
Contrary to its manufacturing cousin, a long time devotee of preventive policies, software engineering is still ambivalent regarding the benefits of integrating quality management with development itself. That certainly should raise some questions, as one would expect the quality of symbolic artifacts to be much easier to manage than the one of their physical counterparts, if for no other reason than the former has to check symbolic outcomes against symbolic specifications while the latter must also to overcome the contingencies of non symbolic artifacts.
Walking Quality Hall (E. Erwitt)
Thanks to agile approaches, lessons from manufacturing are progressively learned, with lean and just-in-time principles making tentative inroads into software engineering. Taking advantage of the homogeneity of symbolic development flows, agile methods have forsaken phased processes in favor of iterative ones, making a priority of continuous and value driven deliveries to business users. Instead of predefined sequences of dedicated tasks, products are developed through iterations regrouping definition, building, and acceptance into the same cycles. That push differentiated documentation and models on back seats and may also introduce a new paradigm by putting tests on driving ones.
From Phased to Iterative Tests Management
Traditional (aka phased) processes follow a corrective strategy: tests are performed according a Last In First Out (LIFO) framework, for components (unit tests), system (integration), and business (acceptance). As a consequence, faults in functional architecture risk being identified after components completion, and flaws in organization and business processes may not emerge before the integration of system functionalities. In other words, the faults with the more wide-ranging consequences may be the last to be detected.
Phased and Iterative approaches to tests
Iterative approaches follow a preemptive strategy: the sooner artifacts are tested, the better. The downside is that without differentiated and phased objectives, there is a question mark on the kind of specifications against which software products are to be tested; likewise, the question is how results are to be managed across iteration cycles, especially if changing requirements are to be taken into account.
Looking for answers, one should first consider how requirements taxonomy can support tests management.
Requirements Taxonomy and Tests Management
Whatever the methods or forms (users’ stories, use case, functional specifications, etc), requirements are meant to describe what is expected from systems, and as such they have two main purposes: (1) to serve as a reference for architects and engineers in software design and (2) to serve as a reference for tests and acceptance.
With regard to those purposes, phased development models have been providing clearly defined steps (e.g requirements, analysis, design, implementation) and corresponding responsibilities. But when iterative cycles are applied to progressively refined requirements, those “facilities” are no longer available. Nonetheless, since tests and acceptance are still to be performed, a requirements taxonomy may replace phased steps as a testing framework.
Taxonomies being built on purpose, one supporting iterative tests should consider two criteria, one driven by targeted contents, the other by modus operandi:
With regard to contents, requirements must be classified depending on who’s to decide: business and functional requirements are driven by users’ value and directly contribute to business experience; non functional requirements are driven by technical considerations. Overlapping concerns are usually regrouped as quality of service.
Requirements with regard to Acceptance.
That distinction between business and architecture driven requirements is at the root of portfolio management: projects with specific business stakeholders are best developed with the agile development model, architecture driven projects set across business domains may call for phased schemes.
That requirements taxonomy can be directly used to build its testing counterpart. As developed by D. Leffingwell (see selected readings), tests should also be classified with regard to their modus operandi, the distinction being between those that can be performed continuously along development iterations and those that are only relevant once products are set within their technical or business contexts. As it happens, those requirements and tests classifications are congruent:
Units and component tests (Q1) cover technical requirements and can be performed on development artifacts independently of their functionalities.
Functional tests (Q2) deal with system functionalities as expressed by users (e.g with stories or use cases), independently of operational or technical considerations.
System acceptance tests (Q3) verify that those functionalities, when performed at enterprise level, effectively support business processes.
System qualities tests (Q4) verify that those functionalities, when performed at enterprise level, are supported by architecture capabilities.
Tests Matrix for target and MO (adapted from D. Leffingwell).
Besides the specific use of each criterion in deciding who’s to handle tests, and when, combining criteria brings additional answers regarding automation: product acceptance should be performed manually at business level, preferably by tools at system level; tests performed along development iterations can be fully automated for units and components (black-box), but only partially for functionalities (white-box).
That tests classification can be used to distinguish between phased and iterative tests: the organization of tests targeting products and systems from business (Q3) or technology (Q4) perspectives is clearly not supposed to be affected by development models, phased or iterative, even if resources used during development may be reused. That’s not the case for the organization of the tests targeting functionalities (Q2) or components (Q1).
Iterative Tests
Contrary to tests aiming at products and systems (Q3 and Q4), those performed on development artifacts cannot be set on fixed and well-defined specifications: being managed within iteration cycles they must deal with moving targets.
Unit and components tests (Q1) are white-box operations meant to verify the implementation of functionalities; as a consequence:
They can be performed iteratively on software increments.
They must take into account technical requirements.
They must be aligned on the implementation of tested functionalities.
Iterative (aka development) tests for technical (Q1) and functional (Q2) requirements.
Hence, if unit and component tests are to be performed iteratively, (1) they must be set against features and, (2) functional tests must be properly documented and available for reuse.
Functional tests (Q2) are black-box operations meant to validate system behavior with regard to users’ expectations; as a consequence:
They can be performed iteratively on software increments.
They don’t have to take into account technical requirements.
They must be aligned on business requirements (e.g users’ stories or use cases).
Assuming (see previous post) a set of stories (a,b,c,d) identified by alternative paths built from features (f1…5), functional tests (Q2) are to be defined and performed for each story, and then reused to test the implementation of associated features (Q1).
Functional tests are set along stories, units and components tests are set along features.
At that point two questions must be answered:
Given that stories can be changed, expanded or refined along development iterations, how to manage the association between requirements and functional tests.
Given that backlogs can be rearranged along development cycles according to changing priorities, how to update tests, manage traceability, and prevent regression.
With model-driven approaches no longer available, one should consider a mirror alternative, namely test-driven development.
Tests Driven Development
Test driven development can be seen as a mirror image of model driven development, a somewhat logical consequence considering the limited role of models in agile approaches.
The core of agile principles is to put the definition, building and acceptance of software products under shared ownership, direct collaboration, and collective responsibility:
Shared ownership: a project team groups users and developers and its first objective is to consolidate their respective concerns.
Direct collaboration: decisions are taken by team members, without any organizational mediation or external interference.
Collective responsibility: decisions about stories, priorities and refinements are negotiated between team members from both sides of the business/system (or users/developers) divide.
Assuming those principles are effectively put to work, there seems to be little room for organized and persistent documentation, as users’ stories are meant to be developed, and products released, in continuity, and changes introduced as new stories.
With such lean and just-in-time processes, documentation, if any, is by nature transient, falling short as a support of test plans and results, even when problems and corrections are formulated as stories and managed through backlogs. In such circumstances, without specifications or models available as development handrails, could that be achieved by tests ?
Given the ephemeral nature of users’ stories, functional tests should take the lead.
To begin with, users’ stories have to be reconsidered. The distinction between functional tests on one hand, unit and component tests on the other hand, reflects the divide between business and technical concerns. While those concerns may be mixed in users’ stories, they are progressively set apart along iteration cycles. It means that users’ stories are, by nature, transitory, and as a consequence cannot be used to support tests management.
The case for features is different. While they cannot be fully defined up-front, features are not transient: being shared by different stories and bound to system functionalities they are supposed to provide some continuity. Likewise, notwithstanding their changing contents, users’ stories should be soundly identified by solution paths across problems space.
Paths and Features can be identified consistently along iteration cycles.
That can provide a stable framework supporting the management of development tests:
Unit tests are specified from crosses between solution paths (described by stories or scenarii) and features.
Functional tests are defined by solution paths and built from unit tests associated to the corresponding features.
Component tests are defined by features and built by the consolidation of unit tests defined for each targeted feature according to technical constraints.
The margins support continuous and consistent identification of functional and component tests whose contents can be extended or updated through changes made to unit tests.
One step further, and tests can even be used to drive iteration cycles: once features and solution paths soundly identified, there is no need to swell backlogs with detailed stories whose shelf life will be limited. Instead, development processes would get leaner if extensions and refinements could be directly expressed as unit tests.
System Quality and Acceptance Tests
Contrary to development tests which are applied iteratively to programs, system tests are applied to released products and must take into account requirements that cannot be directly or uniquely attached to users stories, either because they cannot be expressed from a business perspective or because they are shared concerns and best described as features. Tests for those requirements will be consolidated with development ones into system quality and acceptance tests:
System Quality Tests deal with performances and resources from the system management perspective. As such they will combine component and functional tests in operational configurations without taking into account their business contents.
System Acceptance Tests deal with the quality of service from the business process perspective. As such they will perform functional tests in operational configurations taking into account business contents and users’ experience.
Development Tests are to be consolidated into Product and System Acceptance Tests.
Requirements set too early and quality checks performed too late are at the root of phased processes predicaments, and that can be fixed with a two-pronged policy: a preemptive policy based upon a requirements taxonomy organizing problem spaces according concerns business value, system functionalities, components designs, platforms configuration; a corrective policy driven by the exploration of solution paths, with developments and releases driven by quality concerns.
Tests & Framework
Insofar as large and complex enterprise architectures are concerned, it’s safe to assume that different development models (agile or phased) and tests policies (unit, system, acceptance, …) will have to be cohabit, and that would not be possible without an architecture framework:
Development or unit tests are defined at platform level and applied to software components.
Integration or system tests are defined at system level and built from tested components.
Acceptance tests are defined at enterprise level and built from tested functionalities.
Development processes start with requirements and wind up in code; in between there isn’t much of a consensus among the software engineering community about how to define the scope (spaces), how to sequence the tasks (paths), and how to time deliveries (paces). On one side of the debate phased approaches hope for fixed spaces and ordered paths but often get entangled in moving lines. On the other side of the debate agile teams try to find their space by increments but risk losing the path while still on their way.
Maze revisited: finding a path while building the space (Ibrahim El-Salahi)
This lack of agreed upon concepts and principles entrusts personal skills and best practices as primary success factors. Conversely, that could explain the rate of failures for software projects, significantly higher than for “hard” engineering ones; given the quasi absence of physical constraints, the opposite would have been expected, which would suggest some critical intrinsic flaw.
With the “benefits” of hindsight and agile assessment of waterfall flaws, the focus has been put on fixed scope and schedule, in particular with regard to requirements and quality management:
Fixed requirements set upfront: since there is an inverse relationship between the level of details and the reliability and stability of requirements, staking the whole project on requirements fully defined at such an early time is arguably a very hazardous policy.
Quality as an afterthought: given that finding defects is not very gratifying when undertaken in isolation, delegating the task will offer few guarantees if not associated with rewards commensurate to findings; moreover, quality as a detached concern may easily turn into a collateral damage when set along mounting costs and scheduling constraints. Alternatively, quality checks may change into a more positive endeavor when conducted as an intrinsic part of development.
Agile answer to those failings has been to conduct specifications, development, and quality assurance into integrated iterations. As a consequence, the definition of scope becomes a byproduct of development cycles, with requirements itemized as features in order to be developed progressively. Moreover, with specifications and schedules managed dynamically, timetables become impracticable and deliveries can only be carried out by shuttles.
The agile “reformation” has open new perspectives and beget many fruitful practices, and the objective here is to see how those approaches of scope and schedule can be reformulated within the perspective of architecture layers. This part examines the congruence between the alternate flows of use cases and the backlog of users’ stories, and considers their complementarity as path-finders. The second part will focus on the role of time-boxes as pace-makers and the benefits for quality assurance.
Architectures and Projects Scope
Whatever the compass, agile or phased, projects footprint can be set across three architecture layers:
Enterprise architectures describe business environments and objectives, resources and regulatory constraints.
System architectures describe enterprises in terms of functional entities of human agents and physical and software assets.
Technical architectures describe the platforms supporting functional entities.
Architecture layers vs Processes
Projects are meant to carry out changes within architectures initiated by business, engineering, or services management processes:
Business processes are defined by business environment and objectives. Changes may have to deal with domains and activities, organization and supported operations, and quality of service as experienced by users.
Engineering processes focus on the development of software systems supporting business processes: business domains and applications, system functionalities, platform implementations.
Services management stand between engineering deliveries and operational concerns: location of assets, access to services, releases deployment, and systems configuration.
While development projects may (and will usually) cross architecture layers, their roots and stakes should nonetheless be clearly positioned if projects are to be planned within the respective time-spans, governed by the relevant authority, and their products accepted by the right stakeholders.
Development Project, from Requirements to Deployments
That put projects governance at crossroads between (a) business objectives set by market opportunities, (b) the deployment of features into functional architectures, and (c) the deployment of releases according to changes in technical architecture. With phased developments, scope and schedules are fixed upfront, which means that the business layer forces its time-frame over the ones of system and technical layers, which may introduce frictions regarding scope as well as quality:
With regard to scope, frictions stem from features and schedules set fully and definitively at enterprise level, independently of any feedback from functional and technical layers.
With regard to quality, frictions stem from tests performed at technical layer when scope and schedules can no longer be revised in case of negative outcomes.
The consequences are all too easy to observe, with business needs partially satisfied and software quality sacrificed. Hence the need of a balanced approach that would consolidate the different maps and time-frames in order to minimize frictions between layers.
Mapping Project Scope
Projects scope can be described along two dimensions, one set by business logic, the other by system functionalities:
First, one have to circumscribe the business variants to be taken into consideration. For that purpose the project footprint, first introduced as users’ stories, will have to be documented by activity or business process diagrams.
Then, the project scope will have to mark out the subset of business requirements to be supported by system functionalities. That will usually be done with use cases describing interactions between system and users.
Complementary descriptions of projects footprints: use cases (interactions between users and system) and activity diagrams (business logic).
That makes those descriptions both orthogonal and complementary: orthogonal because use cases cut across activity diagrams, complementary because use cases are meaningless without targeted activities.
More importantly, they are associated with different architecture layers and governed by different concerns:
At business level (business processes or activities), the perimeter and granularity of requirements must be congruent with the continuity and consistency constraints of business objects and operations.
At functional level (use cases), the span and granularity of interactions between system and users must coincide with execution paths. But the rationale governing users interactions is not the same as the one governing the integrity of business processes. As a consequence, the paths considered for development may pick sequences of operations defined by business processes but should not define them anew based upon interaction constraints.
Finally, assuming that use cases see systems as black-boxes, their footprint should not depend on decisions taken at technical level.
Those concerns can be dealt with separately if projects scope is explored iteratively, e.g using activity diagrams for business logic and use case diagrams for users interactions.
Iterative Mapping of Project Footprint
Iterative development is not just about increments but, first and foremost, about exploring development spaces. That is especially useful when projects overlap architecture layers and cannot rely on fully fledged requirements.
Such projects have to deal with two challenges:
They must identify and manage work units according to the state of requirements and the nature of dependencies (business, organization, or technology, …).
They must carry on with developments based on incomplete specifications while exploring alternatives and deferring decisions until the “last responsible moment” when further delay would limit the options at hand.
Taking a leaf out of the agile book, projects should be driven by users’ value, with requirements first introduced as users’ stories. From that springboard, as informal and incomplete as could be, stories must be fleshed out and organized in order to support the reasoned exploration of project scope.
At inception stories are no more than a user, an objective, and an activity, all set at business level independently of the part played by systems. Scope exploration must therefore begin with activities backbone and be furthered with variants, aka scenarii.
Adding execution paths to project scope
Given a set of business scenarii, the candidates for system support must be ordered and mapped to system features, actual or planned. That should provide a blueprint for development paths. Unfortunately, as variants are added to plots, narratives can easily turn messy, mixing features and capabilities across architecture layers. And that’s where the benefits of use cases are to be found.
Development Paths: From Users’ Stories to Use Cases
Whatever the context, iterations are formal constructs defined by invariants, increments, and exit conditions. When applied to development spaces, iterations are defined by:
Invariants: conditions on architectural assets supporting the scenario under consideration.
Increments: features or variants added to scenarii.
Exit condition: no more features or variants (empty backlog) or time-out.
Applied to architecture layers, invariants provide for reasoned iterations and backlogs:
Enterprise layer are the first to be considered: cycles are set for persistency and execution units and bound by domains (identification mechanisms, integrity constraints, and semantics); within cycles, increments target attributes, operations and variants.
Functional layer come second: cycles are set for interaction units (aka use cases), and bound by the continuity and consistency business objects and activities; increments target transient attributes and operations.
Technical layer come last: cycles are set for platforms and bound by functional units.
But there is a catch: while users’ stories and activity (or business process) diagrams are set at enterprise level, development projects are considered at system level; because systems functionalities are not supposed to appear in users’ stories or activity diagrams, there could be a gap between business and functional requirements. As it happens, use cases provide a bridge: on one hand they focus on the interactions between users and systems, on the other hand their basic and alternate flows can be directly mapped to the paths in activity diagrams.
From alternative flows to Development Paths
That provides a clear and sound basis for the definition of development paths: on one hand alternate flows can be ranked according users’ priorities; on the other hand they determine the sequence of use cases that will have to be developed.
Backlogs and Pathfinders
While the objective of users’ stories is to tie up projects in business value, the objective of use cases is to anchor them in the context of system functionalities. That perspective, and the role of models, may be ignored for standalone projects, but it is necessary when project development paths are to be governed both by business and functional dependencies, described respectively by users’ stories and use cases.
In that case the exploration of development paths should be guided by invariants set along MDA model layers: computation independent (business processes), platform independent (systems functionalities), and platform specific (technology platforms).
Projects are rooted in use cases but development paths are governed by users’ stories.
When projects are rooted in business activities (a), e.g the possibility of upgrading a customer, stories describe execution paths and are ranked according business priorities. Iterations will proceed with development and new cycles added for alternative paths to the basic one.
Depending on context dependencies, development projects can be directly initiated from given sequences of activities (b) or conducted in parallel with users’ stories. Use cases remain the option of choice when the features supporting users’ stories are meant to be shared (e.g checkout). In that case the development paths are governed both by users’ value and functional dependencies. When features are deemed specific (e.g upgrade), use cases can be bypassed and development paths explored simultaneously according users’ and development concerns.
Backlog organization is more complex when development paths cross the divide between functional and technical concerns. Ideally, one would expect a clear separation of concerns, with use cases defined independently of technical options, just like business logic doesn’t depend on system functionalities. But alternatives may be blurred due to the dependencies between interactions design and platform capabilities, the risk being to associate technical options with functional variants, e.g specialized use cases.
Entangled development paths: self check out depends on technical platform.
That’s the case when features can only be implemented on specific platforms. If those features are also specific the corresponding development cycle can be managed as a whole. Otherwise the relevant decisions should be factored out. The same principle applies for features supporting different business processes.
Squaring the Circles: From Epics to Releases
Iterations run within boundaries set by invariants, and with regard to projects scope, those invariants are set by architecture capabilities: enterprise on one hand, systems on the other hand.
From the enterprise perspective, development projects (b) are meant to support business objectives (a), not to define them. As a consequence, users’ stories must remain within borders set upfront. That can be achieved by introducing business projects (aka strategies, aka epics) and portfolios of development ones.
Development Paths: Portfolio of business objectives (a), associated backlogs of users’ stories (b), targeted features (c), architectural capabilities (d), and releases (e).
From the system perspective, a clear distinction should be maintained between projects supported by platforms capabilities (b), and projects targeting platforms capabilities (d). Eventually, those different levels of explorations will have to be consolidated as releases (e), and that is where one may find the agile answer to waterfall.
A Time for Every Purpose: Time-boxes as Pace-Makers
As Einstein famously said, “The only reason for time is so that everything doesn’t happen at once.” In other words time is what happens between events, and the use of a single time-frame will put all events under the same rationale.
But architectures are best understood as shearing layers whose events are governed by different rationales, respectively: business opportunities, engineering constraints, or operational needs.
That is arguably the critical flaw of waterfall solutions as they force business, development, and operations under the same set of strictures. And that’s why agile’s solution to components release may be its pivotal innovation as it establishes the autonomy of those three layers and introduces time-boxes as their pace-makers.
As previously noted, embarking for sizable and lengthy project on the assumption that detailed scope and schedules can be set upfront is a very hazardous policy. Alternatively, agile development models carry out specifications, development, and quality assurance into integrated iterations, making room for a progressive exploration of problem spaces and solution paths, and consequently for informed decision-making and better risk management.
Paths & Paces (S.Dali)
Yet, whatever the method, at some point, scope and features will have to be committed; and with targeted features set dynamically, planned schedules are no more an option. Hence the need to reconsider the way time is taken into account.
Dependencies: Playing for Time
Paraphrasing Einstein, one may say that the only reason for processes is so that everything doesn’t happen at once. Why is that ?
First, processes are meant to support informed decisions. If problem spaces and solution paths cannot be settled upfront they must be done progressively. And that will clearly introduce informational dependencies supporting:
Decisions about what is to be done: alternative paths and their priorities
Decisions about how it should be done: supported features and their priorities
Decisions about how it can be done: quality assurance and acceptance.
In that context the objective of development processes is to do as much of definition, building, and acceptance, and to delay decisions in order to gather the most of the relevant information until the “last responsible moment”, i.e without preempting any of the initial set of alternative options.
Assuming informed decisions are supported by architecture knowledge, processes must take into account engineering constraints regarding:
Technical dependencies associated to the nature of development flows and environments.
Functional dependencies associated to products functionalities and supporting systems.
Organizational dependencies associated to business units and localization.
Iterating across architecture layers
While those dependencies are defined within architecture layers, their impact on the organization of work units may have to be consolidated when projects are carried out across layers.
Schedules: Running for Time
Whether development cycles stay within or run across architecture layers, there will be no way to decide about deliveries and schedules at project inception. In other words dependencies will have to be sorted out and planning settled along the road.
Project planning means consolidating overlapping time-frames. That may not be a problem for projects set within single architecture layers (e.g migration), but that should definitively be taken into account when heterogeneous time-frames govern changes across architecture layers. With regard to changes managed at project level (endogenous events), the consolidation may be done within project time-frame; but that will not be possible for changes occurring in non managed environments (exogenous events).
Those events are set in time-frames governed by their own rationale (e.g business, organization, or technology) that cannot be subsumed into the engineering timetable:
At enterprise level, time is set by business context. Both business objectives and business process solutions are meant to be decided with regard to actual (aka exogenous) business opportunities (a).
At system level, time is set by project planning (endogenous events). Given functional requirements (e.g users’ stories or use cases), architects and designers have to decide about the scheduling of systems functionalities and services, and the release of corresponding applications. Since those decisions are not directly exposed to exogenous events, they can be made according to engineering constraints and resources availability (b).
At platform level, time is set by business and operational objectives (endogenous events), and technical contexts (exogenous events). Assuming that risks are evenly set, the problem is to align endogenous (managed by project) with exogenous (anticipated from contexts) events: too early releases may preclude later but more useful ones; too late releases may hamper operations (c).
The texture of time differs across architecture layers (yellow for endogenous, red for exogenous)
Whereas those time-scales are to be synchronized, there is no reason they would be congruent. Hence the need of some mechanism, static (e.g milestones) or dynamic (e.g backlogs) supporting the scheduling of work units.
From Milestones to Backlogs
As considered elsewhere, phased models of development may offer some benefits when dependencies originate from different environments or involve different authorities; yet they may impose still bigger penalties when requirements cannot be fully settled upfront. Conversely, agile approaches are the option of choice when complex problem spaces and solution paths are to be explored and refined progressively; but may prove ineffective in dealing with business, organizational, or technical dependencies set from outside projects. That difference of perspective is reflected by the mechanisms used to manage dependencies: milestones or backlogs.
Sorting out dependencies means consolidating informational and engineering constraints across architecture layers. When problem spaces and solution paths cannot be managed under the same authority (heterogeneous dependencies) phased development models use milestones to consolidate expectations and commitments across layers and time-frames.
Otherwise (homogeneous dependencies) agile development models use backlogs to explore problem spaces and solution paths, whatever the architecture layer and nature of dependencies. With the benefit of shared ownership, business events are propagated all along development paths, governing backlogs of stories (business requirements), features (engineering constraints), and releases (operational requirements).
Backlogs can be used to consolidate organizational, functional, and technical dependencies.
Along that perspective backlogs and milestones can be seen as mirrored solutions of the same problem, namely how to deal with the functional and timing dimension of dependencies: backlogs deal only with the functional dimension as they consider the dependencies between tasks without taking into account their actual timing; milestones look from the opposite direction, anchoring aggregate tasks to timetables before considering dependencies between items. Depending on the point of view:
Backlogs may appear as stacks of stones: the milestones are fragmented and the initial sequence translated into queues.
Milestones may appear as flattened backlogs: dependencies are frozen and stories are ironed out before being merged into heaps.
Milestones can be seen as “flattened” backlogs, or, alternatively, backlogs as stacked milestones
Hence, with regard to the ranking of dependencies, the difference between backlogs and milestones is of granularity, finer for the former, coarser for the latter. But with regard to execution, the difference is of nature: contrary to milestones, backlogs don’t fix any timing.
That distinction between sequence (functional ranking) and schedule (time ranking) may be critical when iterative development has to be combined with heterogeneous dependencies.
Collaboration Levels
As noted above, the planning of work units must take into account three criteria:
The dependencies between tasks, engineering or informational, determine the sequencing independently of actual timing. They are derived from technical or organizational constraints.
The schedules anchor the start and completion of tasks to time-frames. Some time-frames are set within the enterprise (e.g resources availability), others are set from outside (e.g regulations or business opportunities).
Pace determine the elapsed time taken to complete a task. It may be seen as a metronome used to adjust the throughput depending on resources availability on one hand, quality requirements on the other hand.
Milestones and Backlogs Capabilities
At first sight, comparison shows backlogs to outdo milestones on all three accounts: dependencies are managed at finer granularity, which enables dynamic scheduling and releases management; last but not least, due to iteration cycles and time-boxing, development paces can be aligned with resources and quality requirements. Yet, that edge can be misleading if dependencies translate into unmanageable or multiple backlogs.
Collaboration is at the core of iteration cycles, and it can only be achieved through shared and dynamic management of backlogs. Assuming a set of stories, each new cycle has to be preceded by decisions regarding priorities, refinements, and responsibilities; and if informational dependencies have to be taken into account, these decisions must be taken collectively and directly:
Collectively: decisions about priorities and refinements must be negotiated between team members from both sides of the business/system (or users/developers) divide.
Directly: all decisions must be taken by the team itself, without any organizational mediation or external interference.
But those conditions could be thwarted if different projects have to develop stories with shared features implemented on different platforms.
Shared features and cross implementations could thwart collective and direct decision-making.
In that case consolidation mechanisms could bring back fixed scope/schedule configurations:
Different teams, each with its own specific users and developers concerns, will have to commit to agreed features and timetables.
By involving independent organizational units, those decisions will entail some procedural mediation carried out independently of iteration cycles.
Yet, that shouldn’t necessarily be the end of the stories, providing some mechanism could be found to synchronize iteration cycles. And that could be achieved with blackboards.
From Backlogs to Blackboards
Blackboards can be understood as shared backlogs stripped from their ranking mechanism so that items can be consulted and dealt with by different project teams. Alternatively, they can also be seen as timetables stripped from scheduling mechanism. Either way, those views illustrate how blackboards may support shared dependencies without forcing them into time-frames:
Shared features are posted on a single blackboard where their status can be consulted and updated by the teams in charge of the stories concerned.
Development teams post their releases on blackboards according to targeted platforms.
Blackboards are used to manage shared dependencies and differentiated stories’ contents
As it happens, that approach also answers the recurring question of stories’ nature and granularity: with the benefit of blackboards, fine-grained stories can be indexed as business cases, use cases, or new releases and cohabit in backlogs.
Combining backlogs with blackboards provides a collaboration mechanisms supporting external dependencies without impairing teams ownership of iteration cycles. Yet it is not a substitute for schedules as it doesn’t deal with the alignment of cycles with enterprise time-frames.
Time boxes as Pacemakers
Milestones and backlogs are synchronization mechanisms. The former, combined with timetables, coordinate teams along time-spans; the latter, combined with time boxes, coordinate tasks between cycles. Hence, while both aim at the same objective, namely that everything doesn’t happen at once, their understanding of time is very different: timetables are bound to an external measure of time, time boxes are just arbitrarily fixed intervals that can be tethered to any time-frame.
As a consequence, time boxes can be applied at different levels. At system level they are associated to project backlogs and used to set the tempo of iteration cycles. At enterprise level they are associated to business objectives and anchored to strategic plans. Assuming those plans are described by epics, it would be possible to use different tempos depending on level (enterprise or systems) or even applications.
Time boxes can be combined with blackboards to synchronize tempos between enterprise level (T) and interrelated projects (T/x and T/y).
Ideally, differentiated tempos should foster an emerging harmony between melody (users’ stories) and accompaniment (supporting systems) converging into the fulfillment of strategic objectives. Practically, the alignment of releases with epics cannot be taken for granted.
Squaring the Circles: Project Planning
Agile approaches are based upon the dynamic exploration of problem spaces and the iterative development of solution paths, the objective being to maximize the value of functional requirements under the constraints of technical ones. Yet, with spaces and paths defined dynamically, standard exploration procedures like breath or depth-first traversal are useless because the ranking of paths is part of the solution, which means that priorities must be revised at the end of each cycle.
Nonetheless, explorations cannot be everlasting and there must be some end to the story, when stakeholders get what they expect (or accept what they get) and users can begin to reap the benefits. Fixed scope and schedules being ruled out, the problem is to align iterations outcomes (b) with business objectives (a). Solutions can be positioned between two archetypal approaches, one driven by business objectives, the other by development tasks.
How to align tasks (b) with objectives (a)
The first approach would see development teams take commitments with regard to broadly defined objectives: with problem spaces represented by trees progressively refined and explored, commitments can be made collectively on sets of solution paths within still undefined sub-trees (b1). The team will then take responsibility for the details of iteration cycles and will adjust its throughput as to align releases with business objectives.
Alternatively, and providing a finer granularity can be obtained and managed, stories could be broken down into tasks for which commitments will be made individually by team members (b2). Assuming that the tasks workloads can be assessed, iterations could then be planned and releases scheduled on the basis of time boxes parameters.
Commitments can be made collectively with regard to objectives (b1) or individually with regard to tasks (b2).
Not surprisingly, the choice of a planning policy is to be conditioned by the granularity of work units:
Task based planning requires finer grained stories and comes with a phased flavor by reintroducing analysis. That may stretch the intervals between iterations and increase management overheads.
Objective based planning allows for coarser grained stories and is more in line with agile spirit. Yet that may increase the length of iterations and affect their transparency.
All things considered, some feedback loop may be needed when deciding on the size of stories because shorter ones do not necessarily decrease the time to market as they may generate bigger backlogs and exponential overheads in case of complex dependencies.
Balancing Pushes and Pulls: Lean and Just-in-Time Workflows
When push comes to shove project planning turns into conflict management. That may happen with phased development models as well as with agile ones. With the former that will be due to applications forcibly pulled out whatever their value for users and reliability in order to meet unrealistic expectations. With the latter that will be due to requirements forcibly pushed into backlogs disregarding their size and exponential complexity.
The way out of this dilemma is a feedback mechanism between project teams pushing releases and business stakeholders pulling applications. And that is the rationale behind the Kanban development model:
Visualize workflow: up-to-date expectations, constraints, commitments and achievements must be clearly and selectively visible to all concerned. that can be done with backlogs and blackboards.
Limit work in progress: that can be obtained by regulating the selection of solution paths through limits on the size of backlogs and the fragmentation of users’ stories according to their architecture footprint.
Measure and manage flows: metrics and process design can be significantly improved if flows are differentiated depending on architecture layer (business, systems, platforms).
Make process policies explicit: that is already a cornerstone of agile backlog management; those principles should also apply to backboards.
Use models to recognize improvement opportunities: while initially ignored, the benefits of models in agile development is progressively acknowledged. Those benefits have be illustrated in the first part of this article by the use of activity diagrams for the exploration of problems spaces and solutions paths.
Applying those principles will bring about lean processes and just-in-time workflows, improving both users’ value and software quality.
Assuming, for the sake of the argument, that programs are models of implementations, one may also argue that the main challenge of software engineering is to translate requirements into models. But, contrary to programs, nothing can be assumed about requirements apart from being stories told by whoever will need system support for his business process.
Telling Stories with Models
Along that reasoning, one may consider the capture and analysis of requirements under the light of two archetypal motifs of storytelling, the Tower of Babel and the Rashomon effect:
While stakeholders and users may express their requirements using their own dialects, supporting applications will have to be developed under the same roof. Hence the need of some lingua franca to communicate with their builders.
A shared language doesn’t necessary mean common understandings; as requirements usually reflect local and time dependent business opportunities and goals, they may relate to different, if not conflicting, aspects of contexts and concerns that will have to be consolidated, eventually.
From such viewpoints, the alignment of system models to business stories clearly depends on languages and narratives discrepancies.
Business to System Analyst: Your language or mine ?
Stories must be told before being written into models, and that distinction coincides with the one between spoken and written languages or, on a broader perspective, between direct (aka performed) and documented communication.
Direct communication (by voice, signs, or mime) is set by time and location and must convey contexts and concerns instantly; that’s what happens when requirements are first expressed by business analysts with regard to actual and specific goals.
Direct communication requires instant understanding
Written languages and documented communication introduces a mediation, enabling stories to be detached from their native here and now; that’s what happens with requirements when managed independently of their original contexts and concerns.
Documented communication makes room for mediation
The mediation introduced by documented requirements can support two different objectives:
Elicitation: while direct communication calls for instant understanding through a common language, spoken or otherwise, written communication makes room for translation and clarification. As illustrated by Kanji characters, a single written language can support different spoken ones; that would open a communication channel between business and system analysts.
Analysis: since understanding doesn’t mean agreement, mediation is often necessary in order to conciliate, arbitrate or consolidate requirements; for that purpose symbolic representations have to be introduced.
Depending on (1) the languages used to tell the stories and (2) the gamut of concerns behind them, the path from stories to models may be covered in a single step or will have to mark the two steps.
Context and Characters
Direct communication is rooted in actual contexts and points to identified agents, objects or phenomena. Telling a story will therefore begin by introducing characters and objects supposed to retain their identity all along; characters will also be imparted with behavioral capabilities and the concerns supposed to guide them.
Stories start with characters and concerns
With regard to business, stories should therefore be introduced by a role, an activity, and a goal.
Every story is supposed be told from a specific point of view within the organization. That should be materialized by a leading role; and even if other participants are involved, the narrative should reflect this leading view.
If a story is to provide a one-lane bridge between past and future business practices, it must focus on a single activity whose contents can be initially overlooked.
Goals are meant to set specific stories within a broader enterprise perspective.
After being anchored to roles and goals, activities will have to be set within boundaries.
Casings and Splits
Once introduced between roles (Who) and goals (Why), activities must be circumscribed with regard to objects (What), actions (How), places (Where) and timing (When). For that purpose the best approach is to use Aristotle’s three unities for drama:
Unity of action: story units must have one main thread of action introduced at the beginning. Subplots, if any, must return to the main plot after completion.
Unity of place: story units must be located into a single physical space where all activities can be carried out without depending on the outcome of activities performed elsewhere.
Unity of time: story units must be governed by a single clock under which all happenings can be organized sequentially.
Stories, especially when expressed vocally, should remain short and, if they have to be divided, splits should not cross units boundaries:
Action: splits are made to coincide with variants set by agents’ decisions or business rules.
Place: splits are made to coincide with variants in physical contexts.
Time: splits are made to coincide with variants in execution constraints.
When stories refer to systems, those constraints should become more specific and coincide with interaction units triggered by a single event from a leading actor.
Filling the blanks
If business contexts, objectives, and roles can be identified with straightforward semantics set at corporate level, meanings become more complex when stories are to be fleshed out with details defined by the different business units. That difficulty can be managed through iterative development that will add specifics to stories within the casing invariants:
Each story is developed within a single iteration whose invariants are defined by its action, place, and time-scale.
Development proceed by increments whose semantics are defined within the scope set by invariants: operations relative to activities, features relative to objects, events relative to time-scales.
A story is fully documented (i.e an iteration is completed) when no more details can be added without breaking the three units rule or affecting its characters (role and goal) or the semantics of features (attributes and operations).
Iterations: a story is fully fleshed out when nothing can be changed without affecting characters’ features or their semantics.
From Documented Stories to Requirements
Stories must be written down before becoming requirements, further documented by text, model, or code:
Text-based documentation uses natural language, usually with hypertext extensions. When analysts are not familiar with modeling languages it is the default option for elicitation and the delivery of comprehensive, unambiguous and consistent requirements.
Models use dedicated languages targeting domains (specific) or systems (generic). They are a necessary option when requirements from different sources are to be consolidated before being developed into code.
Code (aka execution model) use dedicated languages targeting execution environments. It is the option of choice when requirements are self-contained (i.e not contingent to external dependencies) and expressed with formal languages supporting automated translation.
Whatever their form (user stories, use cases, hypertext, etc), documented requirements must come out as a list of detached items with clearly defined dependencies. Depending on dependencies, requirements can be directly translated into design (or implementation) models or will have to be first consolidated into analysis models.
Telling Models from Stories
Putting aside deployment, development models can be regrouped in two categories:
Analysis models describe problems under scrutiny, the objective being to extract relevant aspects.
Descriptions and specifications look from different perspectives
Seen from the perspective of requirements, the objective of models is therefore to organize the contents of business stories into relevant and useful information, in other words software engineering knowledge.
Following the principles set by Davis, Shrobe, and Szolovits for Knowledge Management (cf readings), such models should meet two groups of criteria, one with regard to communication, the other with regard to symbolic representation.
As already noted, models are introduced to support communication across organizational structures or intervals of time. That includes communication between business and systems analysts as well as development tools. Those aspects are supposed to be supported by development environments.
As for model contents, the ultimate objective is to describe the symbolic representations of the business objects and processes targeted by requirements:
Surrogates: models must describe the symbolic counterparts of actual objects, events and relationships.
Ontological commitments: models must provide sets of statements about the categories of things that may exist in the domain under consideration.
Fragmentary theory of intelligent reasoning: models must define what artifacts can do or can be done with.
The main challenge of analysis is therefore to map the space between requirements (concrete stories) and models (symbolic representations), and for that purpose traditional storytelling may offer some useful cues.
From Fictions to Functions
Just like storytellers use cliches and figures of speech to attach symbolic meanings to stories, analysts may use patterns to anchor business stories to systems models.
Cliches are mental constructs with meanings set in collective memory. With regard to requirements, the equivalent would be to anchor activities to primitives operations (e.g CRUD), and roles to functional stereotypes.
Archetypes can be used to anchor stories to shared understandings
While the role of cliches is to introduce basic items, figures of speech are used to extend and enrich their meanings through analogy or metonymy:
Analogy is used to identify features or behaviors shared by different stories. That will help to consolidate the description of business objects and activities and points to generalizations.
Metonymy is applied when meanings are set by context. That points to aggregate or composite objects or activities.
Primitives, stereotypes, generalization and composition can be employed to map requirements to functional patterns. Those will provide the building blocks of models and help to bridge the gap between business processes and system functionalities.
The value of a model is its fitness to purpose. Missing this simple truth will inevitably trigger a “flight for abstraction” and begets models devoid of any anchor to business relevancy.
Abstraction ladders must be propped up by actual contexts (A. Magnaldo)
Yet, that pitfall can be avoided if requirements and models are put in perspective:
Requirements are meant to describe systems in their business context, models describe system artifacts. They should not be confused because the former are supposed to be rooted in concrete descriptions, while the latter aim at their abstract representation.
Models are built from nodes and associations. Nodes refer to instances which are supposed to be uniformly and consistently identified in both business and system contexts; associations may refer to instances (relationships and flows) or classes (specialization and generalization), the former with consistent semantics for business and system realms, the latter with semantics specific to system artifacts.
Along that perspective, the mapping of requirements into models can be achieved by applying selectively the two faces of abstraction: first removing information from the description of actual contexts, then building symbolic representations according to business concerns.
Business Context and Concerns
Starting with requirements, the challenge is therefore to move up and down the abstraction ladder until one gets the focus right, providing a clear and sharp picture of business context and concerns.
With regard to systems engineering, models’ semantics are unambiguously determined by their target: business environments or systems artifacts:
Models of business environments describe the relevant features of selected objects and behaviors, including supporting systems. Such models are said extensional as they target subsets of actual contexts.
Models of systems artifacts specify the hardware and software components of supporting systems. Such models are said intensional as they define artifacts to be created.
Business analysts figure models from actual contexts and concerns, software architects specify blueprints for artifacts
Climbing up the abstraction ladder, the objective is to align descriptive models of objects and behaviors with prescriptive models of system artifacts. That can be achieved in three steps:
Awareness of contexts: mind the business pie, drop everything else.
Domains of concern: say what features mean.
Symbolic representations: consolidate the descriptions of surrogates.
It is worth to note that the first two levels deal respectively with instances and features of actual objects and activities, while the third deal with artifacts. As a corollary, abstraction at the first two levels should be understood in terms of partitions and subsets, with subtypes introduced only for symbolic representations.
Awareness of Context
As illustrated by sounds (filtering noises) or optics (image point), focusing is a basic perceptual task targeting actual instances of objects, events, or activities. With regard to models, it can be achieved with a pronged move:
Adjust the depth of field to encompass the relevant business context. Large depths of field (aka deep focus) will cover concerns across domains, small ones (aka shallow focus) will support specific business concerns.
Single out image points for identified objects or activities deemed to be pivotal.
Field 1 is too small, field 3 is too large. “Dimensions” has no identity of its own, “Broom” is pointless.
A too shallow focus will capture only some of relevant objects (Piano), activities (Move) or events (Concert). Conversely, extending the focus may go too deep, including irrelevant items (Trumpet, Violinist, Illness, or Repair). Moreover, some image points may depend of others for their identity (Dimensions), or be pointless altogether (Broom).
Domains of Concerns
While business contexts are the same for all, business concerns are by nature specific to domains. The challenge for requirements capture is therefore to anchor specific features to shared objects and activities whose identities are set by business context.
For that purpose concerns are to be organized into domains responsible for the identification of anchors (objects, agents, activities) and the semantics of features:
Shared domains deal with anchors whose continuity and consistency have to be managed across domains, independently of activities.
Specific domains deal with anchors whose continuity and consistency can be managed within a single domain.
At this stage the challenge is to distinguish between identified instances of business objects (piano, concert) and processes (cleaning, moving, playing) on one hand, and the description of roles (mover, cleaner, pianist) and business logic (clean, move, play) on the other hand .
Domains of Concerns and Business Processes
It must be reminded that such models are still at ground level as they describe sets of instances; yet, they can also be seen as the first step up the abstraction ladder, as their objective is to extract relevant features and overlook others.
Symbolic Representations
While business concerns are partial and biased, the symbolic representations managed at system level must be comprehensive and consistent; that’s the objective of requirements analysis.
To start with, symbolic representations are introduced for each set of objects, roles or activities:
Objects surrogates: used to manage the continuity and consistency of business objects independently of business processes (piano, concert).
Process surrogates: used to manage the continuity and consistency of business operations independently of business objects (move, play, clean).
Roles: used to manage the interactions between actual agents and system functionalities (mover, cleaner, pianist). When the continuity and consistency of operations performed by agents are managed (e.g pianist), roles must be associated to surrogates.
Activities: used to describe business logic (move, play, clean).
Business logic and surrogates (#) for objects, processes and pianist .
Those are “flat” descriptions representing ground level instances. In order to be effectively supported by systems, models may have to be expanded downward by specialization, or upward by generalization.
Levels of Abstraction
As already noted, specialization and generalization are not symmetric because, contrary to the former operation, the latter one does modify the semantics of existing artifacts.
The purpose of specialization is to introduce specific descriptions for subsets of instances or features. For instance, assuming requirements are about moving pianos, the representation must climb one step down the abstraction ladder, from concerts to concerts with pianos:
Solo piano concerts are a subset of concerts subject to the same identification mechanisms and integrity constraints (strong inheritance).
The description of moving operations is not used to manage instances and its specialization is only about features (weak inheritance).
Climbing down: specialization of features (Move Piano) and surrogates (Solo Concert)
The purpose of generalization is twofold as it may be limited to features (aka aspect generalization) or targets both identification mechanisms and features (aka object generalization).
Aspect generalization introduces a base artifact for the description for shared features. Such base artifact is said to be abstract because its inheritance is limited to features and it cannot support the instantiation of surrogates, specialized artifacts keeping their own identification mechanisms. As a corollary, the level of abstraction is not modified because the model remains anchored to the same sets of instances. For instance (a), some administrative procedures can be defined uniformly for all maintenance operations otherwise described and executed independently.
Climbing up: generalization of features only (a), and for both features and individuals (b).
That’s not the case with object generalization which redefines the initial sets of surrogates as subsets of newly created super-sets. For instance (b), a cleaning process becomes a maintaining processes without the repair extension. Since maintaining processes can be created as simple cleaning or repairing ones, the model is anchored to different levels of abstraction. And since descriptions should not cross levels, roles must be specialized similarly: maintainers are to be identified as such before being qualified as mechanics, even if their interventions are not managed as such (inheritance of transient identification mechanism).
Getting A Proper Grip
Models are neither true or false and can only be assessed for consistency and effectiveness.
Hence, assuming that (1) systems are meant to handle surrogates of business objects and processes and, (2) those surrogates are designed from models, it ensues that (3) a litmus test of model effectiveness would be the grip it provides on relevant objects and processes.
A grip on context and concerns
And that can only be achieved by pinning models to concrete and identified business objects and processes. That provides a template for modeling grips: concrete descriptions with primary identification in the middle, abstract ones above, aspects or concrete descriptions with inherited identification below.
Whereas UML has been brought to existence by very wise men under very propitious skies, the initial enthusiasm and first successes have never been transformed into wider acceptance and customary usage; subsequent updates and extensions didn’t help and may even have triggered some anticlimax. More than fifteen years after its launch, the utilization of UML remains limited, both in breadth (projects developed) and depth (features effectively used). Moreover, the UML house is deeply divided and there isn’t much consensus among the few that use it comprehensively and consistently, principally to support domain specific languages (DSL).
The Divided House of UML (Anne Desmet)
Certainly, there must have been a wrong turn somewhere, possibly at the UML2 crossing when the OMG committee lost sight of users modeling needs and took the road to meta-models. Considering UML’s shrinking stamp and dwindling relevancy, that road appears more and more like a dead-end; but it may be still possible to get back on track and retrieve the Us of the UML: unified semantics for all and sundry users.
Where to Look
Whether on driving or back seats, respectively for model driven or agile methods, models are widely accepted as a necessary constituent of development processes. Nonetheless, and despite being the only official standard, UML standing appears to falter, up to be already seen as a cold case. As suggested by Ivar Jacobson (“The road ahead for UML“), one of its main drawback would be its lack of modularity with regard of users needs. If that flaw is to be fixed, the question is where to look: directly at language level, or at supporting mechanisms.
Given the broad consensus that surrounded the initial project, one should at first look for a sound and stable subset to be used as a backbone and fleshed out according specific contexts, purposes or users. As a matter of fact that is what stereotypes and profiles are meant to do, except that without a well-defined backbone of unambiguous constructs, the only possible outcomes are domain specific languages. So, one should first consider how the separation of concerns could be better supported by language constructs.
Language Constructs, Model, and Separation of Concerns
Separation of Concerns
Despite its roots in the Object Oriented paradigm, UML has demonstrated its adaptability to all and every method or domain. Unfortunately, being a Jack of all trades often means a master to none, and the use of UML is clearly frustrated by its versatility; that translates either into shallow usage of ambiguous semantics, or into extensions targeting specific domains or technologies.
On the ground, three mechanisms can be used to make for the lack of focus: stereotypes, views, and customization.
UML stereotyping mechanism support predefined constructs for problem (business objects and processes) or solution (system architecture and object design) spaces. Stereotypes can be grouped into profiles, e.g for specific business domains or technical architectures.
Views (or perspectives) organize access to models according contents: logical, physical, conceptual, pragmatic, etc
Tool customization organizes access to models according users purposes and skills: analyst, architect, designer, developer, etc.
While those approaches have their benefits, they are set independently of languages constructs, either as UML extensions (stereotypes and profiles), or defined from outside by development methodologies (views) or projects organization (customization). As a consequence, they have little or no effect on the simplicity or efficiency of UML; they may even add to confusion and complexity when overlapping stereotypes are introduced to support multiple taxonomies, e.g technical architectures and business domains.
Language Constructs (a), Stereotyped Model (b), Combined Views or Profiles (c)
That may point to a clear direction: given the potency of the stereotyping mechanism and its pivotal role in UML utilization, significant benefits could be achieved through a better integration into core language constructs, even if that entails some constraints or limitations. Two straight modifications should be considered:
Model layers: language constructs should be re-organized along architectural concerns for enterprise (business processes), system (functionalities), and platforms (components).
Stereotypes visibility: language constructs should support the distinction between local taxonomies and “unified” ones, the former set with limited scope and visibility, the latter meant to be applies across layers.
While both modifications can be carried out on their own, their benefits would be boosted if they were set within the broader MDA framework and supported by specific language constructs.
Modular Language Constructs
Given the growing intricacy, ubiquity and diversity of systems, UML complexity and versatility should clearly be in demand, and the problem is to harness those capabilities according the needs and skills of the different kinds of users.
That’s arguably a critical flaw of UML, which lumps together essential with secondary constructs, as well as definite with ambivalent semantics. That brings weighty consequences, both for users and models:
Steep or even abrupt learning curve: confronted to a wall of mixed constructs users have to master the whole upfront, whatever their needs and skills.
Blurred concerns: describing various specific contents with the same ambivalent constructs will either distort language semantics, or blur concerns specificities.
Corrupted transformation: whatever the modeling tools, the bad apples of inputs will usually corrupt the whole of outputs. In other words any advance in model driven development requires a sound backbone of unambiguous language constructs.
As noted above, language constructs can be regrouped along two perspectives, one directly associated with users architectural concerns, the other reflecting the scope and visibility of targeted artifacts. While there is no particular reason to match complexity levels with architectural concerns, mapping them to granularity has a clear rationale. Such a “born again” UML would distinguish between two levels of language constructs:
Those pertaining to objects and activities identified by architectures, whatever their nature: enterprise, systems or platforms.
Those used to describe internals of objects and activities independently of their aspects and behaviors at architecture level.
Model Transformation: lumped (b) vs differentiated (a) language constructs.
That re-configuration would bring modularity to the language, enabling a smooth learning curve. More importantly, a clear-cut separation of concerns will enable some kind of Just-In-Time model transformation: instead of cumulative noises (b), one will get separate transformations for models architectural backbone on one hand, contingent specificities on the other hand (a). And that could be a real game-changer for lean and fit models.
While that could be achieved by different means, a simple solution would be to use the stereotyping mechanism to describe supporting structures of enterprise, functional, and technical architectures.
Transformation vs Portability
Model transformation is about changing contents within the same environment, portability is about moving the same contents across different environments; and despite apparent similarities, they deal with different concerns, set by users for the former, by tools vendors for the latter.
Transformation is normally performed under a single corporate roof according agreed semantics; as a corollary, it is meant to cover the full contents of models. That’s not the case for portability, whose primary objective is the exchange of consolidated contents between heterogeneous environments; while sources and targets may have to share the whole of their models, a sound policy should make room for selective portability of specific or confidential contents.
The Meta-Object Facility (MOF) is the solution of choice for portability. As a meta-language it is used to describe language constructs at source and target environments; mapping rules can then be defined and bridges built between environments. As it is, those bridges usually scale very poorly due to the exponential complexity of rules having to cover all and every model idiosyncrasies; and that’s unfortunate for portability which, instead of focused targets, has to deal with overweight models cluttered with useless contents (b).
Portability between modeling environments: Lumped (b) vs Differentiated (a) constructs.
That situation would be greatly improved (a) if the wheat of consolidated constituents could be separated from the chaff of ambiguous or irrelevant contents. On a broader perspective that will open the way leaner and fitter models.
One step back may put UML back on track
There is something of a consensus among the software engineering community regarding (1) the benefits of models and (2) the failures of UML. As should be expected, that consensus translates into fragmented modeling practices and, more generally, software engineering methodologies. Obviously there isn’t much of a future for UML along that path, but the case is still open and the trend can be reversed by putting users needs back on UML driving seat.
