sunevang

Managing the development of software is a complex task – at least if the team grows above a few people or there is a demand for control patterns that is above informal working. You will need to be clear on your boundaries to teams or people with other accountabilities and on your general guidelines for the way of working, design patterns and non functional requirements. All ready here the informal team will start putting their foot down and talk about – “over complicating” – but that is not my take. No, my take is that we need to spend time in the helicopter and get some principles and patterns in place. Working informally can be beneficial for the colloquial work atmosphere – but its not beneficial for productivity, quality and long term coherence.

Managing the evolution of the Data Model

My finding is that the you need to manage the evolution of the data model of the system meticulously so you strike a balance on generalization and specificity in the role of an entity. This goes for the specific domain your software supports as wellas the enterprise fit facilities.

Managing the specification process

My finding is that you need to drive a process where specifications gets written down. And the specifications need to be precise on:

• Business problem to address (this might be a reference to requirements)
• Extension of the data model, parameters, high level UI features

Making it happen

From a practical point of view I’ve addressed the two above challenges through:

• A strict requirement to specification process
• Hard work on the conceptualization part
• Hard work on business rule articulation part

I’ve written some blog post that might inspire you even though they are not prescriptive:

• V-model and the Concept Leap
• Concept Maps – Introduction
• Business Logic/Rules Examples