If you consider software development there are basicaly different models of doing it like,
the types of classical waterfall, V or W models and of course the different agile methodologies, ranging from extreme programming to SCRUM.
All of these methodologies suppose however that there are some kind of a more or less explicite spefication what should be develped.
Considering the waterfall model the specifications should be explicitely given as a set of requirements to start the development itself.
Having developed the reqirements there might be one more round to extend both the specification and the covered the changed requirements.
Agile development focuses much more on the changing of the specification, having more iterations and more check and validation of the requirements.
Agile development usualy does not suppose very strongly that the reqirements covered in the form of a precisely described specification,
but it is supposed that there is at least someone like a product owner who has got an explicetly view what should be developed. We can say that with agile methodologies,
even if it is not written the product owner knows exactly the specification.
What happens however if collection the specification in an organisation is problematic,
if noone is able to act as an efficient product owner because getting information from the members of the company would require too much time and effort.
Not to speak about writing a precise specification that would be much more complicated.
Is there a way in such a situation to carry out an efficient software development ?
Is there a way to have a software development methodology that actually supports collecting pieces of the specification itself ?
I think the answer is yes.
Let we imaging that we do not want to have a development in which everything has to be developed from scratch instead we are dealing with components that are not necessarily ready but they are at least in a prototype that can be somehow demonstrated.
Let we imagine that we have (C1, C2, C3, ... CN) prototype or demonstrable components in our system and we provide user interface called metamodel in which the users or customers can configure demo applications and like them or dislike them based on different like mesaures.
Like supposing one customer wants to have only the (C1, C3) components in a certain configurations another customer wants to have only (C2) components and the third one only (C2 and C4).
The system that should we realised is the combination of (CN...CM) components that are liked the most and makes sense to build it up. Certainly they are fuzzy concepts, how the components can be congigured and how the system can be build are depending on the exact domain and technology.
In this way creating the specification is more like a social network: people like on software components and configurations instead of posts or pictures (see the following picture).
Having this model we should not sctrictly follow the classical principle : developing one software at the end of the process.
Several other outcomes can be imagined as well :
- One software at the end (one size fits for all): based on the likes and techniqual restrictions we still choose one model to implement.
- Several variations: we choose some of the most liked solutions and implement as several variations, from which the userers might choose one on their own.
- Self service software creation (mass customisastion): if the components are not just prototype but practicaly 100 percent ready solutions, there might be a possibility to provide everything and the users can configure everything on their own.
Let have an example, realised in SharePoint.
We want to develop personal records in a company for storing and showing information for each person. We are however not very much sure exactly which information should be stored.
Let we say, first name and last names are for sure but othwervise noone knows which metainformation should be used.
Let we have the following simple meta factory with the following metainformations:
- ObjectName - name of the object that we want to store, in our example there is only one object called PersonalRecord.
- PropertyName - the name of a property of an object.
- PropertyType - the type of a property of an object.
- ProeprtyLike - information who wants to realise which property, for example in our example there is only one property that wants to be seen only by "test" user, there are only two properties that wanted to be implemented by "test2" user : "FirstName" and "LastName" and so on.
In this sense the components are practicaly the objects and property elements (see the following picture).
Pressing a preview button each customer can see how the choosen configuration could look like, in this sense they do not just choose blindly, but there is a certain view, a certain idea how the choice might look like. As an example having the administrator choice, the given configuration might look like as follows.
It is important to note that the preview should not necessarily be the final version; it can be regarded as a sketch as well. Like in our example the concrete design is pretty poor, however in a final implementation it can be much more fancy.
Based on the likes and users' preference there should be a review and a decision, like:
- implementing some of properties, mostly that are liked by the most and create one common profile
- implementing more property sets, so the users can choose which one they want to apply
- or simply implementing everything
