This blog started out with some ms access tricks and tips. As I have not worked with ms access for some time, the attention of this blog has shifted to other topics. That left me a choice between renaming this blog, or starting a new one. Renaming it would have missed some old links in email to this blog, so I discontinue this blog and continue at a new url:
new name and new address.
Friday, October 30, 2009
Wednesday, September 30, 2009
Outlook in office2010
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.
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.
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
Subscribe to:
Posts (Atom)