How distributed analysis helps building the right context

After many years in working on software projects I realized that the most common reason of misunderstanding the design of an application is the lack of context or to be more precise, the lack of a shared context among the participants to the meetings.

The chance of working with a distributed team according to the CalAgile approach highlighted the need of clarifying this aspect. According to this approach a representative of the software consultancy firm kicks off the project at the customer’s premises by setting up communication channels between the customer’s business-oriented team and the remote software-development team. This kind of organization requires a continuous rethought of the customer’s needs as the representative actively reports to the team the model they should build.

Reporting through remote tools like instant-messaging requires a particular care in explaining the logic of the software system in construction. The interactive nature of such tools heavily pushes towards a shared logic model understood by all the components of the team. A set of cause-consequence steps automatically springs from this kind of discussions as the lack of physical interaction lets participants concentrate on the pure inner workings of the system.

Given these circumstances, the need of a properly defined context becomes compulsory and it is interesting how this “forced” state positively backfires to the business team itself that sometimes discovers flaws into its model, sometimes finds out new opportunities and even more, sometimes leads to optimized solutions that had not been devised yet. And now, following this path, we come to the need of a definition for a shared context: the axioms of a shared context are first of all a common understanding of the terms used; second there should be a clear definition of the starting points, how the system to be modeled comes into existence and this is usually achieved by finding out roles interacting with it; third is the goal the system wants to reach.

The points above could be interpreted of something quite common when doing the analysis of a software project and they actually are. The angle I’m trying to point at here is to consider them always during meetings both in the face to face ones and in the remote ones. There is often a natural tendency to fall into a whirlpool of sentences during these meetings and it often turns into a game of building an unbalanced pile of items kept standing only by misunderstandings of a few and the ignorance of others. Let’s try to build a solid system starting from some solid foundations.

Advertisements
Explore posts in the same categories: Methodologies

Tags: , , ,

You can comment below, or link to this permanent URL from your own site.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: