Thoughtfulness about specification phase

In the post series about definitions, I would like to focus today on the specification phase, and in particular on viewing this phase according to different perspectives we used to use. It is not revolutionary while we root them out "old methods" like SART or HOOD.
First of all I would like to consider the V life cycle, which is traditionnaly used as reference for every life cycles, under the concepts of Problem and Solutions domains.
We actually can break down the V life cycle into two main parts, i.e.

1. Problem domain : it is the modelization from an external point of view of the real system under development, and also the requirements wrt the system to be developped. We find in this area three main types of activities, ie establishing system needs document by the customer, describing by IT guys the software specification from this document, describing then running validation tests, and qualification tests
   
2. Solution domain : it is the internal view of the system under development which regroups the following formal phases : analysis, design, coding, verification testing(unit and integration testing)

In this post, we focus specifically on the specification phase which is part of the Problem domain area.
The goal of the sofware specification is to provide the development team with a set of elements needed to realize in the best conditions a system which is as close as possible from the customer needs.
There are many means to reach this goal. We can envisage :

• simulation
• modelisation
• mockups and prototypes
• free textual expression of the needs
• formal specifications with methods like the B Method
• ...

All these methods can be used simultaneously of course, everything being a matter of means and/or time.
It is important to notice that the specification model pursues three goals, ie :

• a cognitive aiming, ie understanding the environment of the system under development. We then speak about establishing the Knowledge model
• a prescriptive aiming, ie undertanding interactions between the environment and the real system under development. We then speak about Requirement model also known as Interaction model
  
• an operational aiming, ie designing an effective system in order to fulfill customer needs as close as possible; it is known as Operational model.
  

Knowledge and Requirement models are part of the Problem domain and the Operational model mainly constitutes the Solution domain.
Knowledge and Requirement models establishment is the goal of the specification phase.

We'll see in later blog messages a deeper definition of thoses models.

Notion of Model

After having precised the concept of Method in a previous post, we're going today to define the notion of Model. I know it is obvious for the major part of you, but it is still useful to recall these concepts in mind.
A Model is a simplified view of a reality. It captures the essential relations of the system under study. The use of models during the software development is mandatory. It enables the developper to:

• handle the complexity of the problem
• communicate with everyone
• be able to pursue the project with another team, contribue to the perenity of the project
• render eventually possible automated tasks like code generation, tests and documentation

There has been a lot of work since few years to promote an Model Oriented Development, where the MDA is the most known perspective. It is clearly a trend today ; there is still maybe today a lack of simple and efficient tools to monopolize totally the attentions of the majority of developpers and decision-makers.

We distinguish, to simplify, four kinds of development models :

• combinatorial models : output values are determined from the current input values (decision tables, truth table, karnaugh table, boolean logics, cause to effect graphs, ...)
• sequential models : output values are determined from the current and past input values (FSM, Statecharts, Grafcets, petri nets, ...)
• static models : describe a statical point of view of the system (class , use Cases , components , deployment, packages, ... diagrams)
• descriptive models : it is often models describing a snapshot of the system ( activity, sequence, .., diagrams)

What are the elements of a model?

They are the following:

• Subject : a model must have a well defined subject, e.g. the software under test
• Pointof view/theory : a mode must be based upon a referential frame and principles which enables identifying relevant information, e.g. software testing models put typically under the light the behavior and/or focus on structure or elements aspects suspected to be bugged
• Representation : the formalism used is very important and must be chosen carefully to express the most aspects as possible with the less artefacts possible. The formalism must also be understood by as many people as possible
• Technics : models are tightly linked to the domain culture where people evolve, and are not necessarily transposable to other domains

That's all for today :-)

What is a method?

It is always valuable to get back to the basics to stand back and eventually change direction. I'll try in future posts to make returns on some notions, maybe the occasion to discuss about them with readers.
So why not start today with the ground notion of a Method?

To make short, the object of a method is to help engineers to design a system under development by garanteeing :

• achievement of customer requirements
• quality
  
• deadlines and costs
• maintenability
• extensibility
• safety
  
• security
• documentation
• team work
• information sharing
• and so on...

To sum up, a method helps us to take into account all the functionnal and non-functional requirements of the customer, expressed explicitly or not.

A method must focus on three main aspects to be considered imo as a usable method :

1. choice of formalisms, and artefacts
• diagrams
• elements of modelization
• elements of representation
  
2. definition of a process
   
• phases and steps
• activities of producing artefacts
• deliveries
• follow up
  
3. instrumentation of this process
• modelisation tools
• control of the models
• development tools
• tests handling
• software configuration management

The method scope can be the entire lifecycle of the application development, or only a phase in this life cycle. We may even have several methods corresponding, each, to different phases and all these methods together becoming the overall method, e.g. a method for specification, another one for architrecture, another one for analysis, and again one for design. Even if I prefer a more homogeneous approach, this way of doing can be relevant when for instance specifying a domain which is very particular needs its own formalism.

You'll object me that many companies, many people use methods to develop applications without using all this stuff... Sure, but what I describe here is an ideal toolbox designed to guarantee the quality of the application wrt the customer expectations. It is a kind of roadmap. Once you have this roadmap in mind you can choose in conscience what you want to choose, what you can choose to achieve your goals and the ones of your customers. You don't undergo events, you play with them... and it is in fine a big difference.