The Two Laws Of Dimensional Ontology

The Two Laws Of Dimensional Ontology

• Law I
  • "One and the same phenomenon projected out of its own dimension into dimensions lower than its own is depicted in such a way that the individual pictures contradict one another."
• Law II
  • "Different phenomena projected out of their own dimension into one dimension lower than their own are depicted in such a manner that the pictures are ambiguous."

I think this is two laws somehow explain what happens when we try to use a model to describe stuff in the real world, we end up representing things inaccurately and incompletely... the funny things that sometimes we seem to somehow change our angle of perspective, and then we realize that the our model is wrong... and try to fix it, and after that we believe that now it is right, but we will never have it right because the map is not the territory. Perhaps a similar problem arises when we try to use ObjectRelationalMapping, we simply lose some of the information because of the perspective we choose to use... Object Orientation forces a particular structure it may not exists... and Relational... trying to see things from a neutral point of view end up not being helpful enough: it seems that humans tend to need to see things from a particular hierarchical perspective at a time, and find it hard to grasp things from all points of view at the same time.

I started to think about this, because as a software engineer I am sometimes asked to create documentation about the software I am building (you know, the typical use cases stuff), and when you have to write a document of the kind a lot of times, the company where you work typically already have some document templates... now, typical document templates have a hierarchical (object oriented?) structure:

• UseCases
  • UseCase1
    • Scenario 1
    • Scenario 2
    • Actors that participate in the use case
    • Classes (sterotyped as boundary in RobustnessAnalysis) that participate in the use case
    • Classes (sterotyped as control in RobustnessAnalysis) that participate in the use case
    • Classes (sterotyped as entities in RobustnessAnalysis) that participate in the use case
    • ActivityDiagram?

But then, they realize that some times, (for example to decide what uses cases will be affected by the modification of an entity class) they also need a document like this:

• Classes
  • Classes (stereotyped as boundary in RobustnessAnalysis) that participate in the use case
    • Class 1
      • Use case 1
      • Use case 2
      • Actors interacting with the class
    • Class 2
      • etc,etc.

Both documents have kind of the same internal model, but represent (view it?) form a different perspective, now, the strange thing, is that I do not know of a commecially successful desktop publishing and/or word processing application that allows you to specify such a model so that you can describe your system once and only once and produce documents with several perspectives (I know products like Adobe FrameMaker are supposed to help you with this kind of semantical document structure, but, since they are (AFAIK) internally based on hierarchies, and not relational theory, they do not really allow the user to use all the power of the relational manipulation of data) I think that the problem might be that humans usually organize their ideas following some kind of hierarchical structure... or at least thats the way we are thought to do it at school, perhaps because of the limitations of printed material (a book made of paper can not be queried and reshaped relationally). But, now that we have all this electronic power to help us, we still try to organize stuff in hierarchies (or in messy graphs) and not relationally (internet is a messy graph, no a relational database... am I wrong? XHTML/XML are hierarchical, nobody would accuse them of being relational). We simply find it easier to organize stuff in that way... is it really because that is the natural way in which we think? or is it because we still do not have good enough relational tools to deal with knowledge? is relationally actually about creating a model that is valid from any perspective? or it is more about easily changing the perspective? (But if we build those model from particular perspective, how can we expect relational to produce a model that is valid for more than one perspective?) And finally, why we do not have any Relational Word Processor/ Relational Document Standard

Business Case (Is it a good idea to modify an Activity?)

Today, we also covered Business Cases, it is an interesting subject, it basically tells you to compare projects using the following criteria:

• Total Activity Disfunctionality
• Total Activity Impact
• Total Activity Factibility

If Impact and Factibility and Disfunctionality are high, then it is a good idea to go ahead with the project, on the other hand, if, for example Factibility is low, then, it would be impossible to really build the project, or if the Impact level is very low, then it might be easy to do it (hi factibility) but i will not help the organization much, so, it will not be a good idea to waste time building the project. If Disfunctionality is low, that means that the activity actually works really good, so, typically the impact of your changes will not be high.
(Mmmm, I see some kind of relationship between Disfunctionality and Impact)

The project triangle

In project management a very important concept is that of the project triangle: Scope, Resources, and Time, it is impossible to have more than two of them.
I have had problems with this triangle.... always, typically because there is not time, and there is no money (Resources) and the Scope, well the Scope always increases.
The main problem in my experience is that not a lot of people has heard of this triangle, and those that do, say, well, it is a nice idea, but the reality of this project is that we need this done with cheaply, for tomorrow, and with unexperience personnel.
When the projects is "Tipically Succesful" it is because it is not too late, or hasn't exceeded the budget too much... or the scope was not too insuficient.

The problem is that everybody in software developerment needs to realize that it is not possible to control more than 2 of this factors. For example:

If you have to do everything in a rush, scope will suffer, and if scope doesn't suffer, then costs will increase...

Perhaps somebody (I?) should create an interactive version of this triangle... one that, when changed 2 factors tells you the implications in the third.

I am starting to think that the project triangle is somewhat similar to radar charts....

Areas of Oportunity

1. Take advantage of Eventum/Bugzilla and use it to feed Construx Extimate (Metrics, Estimation)
2. Take advantage of Construx Estimate to feed DotProject in a more accurate way (Metrics, Estimation)
   
3. Use the curse as a fundation to justify the use of configuration management tools
4. Give courses to increase technical level.
5. Implemente a processs lifecycle for the development of each feature (covering configuration management, architecture, etc) that will help to make estimates more accurate.
   

Software Engineering the State of the Art

Today I started my course on project management, and my instructor gave me this very interesting link: Software Engineering the State of the Art