Achieving Consistency and Agility through Design Accelerator
- Design is Dependent on Designers
More often than not, Good design is dependent on good experienced designers. It depends a lot on the individual skills and foresight of the designers. A designer who has had the experience of designing a similar system in the past is more equipped to design the system better. However with the demand for experienced designers growing up, it is a challenge for project teams to always have very experienced designers in their ranks.
- No Repeatability in Design
Software Design is inherently filled with subjectivity. That is, it depends a lot on how designers comprehend the requirements and design the system. Two good individuals may design the system in two different ways. Both the system could be well-designed. Moreover, if the same individual is asked to design the system at a later point in time, he /she may design it in a different way. That design may be better/worse than the previous one. In other words, the design lacks repeatability and consistency.
- Lack of Documented Reasoning in Design
Imagine a scenario where one of the designer has to leave the project mid-way, the person taking over the project will have to understand why the system was designed the way it was. Despite having the best of tools and models, understanding the thought process behind a design becomes a challenge.
- Increased Design Effort , Reviews and Rework
Design goes thru its own process where in the design is first drafted, then reviewed and then sent for rework. Reviewer need to spend lot of effort in reviewing different aspects of the design.
Let us look at how we can counter the issues stated above and reduce the subjectivity that shrouds the design. For this we need to go into the basic principles that drives the Software Design and also the Best practices which every designer follows. One way to approach Design is to think in terms of Components that realize the system. Well-Designed Systems have well-designed components. If we identify these components in a systematic way, then we are in the right path to Design. Following section explains more on this.
The first step most designers do is to understand the requirements and look for requirements that are related to each other. They might look for certain groups of requirements that perform similar action. In other words, the designers are identifying the components that are needed to build the system. A consistent way of identifying components would help designer to think alike.
Now the key question is how do they identify components and on what basis do they say these groups of requirement correspond to a particular component? There must be something that these requirements share in order to be classified and grouped. In other words, there must be some attributes/traits these requirements possess. Therefore it would be fair to say that these requirements can be clustered based on their attributes
Let us look at some of the attributes on which the requirements can be clustered.
- Data Entities
First thing a Designer might look for is Data Entities that are found in the requirement. If two requirements share a data entity, the designer might consider grouping those requirements. For example Opening a Bank Account can be one requirement. Address Verification of the customer can be another requirement. Both the requirements share the data entity Customer Data. The Designer might consider grouping these two requirements.
- Adjacent Actions
Requirements specify some action about what a system has to do. When a designer sees a natural flow in actions in the requirements, he might consider grouping them. For example Validation of customer data is logically a next step to Entering data. They can be considered for grouping.
Another pattern that designers look for is the Actor who is going to use the system. In the above example, filling application form is done by Customer, while Address verification is done by banking officer. Customer and Banking officers are two different actors who are using the system. If the same Actor is being referred in different requirements, then those requirements can be grouped.
From the above points, it is clear that requirements that share the same data entities, same actor and that are adjacent can be grouped (clustered) together. In reality, requirements might share some attributes say data entities and actor or just one of the attributes. It becomes a big challenge for designers to quantify the extent to which requirements share attributes. Moreover, with huge sets of requirements and less time to deliver, going thru the requirements and identifying these clusters manually becomes a big challenge. The process if repeated, has a high chance of different clusters being formed. In other words, it is not a repeatable process.
This is precisely what Design Accelerator intends to address. It automates the identification process. It takes the requirements that are captured in UML tools and identifies the potential components by forming clusters. These clusters can then be imported into Design Tools, from where the designers can start their design process. This way it brings repeatability into Design process. Moreover, it assists Designers to think and reason out in a similar way. More importantly, it saves a lot Designers' valuable time.
By bringing in repeatability and consistency, the design Accelerator enables the Designers to approach the design in a consistent manner. Lot of Design effort can be reduced thereby bringing in more agility into the process. Having said that, Design is a phase which still has lot of subjectivity and automating this phase remains a challenge. We at Infosys Labs are focusing on building solutions to address this space. This blog focused on design taking component approach. In future, we will be covering other aspects and approach to Design. This is just a beginning of a series we have planned.
- T. Kohlborn, A. Korthaus, T. Chan and M. Rosemann, "Identification and Analysis of Business and Software Services;A Consolidated Approach", In IEEE Transactions on Services Computing, 2009,
- Towards a Foundation for Quantitative Service Analysis An Approach from Business Process Models , IEEE on Services Computing ,2010