off the shelf software and FPA

The Dutch Nesma counting guidelines 2.2 have an interesting section on off-the-shelf applications.
They identify three areas of functionality:
A - functionality wished for by the customer, but not offered by the application
B - Functionality wished for by the customer, and offered by the application
C - Functionality not wished for by the customer, and offered by the application
Visually:

A is functionality that the customer wants, but does not get. This means additional costs. C represents functionality the customer pays for, but does not need. B is the area for which the customer can make a price comparison.

This model, like all models is i.m.h.o. a simplification. Using MoSCoW prioritization, one might group all "Must" and "Should" into the area "wished for", but one might also decide to add the "Could" or even "Would" groups to it. This might give considerable differences. For example, functionality not listed as required by the customer, might turn out to be a secondary wish not listed. Indeed, an inspection of the functionality of some off-the-shelf applications might yield considerable new insights. The nesma counting guidelines correctly mention the problem of counting the information model when counting off-the-shelf applications. One aspect they do not mention is the current trend of feature lists. Feature lists, for those not yet acquainted with them, are lists with short summaries of functionality. They may be formulated as the features found on the box of the product. For example, a word processor feature list might be: * the user can easily enter and correct text * the user can do elementary formatting such as bold, italics and underlined. * the user can use several fonts and character sizes * the user can print the text * the editing is wysiwyg * the user can create mailings by creating a document and connecting it to a variety of sources and so on. Feature descriptions sometimes are too short to make an FPA count. The person performing the FPA count will have to do some inquiries about the nature of the features.

Passwords - some practical remarks

There is a well known problem with passwords: they should be easy to remember, yet be long and complicated enough not to be detected by automatic password crackers.

The story is in the news today again for the umptieth time, with mashable reporting a list of the 25 most common passwords

Here are some of them:
password
123456
12345678
qwerty
abc123
monkey
1234567
trustno1
baseball
111111
iloveyou
Of course the guidelines for good passwords are well known:

1. Use a combination of upper and lowercase, digits and other signs such as "_", !, & and so on.
2. Don't use your name, names of relatives, or hobbies, birth date, and so on. Instead, do use combinations of words.
3. Let your password have a sufficient length. Experts differ in opinion, and applications differ in possibilities. For instance, on windows 7 administrators can set the minimum password length anywhere from 1 - 14. Google apps recently increased the minimum length from 6 to 8.
4. Use different passwords on different sites.
5. Change your passwords frequently.
6. Don't write your passwords down.

How, with these guidelines in mind, how can you choose passwords which on one side comply with these rules and on the other hand, are still useable in real life?

Here are some suggestions:

1. Use something from your most recent holiday: hotel, restaurant, camping, guide, recipe, and so on, and mix this with numbers and other characters. For example, if "haggish" was a recipe you liked when on holiday in Scotland, you might choose "Scotland-Hag*2011*gish" as a password. This will encourage you to change password your password again after a next holiday. Not frequent enough, but it is a step.
   A friend of mine went to Argentina, and used the names of all the small villages there as the base for his passwords.
2. Do you have a favorite song, poem or book? Use a combination of words, intermingled with numbers and other characters. For example, if you love the Rolling Stones, you might pick one of their songs: "You can't always get what you want", and choose a line, such as: I saw her today at a reception, and intermingle it with digits and other characters:
   "I08saw*her_today at a reception".
   If you change your password, don't just change the number, also periodically change to the next line of the song.
3. Including year and month in your password has advantages and disadvantages. One advantages is that it is easy to remember, and another that it reminds you to change your password again. An obvious disadvantage is that these parts are easy to guess, and certainly this should not be the only change in a password.

Now there is something to say about the rule: Don't write your passwords down.. First, to have a different password for every site, virtually forces one to write your password down, or frequently to ask the site to reset your password.
Personally, I don't think the rule can be taken as an absolute. Certainly it is not good if an office employee has a yellow note at the screen with his or her password. A better wording would imho be: write your password down at a secure spot.
If you are at home, store your passwords of internet sites on pencil and paper in a secure spot - where it can be found easily, but not at first sight.
As for the office, unfortunately there are still many employers who don't have single login enabled for there applications. Ask your employer for it - the problem belongs to your employer. Meanwhile, you probably have one main account. You will have to memorize the password for that account, and maybe you have a private area where you can write note your other passwords securely in that spot. Or maybe you can synchronize your passwords, changing them all at the same time?
One secure spot to write your passwords down is a password store. They allow you to write down your passwords for numerous internet sites and applications, together with the name of the site or the application. They need a password to open, so that is the only password you need to remember. And oh, you will want to backup this utility frequently. One which is free and open source is Keepass.

FPA - Some changes are no changes

Or in other words: Some changes are free

The definition of a maintenance project according to NESMA is: A project in which functional changes with regard to an existing information system are realized. In the information system functions can be added, changed or removed.
The first conclusion is that technical changes can not be counted with this guideline. Organizations which offer maintenance based on fixed price/function points may have a problem here, unless they make additional agreements with their customer, which is done often. A good question is if bugfixing counts as a change. My opinion tends to be: This depends. If the bug is of a technical nature, the functionality is not changed. An example might be a programming error where the system occasionally crashes. If however, the system requires that data element z should be equal to a + b, and the bug is that z = a + b + c + d, then the functionality changes, and this should be counted as a functional change.

It is important here to distinguish between the question: ‘Should we count this?’ and the question: ‘Should we charge this to the customer?’. The first question can be answered from the counting guidelines, the second by the contract. It may well be that the change may be counted, but not billed. The reverse situation, that the item may be billed but not counted, is something I see less often.

A second conclusion is that we must differentiate between the documentation of specification of the information system and the information system itself. The specifications and the information system will generally not correspond 100%. What concerns us here is that we count functional changes to the information system, regardless of the documentation. This is why some bugs, if they are functional in nature, may and should be counted even if the documentation does not change.

FPA had several formulas for maintenance projects, that is, for changes to existing systems. One formula is for the size of the system:

PROD_New= PROD_Old + FUN_Added – FUN_Removed + (CHANGED_New - CHANGED_Old)

This formula is given on page 15 of the NESMA counting guidelines reference manual.

The other formula, which is given on page 18 of the NESMA counting guidelines, is the size of the project.
This formula is:

PROJECT = FUN_Added + FUN_Removed + CHANGED_New

An example of both is given in between these two formulas, which is strange, as it introduces the project formula in an informal form before it is explicitly defined. Several conclusions can be drawn from this last formula. The first one is:

1. 1) Any functional change to a function should be counted as if the function has to be build anew.
This is of course not very accurate. There generally is not very much discussion about = FUN_added + FUN_removed. But CHANGED_New is another matter. Changes may be big or small, and I know of at least one softwarehouse that varies the number of function points depending on the number of data-elements involved in the change. This will generally please the customer: they will pay less than in the case of a full count as prescribed by the NESMA guidelines. There is a considerable drawback imho: Counting a reduced number of function points for some small changes makes it doubtful if they can still be considered function points.

It is understandable that some customers get upset if a customer has to pay for say a nearly identical extra data element to be added to 100 screens as if these screens should all be build from scratch.

A second conclusion is:

1. 2) Non functional changes should not be counted.
Cosmetic changes may be chosen as an example. A complete whole-over of the layout of a website might well result in 0 function points, while it requires a considerable effort to realize. Again: if these changes can be billed also depend on the contract. Contract definitions are very important in this respect. If the contract specifies that all functional change requests will be billed a E xx per function point, cosmetic changes might still be charged as they are not covered by the contract. If the contract stipulates that all changes will be charged at xx per function point, the supplier might have a problem.

In the long term, the effect of 1) and of 2) might cancel out each other, but short term fluctuations might be large. One way to solve this dilemma would be to agree that exceptional circumstances might be offered on a non FPA based estimate, but that is an option that would not please most FPA afficionados. Neither would it please the lawyers and management negatiotors, as it would be hard to define what is exceptional.

FPA updates

Some quick FPA Updates:

1. In the Netherlands, FPA certification has been transferred from Exin to Cito. A quick look showed that the sample examination is still the same, with just a name change.
2. There is an interesting discussion on linkedin about the pros and cons of Cosmic and FPA.
3. The Nesma newsletter of october 2011 mentions that the yearly fall conference will be on November 11 in Scherpenzeel.
4. At this conference Carolyn Mair, Senior Lecturer in Psychology at the Southampton Solent University (UK), will give a presentation on why experts estimates on the same subject might vary wildly.

Simplified TRIZ

Today I was able to read some chapters from "Simplified TRIZ", by Rantanen, Kalevi, and Ellen Domb. ". St. Lucie Press. © 2002. . (accessed September 9, 2011) . It's only the first two chapters yet, but they did introduce me to some basic concepts:

1. Contradictions. Every problem to be solved is aimed at solving one or more Contradictions. There are Tradeoff Contradictions and Inherent Contradictions. A contradiction often consists of a tool and an object.
2. The Ideality of the system. A measure of how close it is to the perfect system.
3. Unseen idle resources.

Let's try these on an example.
For example, how can we serve customers in a restaurant faster without increasing prices? The tradeoff contradiction is that we can increase the number of waiters, so that more customers can be served at the same time, but that costs money and the restaurant would have to raise prices. So something good (faster service) also means something bad (higher prices).
We could compromise: hire waiters only at peak times, or fire all waiters and hire them back at a more flexible rates and times. But TRIZ does not seek compromises.
In the ideal solutions all customers are served quickly and costs remain the same.
There is an unseen or hidden resource: the customer. If the customer serves as his own waiter, the cost is reduced and the customer can be served much more quickly. Now the concept of a self service restaurant is well known, but it took from 1948 to 1954 to get established.

Definition: A good solution is one that resolves a contradiction.. Another concept is that of Patterns of Evolution. Systems evolve according to certain patterns, and these patterns can be used in many ways to get new ideas and predict the evolution of the system. Finally, there are 40 innovative principles that give concrete clues for solutions. Let's have them in a diagram:

Figure 1.

Innovation

TRIZ, theory of Inventive Problem Solving, based on the work of the russian inventor and researcher Genrich Altshuller, is slowly gaining the popularity it deserves.

I discovered a nice series of you tube movies, see http://www.youtube.com/watch?v=zcKy0psDlf4.

In addition my own employer Capgemini will be using the principles and has appointed qa special innovation officer.

XBRL (2)

Today offered a new opportunity to dive into XBRL. This time I concentrated on Taxonomies. What are taxonomies?

1. What is a taxonomy?
Basically, a taxonomy defines [u]what[/u/ should be in a report. The taxonomy is not the report itself, and it does not define the layout. It does define the elements that should be reported.

2. What about the layout of a report?
For the layout you can define a stylesheet.

3. What are the properties of elements in a taxonomy?
- data type:
- period
- balance
- nillable
That does not include any relations between elements, for that we have links.

4. What are the properties of links?
- references
- labels
- presentation
- versioning
- definition
The term presentation is slightly misleading, as it suggests it defines the way an element is shown. Actually it defines the place and sequence in which elements should be shown.

4. What is a linkbase?
A linkbase is simply a collection of links.

An element without links is called an unbound element.

Short descriptions:

• A reference link describes the relation between an element and the reporting standard such as IFRS
  
• A label link describes a link to a humanly readable description. For example, machines may not have trouble in using ifrs-ci_CashCashEquivalents, humans usually prefer something like Current Assets Label links may depend on the role of a link. One of the usages of role is to provide description in different languages. Another is to make a difference in description depending on value, for example loss for negative values and profit for positive values.
  
• A presentation link can not be used for layout, but can be used for defining relations between elements. Examples are Parent-child, or Order-Orderline. Another usage is to define the requirements that the presence of element A requires the presence of element B.
  
• The versioning link is used to define the changes in a taxonomy over time.
  
• The Calculation link describe show values of elements should be added or subtracted. It creates a relation between a summation element and a contributing element. It can be used as the base for the Formula linkbase.
  An example of a calculation link:
  <link:calculationLink xlink:type="simple" xlink:role="http://www.example.com/">
  <link:documentation>string
  </link:calculationLink>
  

5. What is a dimensional taxonomy?
A dimensional taxonomy allows the user to group data according to different dimensions. Examples are reporting by product (group), by geographic region, and by period.
Defining such taxonomies is not easy and may lead to high implementation costs.