Tuesday evening we had a nice meeting of all the microsoft professionals at capgemini NL.
Many new and upcoming products of Microsoft were discussed, though not in great detail.
One of the god things was the confirmation that Outlook in office 2010 will have the grouping of emails in threads that gmail already offers. That probably means that you can save yourself some time by skipping lots of outlook videos now, and switsching to outlook 2010 asap.
Another, but minor innovation, is that you will be able to archive your email automatically when your exchange mailbox is full. Less manual work there, but not a big deal. This might imho turn out to be a limited blessing, as you probably want to store your archive in a safe place, where it is backed up. That means that you got to be connected to a network, which is not identical to being online.
Wednesday, September 30, 2009
Thursday, July 09, 2009
Function points and webservices
Function points are widely used to give an accurate measure of the size of an application. This application size is usually applied as an indication to measure the cost of building the application, or to estimate the cost of maintenance of the application.
The nesma counting guidelines version 2.2 generally give clear directions how several situations should be counted. However, the guidlines do not explicitly answer several questions which arise from modern technology. An internal workgroup in Nesma has been working on guidelines for over 2 years, but till now this has not resulted in a guideline on how to deal with new technology.
In this post, I will give my opinion on how a system with web services should be counted, and why. I welcome your opinions on this subject.
The first question is: Should they count at all? And if so, under which conditions?
In the first example, let us have a look at an application with a userinterface some webservices and some databases.
It is depicted in figure 1.
The main principle of Function Points, both nesma and ifpug, is that functionality should be counted, not technology.
Applied to the situation, this means that if the webservices are created because they are "standard architecture" required by the IT-department, the webservices should not be counted.
The situation changes in figure 2.
Here we are counting system A. The systems S and C and ? are other systems, outside the scope of this function point count. For our purpose, it does not matter who the owner of these systems is: another company, or another department within the same company, or even the same department.
Our knowledge of these systemes can be very limited. Sometimes we even dont know the names and owners of these systems. In fact, we may not even know which systems use the interface, or how many. This is reflected by the systems ? in the figure.
Figure 2 shows that System A has a webservice Alpha, which can be addressed from outside System A. Webservice A is an interface which enables the world to put information into System A.
System A has a webservice Beta, which is used internally. Webservice Gamma is an interface offered by System A to the outside world to retrieve information from System A.
The webservices Alpha and Gamma have been built because there are business requirements demanding that the system offers interfaces which enable other systems to feed System A and to retrieve information from system A.
That makes the webservices Alpha and Gamma something required by the user, and thus they should be considered for counting.
Let us have a look at this situation on an even more abstract level. Basically what we have is System A (the system to count) and interfaces with Systems C and S.
FPA has a standard way to deal with interfaces between systems. This has been defined in terms of "External Interface Files". This is in itself a slightly outdated technical terminology, the name "external source of data" would have been more appropriate.
Webservice Alpha receives requests from some external agent to store certain information in the system. The external agent does not need to have infomation on how and where the informaton is stored in System A, just that it needs to be stored and if the process of storing was succesfull.
How and where the information is stored, and which business rules are applied, should be described in the description of the webservice. For System A this webservice is an input function, and should be counted as such. The situation is comparable with an import function with a file from outside the application, as described in chapter 6 and chapters 4.21 and 4.22 of the nesma counting guidelines.
Nesma defines an External Interface File (EIF) as a set of permanent data which
a - is used by the system being counted,
b - is not being maintanied by the system being counted
c - is being maintained by another system than the system being counted
d - is directly accesible by the system being counted.
When we have a look at webservice Alpha, it is used by the system being counted. But it would be artificial, though not impossible, to regard it as a collection of information which is maintained by the system. Rather, it is an interface which provides input functionality into the system we are counting.
This webservice Alpha offers a functionality where information passes the system boudary. It offers a way to input information into the application, just as a batch or a screen would. Thus we should consider it as an external input function. Just to be sure, let us check the defintion of an input function, as given in chapter 7 of the nesma guidelines:
it must be a unique, by the user defined, function where information from outside the information system is brought into the system.
It will be clear that the webservice Alpha provides an interface, just like a screen, to bring information into system A. Still assuming that it was brought into existence as per user requirement as stated above, it satisfies all aspects of this definition, except perhaps the word Unique. If system A would also have a screen input, which has exactly the same functionality and data elements as this webservice Alpha, webservice Alpha would not be unique and should not be counted seperately.
For webservice Gamma, the same principles apply. Again it does not really satisfy the conditions of an external interface file, for the second condition: b - we can not say that it is maintained by another system.
Again, we do have information which transcends the system boundary. Depending on the type of information offered by the webservice, we will have either an External output or en external enquiry.
Figure 2 does not concern itself by how System C should regard webservice Gamma. This situation is depicted in figure 4.
As System C will generally not have and should not have any knowledge of what is going in webservice Gamma, webservice Gamma should be regarded as an external interface file for system C.
If System C uses the information for display on a report or screen, as depicted in the illustration, it should be regarded as a data storage being used by the report or screen (EO).
If system C uses this information to store it in its own database, this function should be regarded as an input function, and webservice Gamma should be counted an external datastorage for System C, used by this EI.
The nesma counting guidelines version 2.2 generally give clear directions how several situations should be counted. However, the guidlines do not explicitly answer several questions which arise from modern technology. An internal workgroup in Nesma has been working on guidelines for over 2 years, but till now this has not resulted in a guideline on how to deal with new technology.
In this post, I will give my opinion on how a system with web services should be counted, and why. I welcome your opinions on this subject.
The first question is: Should they count at all? And if so, under which conditions?
In the first example, let us have a look at an application with a userinterface some webservices and some databases.
It is depicted in figure 1.
The main principle of Function Points, both nesma and ifpug, is that functionality should be counted, not technology.
Applied to the situation, this means that if the webservices are created because they are "standard architecture" required by the IT-department, the webservices should not be counted.
The situation changes in figure 2.
Here we are counting system A. The systems S and C and ? are other systems, outside the scope of this function point count. For our purpose, it does not matter who the owner of these systems is: another company, or another department within the same company, or even the same department.
Our knowledge of these systemes can be very limited. Sometimes we even dont know the names and owners of these systems. In fact, we may not even know which systems use the interface, or how many. This is reflected by the systems ? in the figure.
Figure 2 shows that System A has a webservice Alpha, which can be addressed from outside System A. Webservice A is an interface which enables the world to put information into System A.
System A has a webservice Beta, which is used internally. Webservice Gamma is an interface offered by System A to the outside world to retrieve information from System A.
The webservices Alpha and Gamma have been built because there are business requirements demanding that the system offers interfaces which enable other systems to feed System A and to retrieve information from system A.
That makes the webservices Alpha and Gamma something required by the user, and thus they should be considered for counting.
Let us have a look at this situation on an even more abstract level. Basically what we have is System A (the system to count) and interfaces with Systems C and S.
FPA has a standard way to deal with interfaces between systems. This has been defined in terms of "External Interface Files". This is in itself a slightly outdated technical terminology, the name "external source of data" would have been more appropriate.
Webservice Alpha receives requests from some external agent to store certain information in the system. The external agent does not need to have infomation on how and where the informaton is stored in System A, just that it needs to be stored and if the process of storing was succesfull.
How and where the information is stored, and which business rules are applied, should be described in the description of the webservice. For System A this webservice is an input function, and should be counted as such. The situation is comparable with an import function with a file from outside the application, as described in chapter 6 and chapters 4.21 and 4.22 of the nesma counting guidelines.
Nesma defines an External Interface File (EIF) as a set of permanent data which
a - is used by the system being counted,
b - is not being maintanied by the system being counted
c - is being maintained by another system than the system being counted
d - is directly accesible by the system being counted.
When we have a look at webservice Alpha, it is used by the system being counted. But it would be artificial, though not impossible, to regard it as a collection of information which is maintained by the system. Rather, it is an interface which provides input functionality into the system we are counting.
This webservice Alpha offers a functionality where information passes the system boudary. It offers a way to input information into the application, just as a batch or a screen would. Thus we should consider it as an external input function. Just to be sure, let us check the defintion of an input function, as given in chapter 7 of the nesma guidelines:
it must be a unique, by the user defined, function where information from outside the information system is brought into the system.
It will be clear that the webservice Alpha provides an interface, just like a screen, to bring information into system A. Still assuming that it was brought into existence as per user requirement as stated above, it satisfies all aspects of this definition, except perhaps the word Unique. If system A would also have a screen input, which has exactly the same functionality and data elements as this webservice Alpha, webservice Alpha would not be unique and should not be counted seperately.
For webservice Gamma, the same principles apply. Again it does not really satisfy the conditions of an external interface file, for the second condition: b - we can not say that it is maintained by another system.
Again, we do have information which transcends the system boundary. Depending on the type of information offered by the webservice, we will have either an External output or en external enquiry.
Figure 2 does not concern itself by how System C should regard webservice Gamma. This situation is depicted in figure 4.
As System C will generally not have and should not have any knowledge of what is going in webservice Gamma, webservice Gamma should be regarded as an external interface file for system C.
If System C uses the information for display on a report or screen, as depicted in the illustration, it should be regarded as a data storage being used by the report or screen (EO).
If system C uses this information to store it in its own database, this function should be regarded as an input function, and webservice Gamma should be counted an external datastorage for System C, used by this EI.
Tuesday, July 07, 2009
Translation
Translation is a problem as old as the tower of Babylon. Yesterday I was looking for the translation of the dutch word "verband", as applied to wounds.
Now this word has many meanings, depending upon context. The oldest well known translator on the web, babelfish, took just 1 meaning, and translated it as "link".
This morning my google page advertised microsofts new translator, bing. Sadly, it also came up with just 1 translation, albeit a different one: "link". This also is a correct translation.
There is however a not superwuick, but rather efficient way to translate the word. I went to the dutch wikipedia, and looked up the word "verband". Wikipedia presented me with a page in which the various meanings were sorted out. The one i wanted was among them, and i selected that. In the left column was the list of articles in other languages on the same subject, and i picked english. This led me to "dressing", which upon seeing i identified as a corrcet trnaslation of what I had in mind.
Now the wiki guys are also working on a dictionary, called wiktionary, but this is far from complete compared with wikipedia. I much prefer the wikipedia route.
Now this word has many meanings, depending upon context. The oldest well known translator on the web, babelfish, took just 1 meaning, and translated it as "link".
This morning my google page advertised microsofts new translator, bing. Sadly, it also came up with just 1 translation, albeit a different one: "link". This also is a correct translation.
There is however a not superwuick, but rather efficient way to translate the word. I went to the dutch wikipedia, and looked up the word "verband". Wikipedia presented me with a page in which the various meanings were sorted out. The one i wanted was among them, and i selected that. In the left column was the list of articles in other languages on the same subject, and i picked english. This led me to "dressing", which upon seeing i identified as a corrcet trnaslation of what I had in mind.
Now the wiki guys are also working on a dictionary, called wiktionary, but this is far from complete compared with wikipedia. I much prefer the wikipedia route.
Friday, July 03, 2009
outlook life hack
Outlook is alas the obligatory email client in the office. For years i have complained about the lack of grouping emails. One of gmails main advantages is that it groups emails in threads, enabling me to digest an entire discussion of in one go.
I have been told that MS Office 2010 will have this ability too. But hanging the transfer of msdn licenses from getronics to capgemini, i am stuck with office and thus outlook 2003.
But today there i fund a small hack, which does not solve all, but at least goes a small step. Outlook has a field called "Conversation". This field is identical to "Subject", but stripped of "Re" and "Fw".
In outlook, right click on the fields bar with all your emails, select "fields chooser" and pick "Conversation". Set it in front of "Subject", and sort on that field.
Some useful links:
http://lifehacker.com/
http://www.lifehack.org/
http://en.wikipedia.org/wiki/Life_hacking
http://office.microsoft.com/en-us/outlook/HA010970221033.aspx
I have been told that MS Office 2010 will have this ability too. But hanging the transfer of msdn licenses from getronics to capgemini, i am stuck with office and thus outlook 2003.
But today there i fund a small hack, which does not solve all, but at least goes a small step. Outlook has a field called "Conversation". This field is identical to "Subject", but stripped of "Re" and "Fw".
In outlook, right click on the fields bar with all your emails, select "fields chooser" and pick "Conversation". Set it in front of "Subject", and sort on that field.
Some useful links:
http://lifehacker.com/
http://www.lifehack.org/
http://en.wikipedia.org/wiki/Life_hacking
http://office.microsoft.com/en-us/outlook/HA010970221033.aspx
Tuesday, March 03, 2009
Javascript menus
Most websites these dates are built with a database, php or asp.net. In both php and asp.net it is no problem to build a functiion that generates your menu for all your pages. That is nice, because it means you have to maintain your menu only once: when your menu changes, when an exptar page becomes available, you dont have to change tenths of pages, changing just that one module is sufficient.
But there are still numerous websites that are still html/xml, stylesheets and javascript. Of course you can use frames to attain the same effect: simply have 2 frames, a small left one for your menu and a wide right one for you contents. And voila, you have to maintain your menu only once.
But... frames are on the way out.
But for sure, code like:
<pre>
<html>
<frameset cols="180px,50%,180px">
<frame src="frame_a.html" />
<frame src="frame_b.html" />
<frame src="frame_c.html" />
</frameset>
</html>
</pre>
will execute properly in both IE7 en FF3.
You can aslo modify it easily to add a header and footer:
<pre>
<html>
<frameset rows="80px,50%,60px">
<frame src="frame_d.html" />
<frame src="frame_previous.html" />
<frame src="frame_f.html" />
</frameset>
</html>
</pre>
The page "frame_previous.html" refers of course to the previous html page displayed above. The combination gives you a solid layout with header, footer and 3 columns in between.
But as noted, frames are no longer considered sexy, and frames are on the way out. One reason no doubt is that for frames you need DTD "HTML 4.01 Frameset", which is incompatible with say xhtml.
So designers and builders have to look for an alternative. The way to go for layouts are divs. But divs have no includes, and neither has html. There is a way out, however, and that is through javascript. Javascript can be stored in separate javascript files, and included in any html page. Javascript can write html, and we can simply misuse this to have a javascript function which writes a menu in a div.
Example:
menuscript.js:
function WriteMenu()
{
document.write('<a href="Main.html">Main</a><br />');
document.write('<a href="Option1.html">Option 1</a><br />');
document.write('<a href="Option2.html">Option 2</a><br />');
}
demo.html:
<div id='title'>
title
</div>
<div id='left_column'>
WriteMenu();
</div>
<div id='contents'>
contents
</div>
<div id='footer'>
footer
</div>
But there are still numerous websites that are still html/xml, stylesheets and javascript. Of course you can use frames to attain the same effect: simply have 2 frames, a small left one for your menu and a wide right one for you contents. And voila, you have to maintain your menu only once.
But... frames are on the way out.
But for sure, code like:
<pre>
<html>
<frameset cols="180px,50%,180px">
<frame src="frame_a.html" />
<frame src="frame_b.html" />
<frame src="frame_c.html" />
</frameset>
</html>
</pre>
will execute properly in both IE7 en FF3.
You can aslo modify it easily to add a header and footer:
<pre>
<html>
<frameset rows="80px,50%,60px">
<frame src="frame_d.html" />
<frame src="frame_previous.html" />
<frame src="frame_f.html" />
</frameset>
</html>
</pre>
The page "frame_previous.html" refers of course to the previous html page displayed above. The combination gives you a solid layout with header, footer and 3 columns in between.
But as noted, frames are no longer considered sexy, and frames are on the way out. One reason no doubt is that for frames you need DTD "HTML 4.01 Frameset", which is incompatible with say xhtml.
So designers and builders have to look for an alternative. The way to go for layouts are divs. But divs have no includes, and neither has html. There is a way out, however, and that is through javascript. Javascript can be stored in separate javascript files, and included in any html page. Javascript can write html, and we can simply misuse this to have a javascript function which writes a menu in a div.
Example:
menuscript.js:
function WriteMenu()
{
document.write('<a href="Main.html">Main</a><br />');
document.write('<a href="Option1.html">Option 1</a><br />');
document.write('<a href="Option2.html">Option 2</a><br />');
}
demo.html:
<div id='title'>
title
</div>
<div id='left_column'>
WriteMenu();
</div>
<div id='contents'>
contents
</div>
<div id='footer'>
footer
</div>
Thursday, November 20, 2008
Use case point - Gustav Karners method evaluated
There are several remarks to be made about Gustavs method for estimating applications development costs.
First is that, contrary to what has been suggested, the method gives a number of UCP as the size of an application. Some authors on the web incorrectly conclude that Gustav measured hours, not size. But Gustav seems well aware of the distinction when he writes "It starts with measuring the functionality of the system based on the use case model in a count called Unadjusted Use Case Point (UUCP)".
Second, in the reference at the bottom of his post Gustav bases his constants on just 3 projects. That number is of course way to low to base formulas on.
Luckily Bente Anda of the university of Oslo has taken up this issue and evaluated the formulas for 37 projects. The result was that the use case points method gave an estimate that was closer to the actual effort spent on implementing the system than most estimates made by 37 experienced professional software developers divided into 11 groups. It also pointed out that a combination of UCP and experrtt estimates is the best way to go.
Edward R. Carroll claims: After applying the process across hundreds of sizable (60 manmonths average) software projects, we have demonstrated metrics that prove an estimating accuracy of less than 9 percent deviation from actual to estimated cost on 95 percent of our projects. Our process and this success factor are documented
over a period of five years, and across more than 200 projects.
This research at least gives some solid base under the method.
One assumption that nearly all authors make is that it is an absolute must that use cases are on the same detail level. And of course the more detailed Use Cases are, the more accurate the estimates will be. cap gemini even goes so far as to advise to go to "fish level", that is, to distinguish the importnt sugfunctions. They count these subfunctions, and even have a library of type-examples to support these counts.
A valid question is wether it makes sense to count function points based on use cases. The nesma, the dutch function point organization, thinks it does. In an article they detail how the sepcifications for a function point count can be retrieved from use Cases. Of course these are not Use Case Points, they require you are a certified or very experienced FP-expert. And even then it remains some work to distill the FP-details from the Use Cases. Judging from what they write, it is not a quick method.
At a course last week on rup iterative development i was surpised to see that IBM now includes the Gustav use case points in RUP> Imho this greatly improves the chances of this branch winning out, though i foresee much stricter guidelines in the future about the levels of detail in Use Cases than we have now, just to ensure that estimates will
Nice anecdote:
"Sander, could you estimate the hours for this project?"
"Boss, sure, how much time do I have?"
"Sander, I guess I should have asked this earlier, but I must have the estimate in 1 hour if we want to have this order."
50 minutes later:
"Boss, In 1 hour of course I can not give a thorough estimate. But if you want to have a completely arbitrary number: we have 10 classes, and 180 pages in the RFP document, so I estimate the effort at 10*180=1800 hours."
"Thanks, great"
1 week later:
"Sander, good news: our offer has been approved based on your estimate and you are in the team!"
Several months later:
"Boss, we finished the project is slightly under 1800 hours."
References:
* http://www.bfpug.com.br/Artigos/UCP/Anda-Comparing_Effort_Estimates_Based_on_UCP.pdf
* http://royclemmons.com/articles/docs/0602Clemmons.pdf Article by Roy Clemmens
* Carroll, Edward R. “Estimating Software Based on Use Case Points.” 2005 Object-Oriented, Programming, Systems, Languages, and Applications (OOPSLA) Conference, San Diego, CA, 2005.
* http://www.nesma.nl/download/gidsen/FPA%20toegepast%20bij%20UML%20(1.0).pdf
First is that, contrary to what has been suggested, the method gives a number of UCP as the size of an application. Some authors on the web incorrectly conclude that Gustav measured hours, not size. But Gustav seems well aware of the distinction when he writes "It starts with measuring the functionality of the system based on the use case model in a count called Unadjusted Use Case Point (UUCP)".
Second, in the reference at the bottom of his post Gustav bases his constants on just 3 projects. That number is of course way to low to base formulas on.
Luckily Bente Anda of the university of Oslo has taken up this issue and evaluated the formulas for 37 projects. The result was that the use case points method gave an estimate that was closer to the actual effort spent on implementing the system than most estimates made by 37 experienced professional software developers divided into 11 groups. It also pointed out that a combination of UCP and experrtt estimates is the best way to go.
Edward R. Carroll claims: After applying the process across hundreds of sizable (60 manmonths average) software projects, we have demonstrated metrics that prove an estimating accuracy of less than 9 percent deviation from actual to estimated cost on 95 percent of our projects. Our process and this success factor are documented
over a period of five years, and across more than 200 projects.
This research at least gives some solid base under the method.
One assumption that nearly all authors make is that it is an absolute must that use cases are on the same detail level. And of course the more detailed Use Cases are, the more accurate the estimates will be. cap gemini even goes so far as to advise to go to "fish level", that is, to distinguish the importnt sugfunctions. They count these subfunctions, and even have a library of type-examples to support these counts.
A valid question is wether it makes sense to count function points based on use cases. The nesma, the dutch function point organization, thinks it does. In an article they detail how the sepcifications for a function point count can be retrieved from use Cases. Of course these are not Use Case Points, they require you are a certified or very experienced FP-expert. And even then it remains some work to distill the FP-details from the Use Cases. Judging from what they write, it is not a quick method.
At a course last week on rup iterative development i was surpised to see that IBM now includes the Gustav use case points in RUP> Imho this greatly improves the chances of this branch winning out, though i foresee much stricter guidelines in the future about the levels of detail in Use Cases than we have now, just to ensure that estimates will
Nice anecdote:
"Sander, could you estimate the hours for this project?"
"Boss, sure, how much time do I have?"
"Sander, I guess I should have asked this earlier, but I must have the estimate in 1 hour if we want to have this order."
50 minutes later:
"Boss, In 1 hour of course I can not give a thorough estimate. But if you want to have a completely arbitrary number: we have 10 classes, and 180 pages in the RFP document, so I estimate the effort at 10*180=1800 hours."
"Thanks, great"
1 week later:
"Sander, good news: our offer has been approved based on your estimate and you are in the team!"
Several months later:
"Boss, we finished the project is slightly under 1800 hours."
References:
* http://www.bfpug.com.br/Artigos/UCP/Anda-Comparing_Effort_Estimates_Based_on_UCP.pdf
* http://royclemmons.com/articles/docs/0602Clemmons.pdf Article by Roy Clemmens
* Carroll, Edward R. “Estimating Software Based on Use Case Points.” 2005 Object-Oriented, Programming, Systems, Languages, and Applications (OOPSLA) Conference, San Diego, CA, 2005.
* http://www.nesma.nl/download/gidsen/FPA%20toegepast%20bij%20UML%20(1.0).pdf
Tuesday, October 28, 2008
Use Case Points
Use Cases are, even more than architecture, THE hype in design. Every system nowadays should be modelled with Use Cases. Don't misunderstand me: I don't oppose Use Cases, on the contrary. But every method has its disadvantages, and no doubt some day an even better method will turn up.
For the moment, they are a reasonable good design tool. Reasonably good, because non technical users seem to understand the system better than the previous, rather technical specifications we designers wrote.
With lots of people designing Use Cases, it is not surprising that a new method has been proposed to estimate the size of systems for development based on Use Cases.
Let's give a short recap of the main stuff a Use Case consists of:
In addition, some other sections should be part of any good template:
That having said, lets proceed to Use Cases Points.
These are base on work by Gustav Karner in 1993. In a way, they are a sequel to Function Point Analysis.
Let me describe Use Case Points in more detail. Use Case Points are intended to estimate the amount of hours required to realize a series of Use Cases.
The Use Case Point method also slightly seems to be based on the FPA system.
Let's start with the formula:
Legenda:
UCP = Use Case Points
UUCW = Unadjusted Use Case Weight
UAW = Unadjusted Actor Weight
TCF = Technical Complexity Factor
ECF = Environment Complexity Factor
This number of Use Case Points is multiplied with a PF (Productivity Factor) to get a number of hours required to realize the scenario.
Note that this is a slight deviation from the descriptions you will find elsewhere.
Most descriptions have the PF as part of the formula, but I think this is not a good way to represent it. Use Case points, like Function Points, should be a measure for the size of the application, not a number of hours.
Let's have a closer look at each of these variables, and how to count them. My apologies that all tables in this post have a lengthy blank space above them, I'll try to figure out what causes them but at the moment lack the time to do so.
UUCW: Unadjusted Use Case Weight
Other classifications can also be found. One text i encountered uses the word "transactions" instead of scenarios. IBM states: fewer than 4 key scenarios or execution paths in the UC.
Personally I feel that the nuber of classes involved certainly is also a degree for the complexity. A Use Case which has only 1 scenario (calculate Gross-Netto for wage) may have only 1 step, but may, dependant on the fiscal system of a country and the payment system of the company, easily involve anywhere from 10-30 of even more classes. For this reason I have left them in.
The Weight column gives the number of Unadjusted Use Case Points (UUCP) for each Use Cases with these characteristics.
Example:
The same logic is applied to Actors: Actors are classified as simple, average and complex.
Example:
The sum of Unadjusted Use Case Weight and Unadjusted Actor Weight gives the Unadjusted Use Case Points, or in formula:
These UUCP are adjusted for Technical and Environment Factors to arrive at the Adjusted Use Case Points AUCP.
A list of 12 Technical factors are considered, and again each factor is assigned a weight:
Every factor is estimated on a scale of 0-5 for its perceived value. Then the Technical Correction Factor is calculated with the formula:
Example:
The Environment Correction Factor represents things in the environment that greatly influence the project. Again, these variables are processed the same way that Technical Correction Factors are treated: Each factor is assigned a relative weight, each factor is estimated on a scale of 0-5 and the product is the EF for that Factor.
Example:
We have a team that knows the application inside out, and also has years of experience with objectorientation. Alas the requiremebnts are known to be vulnerable for change. The team consists for a majority of part time workers.
This gives a total of 8,5, making the environment correction factor:
Sources:
For the moment, they are a reasonable good design tool. Reasonably good, because non technical users seem to understand the system better than the previous, rather technical specifications we designers wrote.
With lots of people designing Use Cases, it is not surprising that a new method has been proposed to estimate the size of systems for development based on Use Cases.
Let's give a short recap of the main stuff a Use Case consists of:
- Actor(s) : Actors can be persons, but also interfaces with other systems.
- Goal: An Actor should have a goal that (s)he tries to accomplish
- Main scenario: This scenario describes the steps to take to accomplish the earlier described goal.
- Alternative scenarios: Due to business rules such as constrictions, or due to judgment by the actor, alternate scenarios may be described.
- Pre- condition: Conditions that must be fullfilled before at the Start of the Scenario
In addition, some other sections should be part of any good template:
- Post-condition: A condition that must be satisfied at the end of the Use Case
- LOM references
- Business Rules referenced
- Author: The author of the Use Case
- Extensions: Note that some gurus believe these should be forbidden
- Includes: Some situations may be part of multiple Use Cases. In such a case, it may be a good idead to create a separate Use Case which is regarded as "included" in other Use Cases.
- Other requirements: usually technical requirements, such as : batches for 200.000 people should be processed in no more than 4 hours.
That having said, lets proceed to Use Cases Points.
These are base on work by Gustav Karner in 1993. In a way, they are a sequel to Function Point Analysis.
Let me describe Use Case Points in more detail. Use Case Points are intended to estimate the amount of hours required to realize a series of Use Cases.
The Use Case Point method also slightly seems to be based on the FPA system.
Let's start with the formula:
UCP = (UUCW+UAW) * TCF * ECF
Legenda:
UCP = Use Case Points
UUCW = Unadjusted Use Case Weight
UAW = Unadjusted Actor Weight
TCF = Technical Complexity Factor
ECF = Environment Complexity Factor
This number of Use Case Points is multiplied with a PF (Productivity Factor) to get a number of hours required to realize the scenario.
Note that this is a slight deviation from the descriptions you will find elsewhere.
Most descriptions have the PF as part of the formula, but I think this is not a good way to represent it. Use Case points, like Function Points, should be a measure for the size of the application, not a number of hours.
Let's have a closer look at each of these variables, and how to count them. My apologies that all tables in this post have a lengthy blank space above them, I'll try to figure out what causes them but at the moment lack the time to do so.
UUCW: Unadjusted Use Case Weight
Other classifications can also be found. One text i encountered uses the word "transactions" instead of scenarios. IBM states: fewer than 4 key scenarios or execution paths in the UC.
Personally I feel that the nuber of classes involved certainly is also a degree for the complexity. A Use Case which has only 1 scenario (calculate Gross-Netto for wage) may have only 1 step, but may, dependant on the fiscal system of a country and the payment system of the company, easily involve anywhere from 10-30 of even more classes. For this reason I have left them in.
The Weight column gives the number of Unadjusted Use Case Points (UUCP) for each Use Cases with these characteristics.
Example:
The same logic is applied to Actors: Actors are classified as simple, average and complex.
Example:
The sum of Unadjusted Use Case Weight and Unadjusted Actor Weight gives the Unadjusted Use Case Points, or in formula:
UUCP = UUCW + UAW
These UUCP are adjusted for Technical and Environment Factors to arrive at the Adjusted Use Case Points AUCP.
A list of 12 Technical factors are considered, and again each factor is assigned a weight:
Every factor is estimated on a scale of 0-5 for its perceived value. Then the Technical Correction Factor is calculated with the formula:
TCF = 0.6 + sum(perceived value*weight)/100
Example:
TCF = 0.6 + 30.5/100 = 0.905
The Environment Correction Factor represents things in the environment that greatly influence the project. Again, these variables are processed the same way that Technical Correction Factors are treated: Each factor is assigned a relative weight, each factor is estimated on a scale of 0-5 and the product is the EF for that Factor.
ECF = 1,4 - 3 * sum(perceived value * weight)/100
Example:
We have a team that knows the application inside out, and also has years of experience with objectorientation. Alas the requiremebnts are known to be vulnerable for change. The team consists for a majority of part time workers.
This gives a total of 8,5, making the environment correction factor:
ECF = 1.4 - 3*8.5/100 = 1.145
Sources:
- http://www.bfpug.com.br/Artigos/UCP/Karner%20-%20Resource%20Estimation%20for%20Objectory%20Projects.doc Gustav Karner, 1993, doctoral thesis.
- http://www.uea.ac.uk/~a168955/effort_estimation/use_case_points.html, Use Case Points Method
- http://www.codeproject.com/KB/architecture/usecasep.aspx Project Estimation with Use Case Points, by Roy Clemmens
- http://www.methodsandtools.com/archive/archive.php?id=25 Estimating With Use Case Points, by Mike Cohn,
- http://www.stsc.hill.af.mil/crosstalk/2006/02/0602Clemmons.pdf Project Estimation With Use Case Points, by Roy Clemmens
- http://www.ibm.com/developerworks/rational/library/2870.html Dr Use Case at IBM
Tuesday, September 30, 2008
E-mail overload
It is surprising that the amount of email is still growing slowly. Or rather, not that the amount of email in absolute terms is growing, but that long time users like me still slowly receive more and more email.
And i'm not the only one. Browsing over the web i came across several websites with terms like "email bankrupticy" - that term now has over 10 million hits at google.
Those people are a lot worse off than me: this morning when I arrived at the office I had only 30 unread emails in my office inbox, and about 50 in my gmail account.
Over the years, I have developed several rules which limit the amount of email in my inbox, and which help me to cope with them.
And i'm not the only one. Browsing over the web i came across several websites with terms like "email bankrupticy" - that term now has over 10 million hits at google.
Those people are a lot worse off than me: this morning when I arrived at the office I had only 30 unread emails in my office inbox, and about 50 in my gmail account.
Over the years, I have developed several rules which limit the amount of email in my inbox, and which help me to cope with them.
- The less emails I write, the less I receive.
Emails invoke replies by email.
I try not to write emails:
- to cover my ass
- to inform fellow workers in the same room (there are always exceptions)
- which are a 2nd reply to some one. This ends endless debates.
- for things which require a speedy answer - phones are much better at that
- for explanations which are likely to invite further questions - phones are much better suited at this. - Avoid irritation
An old courtesy rule is: DONT USE CAPITALS! - Using capitals is the internet way to shout, and shouting is impolite.
But there are lots of other ways to annoy people. I found it is much better to phone people when i feel irritated, than to reply to their email - heat always sips through. - Long emails invite long replies, short emails invite short replies
So if i want a brief answer, i write a brief email. - Organize incoming email
Gmail does a fantastic job at this. All replies and forwards are stored with the original message in 1 thread, and all emails can be read in sequence. In fact you are naturally invited to combine the information in all related emails before you start to react on the email. This is a great time saver for handling incoming email: the 50 emails i received on my gmail account i could dispose of in about 5 minutes. about 3 of them were forwards by my wife, a matter of simply reading and archiving. Over 40 were from the wikimedia foundation: from the title of the topic it was clear these discussions did not interest me and i could archive them straight away: 3 clicks for over 40 emails.
In comparison: the emails in MS Outlook can not even be sorted well on topic, as the FW: and RE tages in fron of the subject spoil the sorting. MS would do a great service to the world if they built in an option to seperate these tags from incoming and sent emails, and present them in a separate column.
For the time being, i'll try to write an ms outlook macro which strips the tags from the subject. If you happen to know such a macro, please let me know! - Rules
Whatever your tool is, rules are very handy to sort and handle email. I have subscriptions to several newsletters, discussion boards, and tools for administrating projects / bugs / wishes. These tools send me information when something changes which might be of interest to me. I dont want to stop these automatic signals - sometimes they are important. Our customer uses Team Foundation System to register bugs, and we use Bugtracker to register bugs in relation to our subcontractor in India. Both send me an update for every edit made. I have already cut down in TFS the number of emails i want to receive, but not all signals are immediatly important. A signal that something changed is important in the quiet days of a project, while on the busyu days i want to schedule my visits to TFS myself.
The same applies to Bugtracker. So i define rules in outlook that moves these emails to a separate folder. The fact that it is bold is sufficient for me to know that i have to visit that tool.
Tuesday, July 29, 2008
MS Office
The customer i am working for is still using microsoft office 2003, i think, though i really got to check if it isnt ms office 2000.
And that office has a strange quirk: if i have 2 word documents in different directories but with the same name, ms word is happy to have them open at the same time.
But the same is not true for ms excel. If i open a document Expert estmation project 1.xls from file, and i open a file with the same name from sharepoint, ms excel will refuse to open it.
No doubt there will be a valid technical reason for it, but to me as a user it looks rather inconsistent to me :-)
And that office has a strange quirk: if i have 2 word documents in different directories but with the same name, ms word is happy to have them open at the same time.
But the same is not true for ms excel. If i open a document Expert estmation project 1.xls from file, and i open a file with the same name from sharepoint, ms excel will refuse to open it.
No doubt there will be a valid technical reason for it, but to me as a user it looks rather inconsistent to me :-)
Monday, April 21, 2008
10 reasons to use gmail and not hotmail/livemail
Reason 1: No Spam
Your gmail account has efficient spam filters. In hotmail, i time and again got spam, and yahoo is even worse. In gmail, spam messages in my inbox are rare.
Reason 2: Better filters
Im gmail, you can set many autofilters which are not available in hotmail. True, with hotmail/livemail you can create a filter to automatically move an email to a folder. You can search the topic or the addressline. I dont see an option to search the body of an email.
Reason 3: Labels
In gmail, you can attach one or more labels to an email. Labels are different from folders. An email can be in only one folder, but may have more than one label. For example, if you are a member of a political party, and also an environment acivist, you would have to sort emails which concern both in one of them.
But then it is out of your inbox, and out of sight. With gmail labels, you can automatically attack a label, or autoarchive it, just as you please.
Gmail can automatically add labels based on both the topic and the contents of an email.
Reason 4: More Space
Hotmail gives you 5Gb, and Gmail 6.x (at the moment of writing) and growing daily.
Reason 5: Threading
Gmail groups emails in threads. In your inbox, you see the names of the threads (subjects of your emails) and the number of messages in the thread. When you open a thread, gmail displays all old messages as collapsed, while the first unread message is showed open. A great time saver.
Reason 6: Less is more.
Gmail has less distracting adds, it has less chrome, less images, less colors and is thus easier to use. Your mind is less distracted and has to search less.
Reason 7: Archive, dont delete.
With growing archive space, Gmail encourages you to arcghive instead of deleting messages. Virtually all hotmail users i know delete their messages instead of moving them to folders.
Reason 8: Dont expire.
Dont use your hotmail account for a month and you have lost your emails, including those holidy pix, including that valuable family photo, including that emailed password. No doubt Gmail has some expiration limit too, but i havent seen my emails deleted when i forgot to access my account for 1 month.
Reason 9: Variations in name.
If your emailaddress is JohnJohnsson@gmail.com, you can send an email to JohnJohnsson+testexpert@gmail.com and it will arrive in your normal email box. But you can use that extra "+testexpert" to automatically attach a label. Sending the same to hotmail results in "it was rejected by the recipient domain". This is also very convenient when signing up for a service somewhere on the web - you can find emails related to their service in your normal archive by searching for this email address.
Reason 10: Better security.
Need i say anything?
No ads
Live mail adds advertisements to the bottom of your email - gmail doesnt
Your gmail account has efficient spam filters. In hotmail, i time and again got spam, and yahoo is even worse. In gmail, spam messages in my inbox are rare.
Reason 2: Better filters
Im gmail, you can set many autofilters which are not available in hotmail. True, with hotmail/livemail you can create a filter to automatically move an email to a folder. You can search the topic or the addressline. I dont see an option to search the body of an email.
Reason 3: Labels
In gmail, you can attach one or more labels to an email. Labels are different from folders. An email can be in only one folder, but may have more than one label. For example, if you are a member of a political party, and also an environment acivist, you would have to sort emails which concern both in one of them.
But then it is out of your inbox, and out of sight. With gmail labels, you can automatically attack a label, or autoarchive it, just as you please.
Gmail can automatically add labels based on both the topic and the contents of an email.
Reason 4: More Space
Hotmail gives you 5Gb, and Gmail 6.x (at the moment of writing) and growing daily.
Reason 5: Threading
Gmail groups emails in threads. In your inbox, you see the names of the threads (subjects of your emails) and the number of messages in the thread. When you open a thread, gmail displays all old messages as collapsed, while the first unread message is showed open. A great time saver.
Reason 6: Less is more.
Gmail has less distracting adds, it has less chrome, less images, less colors and is thus easier to use. Your mind is less distracted and has to search less.
Reason 7: Archive, dont delete.
With growing archive space, Gmail encourages you to arcghive instead of deleting messages. Virtually all hotmail users i know delete their messages instead of moving them to folders.
Reason 8: Dont expire.
Dont use your hotmail account for a month and you have lost your emails, including those holidy pix, including that valuable family photo, including that emailed password. No doubt Gmail has some expiration limit too, but i havent seen my emails deleted when i forgot to access my account for 1 month.
Reason 9: Variations in name.
If your emailaddress is JohnJohnsson@gmail.com, you can send an email to JohnJohnsson+testexpert@gmail.com and it will arrive in your normal email box. But you can use that extra "+testexpert" to automatically attach a label. Sending the same to hotmail results in "it was rejected by the recipient domain". This is also very convenient when signing up for a service somewhere on the web - you can find emails related to their service in your normal archive by searching for this email address.
Reason 10: Better security.
Need i say anything?
No ads
Live mail adds advertisements to the bottom of your email - gmail doesnt
Tuesday, April 15, 2008
Stakeholders - how to model them
UML is all about visual modelling, and though Unified Process has made UML the default modelling technique, it does not visually define stakeholders or their relation to the stakeholder requests.
Personally I find this a shortcoming, and I have been thinking about ways to model stakeholders, their types, their relations and their interests in stakeholders requests.
Stakeholder analysis is a rapidly growing area wth its main applications in politics and management. For RUP purposes, we usually don't need to model all properties and relations between stakeholders. Moreover, as circulstances, and thus stakeholders, can change frequently, it is often not very wise too spend too much time and effort on stakeholder analysis, as many projects should and will be short.
But for Requirements Management it is wise to link Use Cases to stakeholder requests, and Stakeholder requests to Stakeholders. By linking Use Cases to Stakeholder Requests, we can check that no Use Cases creep in that are not supported by Stakeholder requests. By linking Stakeholder requests to Stakeholders, we can make sure that these Use cases are requested by at least one Stakeholder.
"Traditionally" (for what is tradition in this young branch?) stakeholders and feature requests are related in a matrix. But tables are not very intuitive. It will have benefits if we can model the relations visually.
The simplest representation of a link between stakeholder and feature request or stakeholder request is a line. Like the Use Case Model, a Stakeholder Request Model could consist of persons (stakeholders) linked to ovals (feature requests) by lines.
As the lines should depict support of a stakeholder for a request, lines should be uni-directional and thus have an arrow.
The power of stakeholders is often described as an important feature, and something we could visually depict by the size of the person representing a stakeholder. To keep things manageble, 3 levels (powerful, normal, weak) should suffice.
The support of a stakeholder for a request can be depicted by the widt of a line, the thicker the line, the stronger the support. Again, 3 levels should be sufficient: Must, Should, Could, they correspond with the first three levels of MosCow:
In a good project, the Wonts wont be present.
Let me conclude this with a simple example of what i have in mind:
This example shows part of an online registration system for courses / lectures. Professors may register a lecture they intend to give, students may sign up for them. The manager provides the funds for the system, holds the most power (hence drawn larger) and has the largest influence.
The analyst, knowing this, might do well to have a 5 minute chat with the manager before starting the work on a use case to ask him what the priorities of the manager are, before going into the details with the student or the professor. If the managers respons is: "the students will have to use the system anyway, so dont spend to much money on their facilities", he has another frame of mind than if the manager would reply: "At present, too many students find it hard to sign up in time for the start of courses and that holds the results of our university back".
Sources:
Personally I find this a shortcoming, and I have been thinking about ways to model stakeholders, their types, their relations and their interests in stakeholders requests.
Stakeholder analysis is a rapidly growing area wth its main applications in politics and management. For RUP purposes, we usually don't need to model all properties and relations between stakeholders. Moreover, as circulstances, and thus stakeholders, can change frequently, it is often not very wise too spend too much time and effort on stakeholder analysis, as many projects should and will be short.
But for Requirements Management it is wise to link Use Cases to stakeholder requests, and Stakeholder requests to Stakeholders. By linking Use Cases to Stakeholder Requests, we can check that no Use Cases creep in that are not supported by Stakeholder requests. By linking Stakeholder requests to Stakeholders, we can make sure that these Use cases are requested by at least one Stakeholder.
"Traditionally" (for what is tradition in this young branch?) stakeholders and feature requests are related in a matrix. But tables are not very intuitive. It will have benefits if we can model the relations visually.
The simplest representation of a link between stakeholder and feature request or stakeholder request is a line. Like the Use Case Model, a Stakeholder Request Model could consist of persons (stakeholders) linked to ovals (feature requests) by lines.
As the lines should depict support of a stakeholder for a request, lines should be uni-directional and thus have an arrow.
The power of stakeholders is often described as an important feature, and something we could visually depict by the size of the person representing a stakeholder. To keep things manageble, 3 levels (powerful, normal, weak) should suffice.
The support of a stakeholder for a request can be depicted by the widt of a line, the thicker the line, the stronger the support. Again, 3 levels should be sufficient: Must, Should, Could, they correspond with the first three levels of MosCow:
- M - MUST have this.
- S - SHOULD have this if at all possible.
- C - COULD have this if it does not affect anything else.
- W - WON'T have this time but WOULD like in the future.
In a good project, the Wonts wont be present.
Let me conclude this with a simple example of what i have in mind:
This example shows part of an online registration system for courses / lectures. Professors may register a lecture they intend to give, students may sign up for them. The manager provides the funds for the system, holds the most power (hence drawn larger) and has the largest influence.
The analyst, knowing this, might do well to have a 5 minute chat with the manager before starting the work on a use case to ask him what the priorities of the manager are, before going into the details with the student or the professor. If the managers respons is: "the students will have to use the system anyway, so dont spend to much money on their facilities", he has another frame of mind than if the manager would reply: "At present, too many students find it hard to sign up in time for the start of courses and that holds the results of our university back".
Sources:
- Stakeholder analysis: a review, 2000, Oxford University press, Ruairí Brugha1 and Zsuzsa Varvasovszky2
- Cultivating Peace: Conflict and Collaboration in Natural Resource, 1999, World
Bank Institute,Ricardo Ramirez - http://en.wikipedia.org/wiki/MoSCoW_Method
Stakeholders - who are my stakeholders?
One of the Rational Unified Process (RUP) concepts is that of a stakeholder.
At Agilemodelling Scott W. Ambler describes stakeholders as:
My definition of a project stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.
The author explicitly does not include the developers working on the project. In my humble opinion, a right decision.
My problem with this definition is that it is not a definition, it is a list. My definition would be:
Someone is a stakeholder if that person has an interest in the result of the project.
Note that this definition does not say that the stakeholder has an interest in the project. That would make everyone involved in the project a stakeholder. But that would make the project an aim in itself.
This definition also transcends the terms of software development. It can be applied to any project in any branch.
Stakeholders are important during the project process, because they:
* In the conception phase, define the scope of the project (they define the requested features list)
* During the elaboration phase, stakeholders have to agree that the current vision can be achieved if the current plan is executed
* During both elaboration phase and during the construction phase, the stakeholders need to guard the agreed balance of features
* At the end of the construction phase, the stakeholders have to say if they are ready to move to the transition phase.
* In all phases, stakeholders are essential for analists as a source of information.
Stakeholders typically will have to guard their own interest. Depending in the project management organization choosen, a project board may be
formed where they meet and discuss the priorities of the project.
Examples of stakeholders are:
* The funder of the project. Often there is one manager paying for the project. Sometimes there is more than one organization or department that funds a project. Conflicts between these parties should not drip down into the project. The project board should balance te interests by having the stakeholders agree on the scope through the adoption of a Requested Features List.
* Users. But be aware: "The user" does not exist. More than one department will be involved. More than one type of user will be involved. If there are large differences, they will be more than one stakeholder.
* IT staff who will have to work with the software after delivery. Examples are maintenance personel, helpdesk, dba-ers
Stakeholders will often be represented by people. The funder of the project will often send someone else to represent his interests, for example his sale manager or his CFO.
The users may be represented by several people, depending on the size of the users group and the diversity of their roles.
The Getronics Delivery Process, a company based implementation, says "Assign one or more staff members to perform this role only" before proceeding to combine this role with several others. The decision to assign staff members instead of line personel is a doubtful one.
There are several types of Stakeholders, and several roles. Ons distiguishment which is important to make is that some Stakeholders are Actors, while others are not. For example, a student who will use the Course Registration System to sign up for a course is both a Stakeholder and an Actor. The university director who finances the realization of a Course Registration System will be a Stakeholder, but probably not an Actor, unless he also lectures.
At Changing minds.org the authors view a short list of roles:
The first group they distiguish, the Sponsors, is a very important one.
In the past 2 decades there have been several research projects into stakeholder analysis. Important work has been done by:
Stakeholders can be classified in several ways. According to wikipedia, some of the commonly used 'dimensions' include:
At Agilemodelling Scott W. Ambler describes stakeholders as:
My definition of a project stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.
The author explicitly does not include the developers working on the project. In my humble opinion, a right decision.
My problem with this definition is that it is not a definition, it is a list. My definition would be:
Someone is a stakeholder if that person has an interest in the result of the project.
Note that this definition does not say that the stakeholder has an interest in the project. That would make everyone involved in the project a stakeholder. But that would make the project an aim in itself.
This definition also transcends the terms of software development. It can be applied to any project in any branch.
Stakeholders are important during the project process, because they:
* In the conception phase, define the scope of the project (they define the requested features list)
* During the elaboration phase, stakeholders have to agree that the current vision can be achieved if the current plan is executed
* During both elaboration phase and during the construction phase, the stakeholders need to guard the agreed balance of features
* At the end of the construction phase, the stakeholders have to say if they are ready to move to the transition phase.
* In all phases, stakeholders are essential for analists as a source of information.
Stakeholders typically will have to guard their own interest. Depending in the project management organization choosen, a project board may be
formed where they meet and discuss the priorities of the project.
Examples of stakeholders are:
* The funder of the project. Often there is one manager paying for the project. Sometimes there is more than one organization or department that funds a project. Conflicts between these parties should not drip down into the project. The project board should balance te interests by having the stakeholders agree on the scope through the adoption of a Requested Features List.
* Users. But be aware: "The user" does not exist. More than one department will be involved. More than one type of user will be involved. If there are large differences, they will be more than one stakeholder.
* IT staff who will have to work with the software after delivery. Examples are maintenance personel, helpdesk, dba-ers
Stakeholders will often be represented by people. The funder of the project will often send someone else to represent his interests, for example his sale manager or his CFO.
The users may be represented by several people, depending on the size of the users group and the diversity of their roles.
The Getronics Delivery Process, a company based implementation, says "Assign one or more staff members to perform this role only" before proceeding to combine this role with several others. The decision to assign staff members instead of line personel is a doubtful one.
There are several types of Stakeholders, and several roles. Ons distiguishment which is important to make is that some Stakeholders are Actors, while others are not. For example, a student who will use the Course Registration System to sign up for a course is both a Stakeholder and an Actor. The university director who finances the realization of a Course Registration System will be a Stakeholder, but probably not an Actor, unless he also lectures.
At Changing minds.org the authors view a short list of roles:
- Sponsors
- Targets
- Others affected
- Partners
The first group they distiguish, the Sponsors, is a very important one.
In the past 2 decades there have been several research projects into stakeholder analysis. Important work has been done by:
- Mitchell, Agle et al. 1997. They identify Stakeholders based on 3 properties: power, legitimacy and urgency.
- Fletcher, Guthrie et al. 2003
- Turner, Kristoffer and Thurloway, 2002
- Ronald K. Mitchell, Bradley R. Agle and Donna J. Wood, 2002
Stakeholders can be classified in several ways. According to wikipedia, some of the commonly used 'dimensions' include:
- Power (high, medium, low)
- Support (positive, neutral, negative)
- Influence (high or low)
- Interest (high or low)
- Attitude (supportive or obstructive)
Tuesday, April 08, 2008
Open office
An email announcing the availability of Open Office 2.4 had arrived while for a day i didnt check my gmail.
Allthough i rarely browse through the new features list, this time and did. And one thing caught my eye: Open office seems to be moving towards google. Google has always had a penchant for open source. They always rated wikipedia quit high in their results lists, though i dont know if this is a by-product of their existing algorithm or something that they awarded extra weight on purpose.
Some examples of their movement towards google:
* OpenOffice.org2GoogleDocs - the name suggests it becomes easy to transfer open office documents in google docs. Google docs already could import open office documents, this will make 2 way traffic easier.
* The writers tools have several extras. One is an integration with Google Translate
* Another writers tools feature is an integration with google maps
One wonders if this is a signal of closer cooperation between google and sun corporations.
Allthough i rarely browse through the new features list, this time and did. And one thing caught my eye: Open office seems to be moving towards google. Google has always had a penchant for open source. They always rated wikipedia quit high in their results lists, though i dont know if this is a by-product of their existing algorithm or something that they awarded extra weight on purpose.
Some examples of their movement towards google:
* OpenOffice.org2GoogleDocs - the name suggests it becomes easy to transfer open office documents in google docs. Google docs already could import open office documents, this will make 2 way traffic easier.
* The writers tools have several extras. One is an integration with Google Translate
* Another writers tools feature is an integration with google maps
One wonders if this is a signal of closer cooperation between google and sun corporations.
Thursday, February 14, 2008
HTML and browsers
Occasionally i have to design webpages. Well, no doubt there are people around here who do this a whole lot better than i do. After all, I am a generalist, not a specialist. I design a webpage once a year, or once a month, not twenty a day.
For this reason I like to keep things simple. Of course that is 100% in line with the KISS=Keep It Stupidly Simple principle. But it is also highly practical. After all, every application grows until its complexity has made it unattainable. The longer you keep things simple, the longer the application can be kept running.
Keeping html pages simple to me is a matter of several aspects. One aspect is that pure html is easier to maintain than lengthy pages with hundreds of lines of javascript. Not only are long javascript codes more likely to contains bugs, they also tend to differ between various browsers and they als take longer to load.
I also tend to use FireFox as my primary browser. The web developer plugin detects a large number of errors before i spot them myselves. The debugging facilities of this plugin are fantastic, much better than anything I have seen for IE. The drawback is that some pages at the end do not work in IE as expected, so occasinally i have to break down my pagge and see where things go wrong.
Because I design webpages so rarely, I have to look up exact statements very often. I love w3schools.com as a reference. Easy to understand, well designed, and their examples actually work.
For this reason I like to keep things simple. Of course that is 100% in line with the KISS=Keep It Stupidly Simple principle. But it is also highly practical. After all, every application grows until its complexity has made it unattainable. The longer you keep things simple, the longer the application can be kept running.
Keeping html pages simple to me is a matter of several aspects. One aspect is that pure html is easier to maintain than lengthy pages with hundreds of lines of javascript. Not only are long javascript codes more likely to contains bugs, they also tend to differ between various browsers and they als take longer to load.
I also tend to use FireFox as my primary browser. The web developer plugin detects a large number of errors before i spot them myselves. The debugging facilities of this plugin are fantastic, much better than anything I have seen for IE. The drawback is that some pages at the end do not work in IE as expected, so occasinally i have to break down my pagge and see where things go wrong.
Because I design webpages so rarely, I have to look up exact statements very often. I love w3schools.com as a reference. Easy to understand, well designed, and their examples actually work.
Tuesday, May 08, 2007
Don't tell your left hand what your right hand is doing
This old advice is given in the bible, by a man called Jesus. You can look it up in a book called Matthew, chapter 5. The moral was: if you do something good, don't let everybody know it. If you tell everybody how good you are, God wont reward you, as you will already have gotton your reward from the people around you.
Sometimes I see the same effct in organizations, but not on purpose, but by accident. Some call it lack of communication, some call it lack of coordination. The bigger the organization, the easier it is to forget to communicate something essential. One department invents something cool, but it remains a secret, known only within the department.
One nice example of lack of communication I discovered today in livemail, see this pic. For those who dont know dutch, the message in the pink background says: This message has been blocked for your safety.
Sometimes I see the same effct in organizations, but not on purpose, but by accident. Some call it lack of communication, some call it lack of coordination. The bigger the organization, the easier it is to forget to communicate something essential. One department invents something cool, but it remains a secret, known only within the department.
One nice example of lack of communication I discovered today in livemail, see this pic. For those who dont know dutch, the message in the pink background says: This message has been blocked for your safety.
Tuesday, February 13, 2007
MS Access and ms word
Consistent use of features and interface has never been a strong point of microsoft products. Some people accuse microsoft of cross selling to create and maintain monopolies, and I understand these accusations.
But I vividly remember that in an old version of ms office, the default directory whem I saved a new word document was the same as with the previous document, while ms excel alsways started in "my documents". As I never use the "my documents" directory for serious documents, but always tend to save important docs in "real" directories, I regretted the excel default. Unfortunately, since then microsoft has tended to standardize on "my documents" even more.
In one of my latest projects, the customer wanted to export reports to ms word. A fellow worker told me this would be no problem. Of course I should have been more careful. I objected and said that I wanted to see a working demo first.
He delivered one in record time.
It turned out he used the code:
It worked beautifully, even with a subreport, and I accepted.
I should have read more closely. The "acFormatRTF" should have warned me. It generates an rtf file, which is saved as a word document. In a way MS Office are wonderful: even when the file extension tells you otherwise, ms word automatically recognize rtf and html.
One problem that arose was the use of page footers. We wanted to have a reportname and pagenumber at the bottom of each page. We added them to the pagefooter of the ms access report. When we exported the report to rtf, it generated plain text on each page. And the page lengths didnt match, so the pagenumber appeared a little bit higher on each page.
We could solve that one by making the pagefooter elements in the report invisible before exporting them. Then we wrote an ms word macro which added page footers.
A second problem was that we had a lot of memo fields and subreports. Both tend to have variable lengths and a nice border around them. When exporting the reports to rtf, ms access forgot the borders.
But as our customer needed the borders to make the document pretty enough to comply with the standards demanded by their customers, we simply had to add these borders. You can sometimes persuade a customer to be satisfied with something less than he hoped for, but a good customer won't accept no for those products he sends directly to his own customer.
This solution was even more complex than the previous one. On the main report, we added 2 tages for each memofield and subreport: a "startsub" and "endsub", placed before and after each memofield and subreport. These were made invisible before showing in ms access, and made visible before exporting to rtf.
Again an ms word macro had to be written. This one selected all text between and including the two tags, and moved it into a newly inserted 1 cell table. Then the two tages were removed.
This worked fine in ms word 2002 and ms word 2003. Of course there was a minor hickup, as you can't expect ms word macro's to be backward compatible to ms word 2000 when it comes to basic operations like find and cut.
The final problem arose from the variable length memo fields and sub reports. We had carefully put the autochange size (or whatever the correct name in english may be, we used the dutch version) property at Yes/True. That worked very well while viewing the reports in ms access. It created chaos when exporting the reports to ms access. Some of them expanded, some of them didnt. After a few days we arrived at a solution: all the memo fields went into subreports, even when there was no reason for them, and nothing was left in the details section of the main report. This finally solved the problem, though a little teaser remained: the tags introduced in the previous paragraph.
It turned out that the tags, when on the main form, did move down as required with the subreprots in some versions of ms office, but not in others. I couldnt reference the tags from vb-script when they were in the subreport. I still havent solved this problem, though my fellow worker probably did this in the past weeks.
But I vividly remember that in an old version of ms office, the default directory whem I saved a new word document was the same as with the previous document, while ms excel alsways started in "my documents". As I never use the "my documents" directory for serious documents, but always tend to save important docs in "real" directories, I regretted the excel default. Unfortunately, since then microsoft has tended to standardize on "my documents" even more.
In one of my latest projects, the customer wanted to export reports to ms word. A fellow worker told me this would be no problem. Of course I should have been more careful. I objected and said that I wanted to see a working demo first.
He delivered one in record time.
It turned out he used the code:
DoCmd.OutputTo acOutputReport, "ReportName", acFormatRTF, "report.doc"
It worked beautifully, even with a subreport, and I accepted.
I should have read more closely. The "acFormatRTF" should have warned me. It generates an rtf file, which is saved as a word document. In a way MS Office are wonderful: even when the file extension tells you otherwise, ms word automatically recognize rtf and html.
One problem that arose was the use of page footers. We wanted to have a reportname and pagenumber at the bottom of each page. We added them to the pagefooter of the ms access report. When we exported the report to rtf, it generated plain text on each page. And the page lengths didnt match, so the pagenumber appeared a little bit higher on each page.
We could solve that one by making the pagefooter elements in the report invisible before exporting them. Then we wrote an ms word macro which added page footers.
In ms access:
Reports!Reportname.MyPageFooter.visible = false
DoCmd.OutputTo acOutputReport, "ReportName", acFormatRTF, "report.doc"
A second problem was that we had a lot of memo fields and subreports. Both tend to have variable lengths and a nice border around them. When exporting the reports to rtf, ms access forgot the borders.
But as our customer needed the borders to make the document pretty enough to comply with the standards demanded by their customers, we simply had to add these borders. You can sometimes persuade a customer to be satisfied with something less than he hoped for, but a good customer won't accept no for those products he sends directly to his own customer.
This solution was even more complex than the previous one. On the main report, we added 2 tages for each memofield and subreport: a "startsub" and "endsub", placed before and after each memofield and subreport. These were made invisible before showing in ms access, and made visible before exporting to rtf.
Again an ms word macro had to be written. This one selected all text between and including the two tags, and moved it into a newly inserted 1 cell table. Then the two tages were removed.
This worked fine in ms word 2002 and ms word 2003. Of course there was a minor hickup, as you can't expect ms word macro's to be backward compatible to ms word 2000 when it comes to basic operations like find and cut.
The final problem arose from the variable length memo fields and sub reports. We had carefully put the autochange size (or whatever the correct name in english may be, we used the dutch version) property at Yes/True. That worked very well while viewing the reports in ms access. It created chaos when exporting the reports to ms access. Some of them expanded, some of them didnt. After a few days we arrived at a solution: all the memo fields went into subreports, even when there was no reason for them, and nothing was left in the details section of the main report. This finally solved the problem, though a little teaser remained: the tags introduced in the previous paragraph.
It turned out that the tags, when on the main form, did move down as required with the subreprots in some versions of ms office, but not in others. I couldnt reference the tags from vb-script when they were in the subreport. I still havent solved this problem, though my fellow worker probably did this in the past weeks.
Friday, November 10, 2006
Performance
Performance is a big issues in ms access.
First, it works with an interpreted language, vb. Interpreted languages are always slower than compiled languages, as interpreters generally translate each line of code as they encounter it.
Second, MS access generates a lot of network traffic. I don't know why, but it does.
Microsoft publishes a nice page with performance tips. Some interesting knowledge base articles:
The latter is particularly interesting, it contains several tips (or tricks, depending on ones point of view)
Someone asked me to have a look at an application a fellow worker had developed and which didnt perform on the network of our customer.
A first analysis learnt that the data involved was not much: most tables had very little rows, 10-50 rows, while a few had about 400 rows and one had 700 rows. The whole ms access data file was less than 4 Mb.
Yes, the database had been split in a program mde and a database file. Good practice in many environments, as it allows developers to work on the programs while the users can continue working with it.
The application works in a network environment, where the customers are in The Hague while the servers are in Amsterdam. The customers worked within a powerfuse and citrix network environment.
The performance problem appeared throughout the application, but was most noticeble in the opening of two forms. One took 30 seconds to open, the other 60. In stand alone mode, the forms openend within a second.
The network posed no problem, a database operator openened the forms on the server while located in Amsetrdam and found the same results.
Using this kb article, I asked him to rename both the database .mdb file and the program .mde file to a 8.3 format name. The result was astonishing: times went down from 30 and 60 to 10 and 20 seconds respectively. Astonishing. I had hoped them to half, a factor of 3 was above my expectations.
In a test environment, the option "Turn off the sharing violation notification delay" yielded no benifit. The same results appeared when I tested "Disable automatic short file name generation".
What did result in a substantial improved perfoamnce was the option to turn of local settings fo windows. This halved the time required for opening one of the windows, but did nothing for the other window.
Another thing was the option
First, it works with an interpreted language, vb. Interpreted languages are always slower than compiled languages, as interpreters generally translate each line of code as they encounter it.
Second, MS access generates a lot of network traffic. I don't know why, but it does.
Microsoft publishes a nice page with performance tips. Some interesting knowledge base articles:
- http://support.microsoft.com/kb/209126
- http://support.microsoft.com/kb/128808
- http://www.microsoft.com/technet/archive/office/office97/maintain/off411ef.mspx?mfr=true
- http://support.microsoft.com/kb/889588
The latter is particularly interesting, it contains several tips (or tricks, depending on ones point of view)
Someone asked me to have a look at an application a fellow worker had developed and which didnt perform on the network of our customer.
A first analysis learnt that the data involved was not much: most tables had very little rows, 10-50 rows, while a few had about 400 rows and one had 700 rows. The whole ms access data file was less than 4 Mb.
Yes, the database had been split in a program mde and a database file. Good practice in many environments, as it allows developers to work on the programs while the users can continue working with it.
The application works in a network environment, where the customers are in The Hague while the servers are in Amsterdam. The customers worked within a powerfuse and citrix network environment.
The performance problem appeared throughout the application, but was most noticeble in the opening of two forms. One took 30 seconds to open, the other 60. In stand alone mode, the forms openend within a second.
The network posed no problem, a database operator openened the forms on the server while located in Amsetrdam and found the same results.
Using this kb article, I asked him to rename both the database .mdb file and the program .mde file to a 8.3 format name. The result was astonishing: times went down from 30 and 60 to 10 and 20 seconds respectively. Astonishing. I had hoped them to half, a factor of 3 was above my expectations.
In a test environment, the option "Turn off the sharing violation notification delay" yielded no benifit. The same results appeared when I tested "Disable automatic short file name generation".
What did result in a substantial improved perfoamnce was the option to turn of local settings fo windows. This halved the time required for opening one of the windows, but did nothing for the other window.
Another thing was the option
Subscribe to:
Posts (Atom)