Volvo Cars sets objectives for the company each year. Same as I guess almost every other company. Every department is then required to break down these objectives.
One thing I notice is that often there is confusion between what is an objective and what is the activity to achieve the objective.
Objectives or activities?
Tuesday, March 27, 2012Concrete vs. abstract and detail vs. overview...
There often seems to be confusion about two concepts relevant to representing design information, including models.
First there is the scale of abstract versus concrete. Second there is the concept of overview versus details.
If one looks at how a design progresses over time, regardless if one follows a waterfall or agile process, one moves both from abstract to concrete and from overview to details, but they are not the same thing. And I think that agile and waterfall puts different emphasis on on to make these transisions, and where to start and end (topic for another blog post!)
Going from overview to details is simple, the more you know about the problem and the solution the more information is added. think of going from a sketch where you only elaborated on the key classes to understand the system to a class diagam with all classes that are implemented. Using a map as analogy; you increase the scale to see more details, the coastline gets more details, or you see all roads and not only the big ones.
Going from abstract to concrete is also about adding details, and I think that is where the confusion begins. But the details that are added are not of the same type as in the more abstract representation. Here it could be adding all attributes of classes or ports to components. You don't get this information by adding more classes or structure components. In the map analogy it would mean adding indvidual houses on a map which previously only had roads, lakes and forests. It is a new type of information which you cannot deduct (transform) from the more abstract representation.
First there is the scale of abstract versus concrete. Second there is the concept of overview versus details.
If one looks at how a design progresses over time, regardless if one follows a waterfall or agile process, one moves both from abstract to concrete and from overview to details, but they are not the same thing. And I think that agile and waterfall puts different emphasis on on to make these transisions, and where to start and end (topic for another blog post!)
Going from overview to details is simple, the more you know about the problem and the solution the more information is added. think of going from a sketch where you only elaborated on the key classes to understand the system to a class diagam with all classes that are implemented. Using a map as analogy; you increase the scale to see more details, the coastline gets more details, or you see all roads and not only the big ones.
Going from abstract to concrete is also about adding details, and I think that is where the confusion begins. But the details that are added are not of the same type as in the more abstract representation. Here it could be adding all attributes of classes or ports to components. You don't get this information by adding more classes or structure components. In the map analogy it would mean adding indvidual houses on a map which previously only had roads, lakes and forests. It is a new type of information which you cannot deduct (transform) from the more abstract representation.
Testing
Friday, March 23, 2012
I have to admit that I know too little about software testing in practice to be a well-rounded software developer. That does not mean that I am adverse to testing, on the contrary I think that many architecture focus on properties discernible by the end user and not the developers where testers are a key developer role.
So I am curios if there are any patterns on how to design a testable architecture.
I enjoy the blog thoughts from the test eye, which also has a blog roll if you want to explore further test blogs.
I also stumbled across a very good powerpoint summary about testing in industrial settings from Lappeenranta University of Technology.
So I am curios if there are any patterns on how to design a testable architecture.
I enjoy the blog thoughts from the test eye, which also has a blog roll if you want to explore further test blogs.
I also stumbled across a very good powerpoint summary about testing in industrial settings from Lappeenranta University of Technology.
Quality starts with me
Monday, March 12, 2012
Outside the main dining hall at Volvo Cars R&D headquarters there is some information about ongoing quality work under the heading "Quality starts with me". A quick google search shows this sentence is not something unique to Volvo Cars, but it got me thinking.
To start with: For software (or any product I guess) quality can be seen from to viewpoints:
Let's say that I review a software specification if all requirements are SMART requirements (insert alternative acronym if desired). Does this support quality of type 1 or 2 above?
When it comes to reviewing or auditing I think it can be applied towards both objectives above, but it requires a lot more of the reviewer if it is the second objective that is the goal of the audit.
To start with: For software (or any product I guess) quality can be seen from to viewpoints:
- Free from defects
- Appropriate according to the needs of the user
Let's say that I review a software specification if all requirements are SMART requirements (insert alternative acronym if desired). Does this support quality of type 1 or 2 above?
When it comes to reviewing or auditing I think it can be applied towards both objectives above, but it requires a lot more of the reviewer if it is the second objective that is the goal of the audit.
Subscribe to:
Posts (Atom)
