FPA certificering - oefenvragen (2)

Like last time, an apology to the english language visitors of this blog. In this post you find part 2 of a series of certification questions for the nesma 2.2 examination.

11. Niveau's van complexiteit
Welke drie niveaus van complexiteit worden onderscheiden? Kruis er drie aan:
a. Eenvoudig
b. Complex
c. Moeilijk
d. Simpel
e. Gemiddeld

12. Functiepunten per complexiteit
Vul het aantal functiepunten per complexiteit in:

	E	G	M
Interne logische gegeve. Verz
Koppelingsgegevensverzameling
Invoerfunctie
Opvraagfunctie
Uitvoerfunctie

13. Functionele omvang
Wat is de Functionele omvang van een informatieverwerkend systeem?
a. De verzameling gebruikersfuncties;
b. De som van het aantal functiepunten van de gebruikersfuncties;
c. De verzameling gegevensverzamelingen en de verzamelde gebruikerstransacties;

Hoofdstuk 3
14. Stappen
Welke stappen worden uitgevoerd bij het maken van een functiepunten telling? (meerdere antwoorden!)
a. Vaststellen aard van de telling;
b. Verzamelen beschikbare documentatie;
c. Stel de systeemgrens vast;
d. Identificeer de gebruikersfuncties en stel de complexiteit hiervan vast;
e. Controleer het resultaat bij de gebruikers;
f. Stem het resultaat af met andere FPA experts indien er interpretatiepunten zijn geweest;
g. Stel vast wie de gebruikers zijn;
h. Stel vast wie de doelgroep is;
i. Stel vast wie de opdrachtgever is;
j.Stel de informatie uitwisseling met andere informatiesystemen vast;

15. indicatieve functiepunten telling
Wat is nodig voor een indicatieve functiepunten telling?
a. Een objectmodel met de volledige levenscyclus van elke klasse;
b. Het logisch gegevensmodel in 5e normaalvorm;
c. Een conceptueel gegevensmodel;

16. De formule voor een indicatieve telling
De formule voor een indicatieve telling op basis van een conceptueel gegevensmodel is:
35 x #ILGV's + 15 * #KGV.
Motiveer de formule;

17. De formule voor een indicatieve telling
Wat is de formule voor een indicatieve telling op basis van een genormaliseerd gegevensmodel?

18. Bronmateriaal
Geef aan welk bronmateriaal noodzakelijk is voor een indicatieve (I), globale (G) of gedetailleerde (D) telling noodzakelijk is:
a. Een conceptueel of genormaliseerd gegevensmodel;
b. Een model dat de gegevensverzamelingen en hun onderlinge relaties toont;
c. Een model dat alle logische gegevensverzamelingen toont met hun onderlinge relaties, en de samenstelling van de logische gegevensverzamelingen;
d. Een model dat de systeemfuncties en hun detaillering tot op data element niveau laat zien met hun ingaande- en uitgaande informatiestromen;
e. Een indicatie waar de logische gegevensverzamelingen worden onderhouden;
f. Een model dat de systeemfuncties laat zien met hun ingaande- en uitgaande informatiestromen;
g. De informatiestromen die lopen tussen het te tellen informatiesysteem en zijn omgeving;
h. Een detaillering van de ingaande en uitgaande informatiestromen en hun detaillering op data element type niveau;

19. Kenmerken
Welke kenmerken dient een informatiesysteem te bezitten?
a. Verzamelen van informatie;
b. Bewaren van informatie;
c. Verplaatsen van informatie;
d. Bewerken van informatie;
e. Veranderen van informatie;
f. Combineren van informatie;
g. Presenteren van informatie;

20. Productomvang
Wat is de formule voor de productomvang van een gewijzigd informatiesysteem?
a. NieuweOmvang = OudeOmvang+NieuweFuncties-VerwijderdeFuncties+GewijzigdeFuncties
b. NieuweOmvang=OudeOmvang+NieuweFuncties-VerwijderdeFuncties+(GewijzigdeFunctiesNieuw-GewijzigdeFunctiesOud);
c. NieuweOmvang=NieuweFuncties+GewijzigdeFuncties+VerwijderdeFuncties

FPA certificering - oefenvragen (1)

My apologies for the english visitors, this post as well as the next few, will be in Dutch.

Deze post bevat, samen met de volgende posts, een alternatief FPA oefenexamen. Deze vragen heb ik opgesteld om "mijzelf te overhoren". Iedereen mag ze voor zijn/haar eigen oefeningen gebruiken. Gebruik door commerciële partijen alleen na toestemming.

Uit bovenstaande mag duidelijk zijn dat deze vragen geen officiële status hebben. Er is dus geen garantie dat wie deze test goed maakt, ook het certificeringsexamen haalt.

De antwoorden worden in een aparte blog post gegeven.

1. ISO richtlijn
Als welke ISO richtlijn staan de telrichtlijnen bekend?
a. ISO/IEC 24000
b. ISO/IEC 24500
c. ISO/IEC 24570
d. ISO/IEC 24575

2. versie FPA telrichtlijnen?
Wat is de huidige versie van de FPA telrichtlijnen?
a. 2.0
b. 2.01
c. 2.2
d. 3.0

3. Toepassingsmogelijkheden
FunctiePuntAnalyse (FPA) is een methode waarmee (meerdere antwoorden mogelijk):
a. men een technologie onafhankelijke meting te doen van de door een geautomatiseerd informatiesysteem geboden functionaliteit;
b.  men deze meting kan gebruiken als basis voor het bepalen van de projectomvang bij de  realisatie;
c. men deze meting kan gebruiken als basis van de onderhoudsinspanning;
d. men projectleiders kan beoordelen op hun prestaties;
e. men een aantal factoren kan analyseren die de productiviteit beïnvloeden;
f. men de omvang van een informatiesysteem tijdens de ontwikkeling kan beheersen;
g. men de kwaliteit van de specificaties van een informatiesysteem kan toetsen;
h. Een methode voor het meten van de kwaliteit van een informatiesysteem;

4. Verantwoordelijke organisatie
De Nederlands FPA telrichtlijnen vallen onder de :
a. IFPUG
b. NEFPUG
c. NESMA

5. Onderwerpen:
Wat behandelen de telrichtlijnen van de Nesma standaard: (meerdere antwoorden mogelijk)
a. Hoe een informatiesysteem geteld dient te worden;
b. Hoe men de telrichtlijnen dient te gebruiken als basis voor een projectbegroting;
c. Wat de productiviteitsnormen voor verschillende omgevingen zijn;
d. Bepalen van de technische omvang van een informatiesysteem;
e. Productiviteitsattributen;
f. Stappenplan voor tellen;

6. Relatie met scrum
Welke soorten tellingen behoren bij welke scrum hoofdfasen:
a. Indicatieve functiepuntentelling;
b. Globale functiepuntentelling;
c. Gedetailleerde functiepuntentelling;
1. main game
2. pre game
3. post game

7. Plaats in project fasering
Ten aanzien van de volgende soorten tellingen:
a. Initiële functiepuntentelling;
b. Tussentijdse functiepuntentelling;
c. Definitieve functiepuntentelling;
d. Finale functiepuntentelling;
Geef ze een plaats tijdens een project:
1. Aan het slot van een project;
2. Tijdens een project;
3. Voor de aanvang van een project;

8. Base Functional Components
In welke twee groepen worden de vijf gebruikersfuncties (base functional components) waaruit een fpa bestaat gegroepeerd?

...
...

9. Systeemgrens
Waarvoor is het bepalen van de systeemgrens belangrijk?
a. Om te bepalen wat een Logische gegevensverzameling is;
b. Om te bepalen of de gegevens van een gebruikerstransactie de systeemgrens passeren;
c. Om te kunnen tellen;
d. Om het InformatieSysteemOverzichtsschema te kunnen verifiëren;

10. Definitie complexiteit
Wat is de definitie van de complexiteit van een gebruikersfunctie:
a. De hoeveelheid informatieverwerking van een gebruikersfunctie op grond waarvan het aantal functiepunten aan de gebruikersfunctie wordt toegekend;
b. De hoeveelheid informatieverwerking van een gebruikersfunctie op grond waarvan het aantal functiepunten wordt berekend;
c. De complexiteit van de berekening en de hoeveelheid informatie die in de gebruikersfunctie verwerkt wordt;
d. De complexiteit van de informatie die door de gebruikersfunctie de systeemgrens passeert;

learning and education

The English language wikipedia defines education as:
Education in its general sense is a form of learning in which knowledge, skills, and habits of a group of people are transferred from one generation to the next through teaching, training, research, or simply through autodidacticism.

For this blog I would like to define Education as Learning in an organized setting. Examples of organized settings are schools, universities, courses, lectures, and so on. From both definitions it becomes clear that Learning is broader than education. Learning can also be from a presentation at work, from a discussion with a fellow worker, by watching a youtube video, by participating in a workshop, and so on.

In my own branch, IT, learning is life long. The same will go for most brain workers. Learning can be in acquiring a new trick (how can I record a macro in excel) from a youtube video, learning the difference between credit and debit in a discussion from a fellow worker, learning how to organize your mail inbox from a blogpost in an efficient and effective way, or learning through experimenting with several ways to interview a client. Other examples may be a workshop, brown paper session, meetup, co-work job.

In the current recession, I also notice an increased emphasis on formal training in IT, in the form of internationally recognized certifications. As I said, IT-workers have both formal and informal learning life long. So here is a collection of links to recent research on learning in both education and informal learning.

1. John Dunlosky, Katherine A. Rawson, Elizabeth J. Marsh, Mitchell J. Nathan and Daniel T. Willingham did research in the way students could learn most effective from lecture and study books. They compared 10 ways which students often use to prepare for their exams. Of these 10 ways, practice testing and distributed practice received high utility assessments because they benefit learners of different ages and abilities and have been shown to boost students’ performance across many criterion tasks and even in educational contexts
2. Kou Murayama, Reinhard Pekrun, Stephanie Lichtenfeld, Rudolf vom Hofe did research the influence of motivation and cognitive strategies. Unfortunately only the summary is still available online.
3. In line with constructivism (see below), educators have come to focus more and more on the importance of lab-based experimentation, hands-on participation, student-led inquiry, and the use of "manipulables" in the classroom.
4. This research shows that willpower is an important factor in attaining your learning goals long term.

Besides these 2 articles on recent research, there are 2 good articles on the English language wikipedia on Cognitivism (learning theory) and more important Constructivism (learning theory).

Requirements - level of detail.

How detailed should requirements be? Should requirements always have the same level of detail?
That is a question which popups in nearly every requirements project. The only right answer i.m.h.o. is: It depends.

terminology
Before we proceed, allow me to spend some words on context and terminology. In this post I use the term "level of detail". There are other terms around, one of them is "granularity".

Context and domain
It is always important to establish the context of a discussion. Some methods distinguish between Business requirements and Functional Requirements. Some methods stress integration and traceability over all requirements. Without choosing sides in this discussion, I believe that much of what is written here applies to both. I do limit my scope to requirements for IT systems. Though requirements are also used in many other branches of engineering, my knowledge of other domains is too limited to say much useful about those domains.

Why would we limit ourselves?
Why would we not simply write out all requirements to the last detail? There are many reasons for this.
- Writing down requirements takes time. Time-to-market may no longer be as hot a topic as a couple of years ago, it is still often essential.
- Writing down requirements takes time, and time is money. That's no proble if it's your own money, but often someone else pays the bill, either your employer or the customer.
- Written requirements must be maintained. The application will probably exists longer than your assignment to the project, and any changes also may need to be a change in the requirements document.
- longer initiation phases means longer projects, and thus a greater chance that a changing environment will require a changed set of requirements.
Having said that, there are also very good arguments to DO write out detailed requirements:
- the need to maintain the application later may be facilitated by a good set of requirements. Though all too often I have seen outdated requirements, as programs always get updated, its documentation more rarely, its designs less rarely, and lets not speak about the rest.
- the need to ensure that no features are forgotten.
Many of the arguments in this discussion overlap with the arguments between agile and waterfall development.

Let's first have a look at some standard detail levels of requirements, and then have a look at this question in more detail.

3 levels model
A "high level" requirement has the form "Actor-Verb-Entity". Example: The system must show the account profiles.
A "standard" requirement has the form "Actor-Verb-Entity-Condition". Example: The system shows the account profile if the user is logged in.
A "detailed" requirement may still have "Actor-Verb-Entity-Condition" as above, or have "Actor-Verb-Entity-Attributes-Condition". Example: The system will show the user's own account profile, consisting of name-location, credit card info, recent failed login attempts, and recent ip-addresses logged in from.

However, other details may also be added, such as a calculation to be made, or screen details.

Cloud to clam
Other definitions are also used (Cockburn):
Cloud Level – very high level summary
Kite level – summary
Sea level – “single sitting” task descriptions
Fish level – small tasks that add up to valuable tasks
Clam level – very small details that make up small tasks
Cockburn uses these level when talking about Use Cases, but they may also be applied to other forms of requirements elicitation.


Now let's get back to our question: Should requirements always have the same level of detail?
As stated at the introduction, the level of detail depends. One thing it depends on, is its purpose. Requirements for which purpose?
a) For making a Function Point Analysis
b) For making a GO-NO GO decision of a waterfall project.
c) For making an INCLUDE / DON'T INCLUDE decision in an agile / scrum project on the next sprint.
d) For receiving a fixed date fixed price fixed scope (FDFPFS) tenders from suppliers.
e) For a system that you will build yourself.

These are quite different goals, and each has its own necessities. If the purpose is to enable an FPA: the decision here will depend on the level of the FPA. These in turn can be global, intermediate or detailed. These levels do not correspond 1:1 with the requirements levels described above.

Decisions for waterfall projects traditionally suffer from an overload of detail. Just because it will take long to realize them, and because managers are afraid for costly changes, managers and architects involved will feel uncertain and demand lots of details - even when the decision is just a GO / NO GO. This applies even more if the project will be realized by an external party.

For scrum projects, the main point is that any architectural risks and issues must be clear at the start. In RUP projects, architectural risks should be addressed in the first one or first two iterations. An important question here is: Are your requirements detailed enough to identify the architectural issues?.

FDFPFS projects typically require every detail to be spelled out, especially if a government agency is doing the tender.

If you intend to develop a system yourself, you may wish to sum up a feature list, in order to have a more complete mental image of what you what you are going to develop. A normal mind can mentally juggle 7 plus or minus 2 items, and your application may have more features than these, and more than you realized when you came up with the idea. Thus a feature list, or a use case model, may help yourself to get a more complete picture of the task ahead of you.

Requirements for whom?
You don't write requirements for the sake of writing requirements. Neither are you writing because someone pays you to write. For whom are you writing?
Let's have a look at possible answers:
a) For the development team: Nice, but what about this team? Do they know the subject area? If they do, you don't have to spell out every keyword in the domain. For example, if the team is experienced in the stock exchange, you wont have to describe call and put options.
b) For the CEO: IF the CEO doubts your knowledge and understanding of his business, you may be tempted to include more detail to show you understand his business. However, I find it very doubtful if the requirements document to be the document to convince him/her. Did you ask him what he wants to know?
c) For the testers: They want sufficient input for their test plans. But what input do they want for their activities? If they want to use your requirements as input for their global test plan, they might be satisfied with a feature list and a list of the non functional requirements. If they skip writing test plans, and just want to write extensive lists of testcases, they might require you to write up every last design detail. (And that they require you to do this, does not mean that you have to give in to them and cross the fuzzy line between requirements and design). Did you talk with them?

Requirements about what?
What is the topic you write about? If it is a highly technical piece of middle-ware, you may wish to concern yourself with the exact interfaces to be used. If this middle-ware is to be used by potential customers, you may be free to define the interfaces yourself. If at the rear of the application you have to connect to other components, some interfaces may already be given and non-negotiable, and have to be taken into account.
A traditional question here is: Am I talking about "what" or "how"?, though these terms are by no means a conclusive answer.

In which environment?
Did you have a look at your environment? And, no, I don't mean green. It may be that the organization has standards which have to be adhered to. Those standards have two sides, as given by these two questions: Did you list them as necessary for the project? Did you read them and found that certain non functional requirements have already been taken care of?

Another environment issue is the development tooling. Though the temptation to include solution specific terms might be great ("we all know it will be a website based on server based java"), this temptation should be strictly avoided. Nu terms like "persistence unit", or "sql table" should be used in a requirements document.

One last question: Do all your requirements have the same level of detail? I hope NOT. It is perfectly valid to work out some requirements to a very detailed level, while having others kept at a global level. For example, adding and changing an employees salary component may be standard, and described in five words. A salary calculation may take you several pages of detailed formula's.

graph theory


If we represent the relations between requirements as a (directed) tree (in the sense of graph theory), the vertices should represent the same level of abstraction. In other words, the degree of the vertices of degree 2 should have about the same level of abstraction.
But the leaves need not all have same degree, that is, the same distance between root and leave.

Links
iag
tyner blain

Configuration Management Plan

In ASL, Configuration Management is one of the five processes in the Maintenance process cluster. Like all processes, we want everything we do about it to be clear, structured, managed and audit-able.

The ASL-Bisl foundation, which you can find here, inherited all the stuff from the ASL foundation. It has a "Configuration management plan maintenance" and an example.

Unfortunately the plan does not state the goal of the document. Why is the CMP written?

In my humble opinion, a configuration management plan fits into the Waste - definition of Lean. Still, it is a useful item to prevent other kinds of waste.

A good Configuration Management Plan fits into both Maintenance and Development.
The configuration Management Plan defines  the items that are governed by the CMP, and the processes governing these items.

The CMP thus makes everybody involved clear:
A - what items are important to us?
B - where are these items stocked?
C - what is their status?
D - how do we make sure the items and their status is up to date?
All the rest is bogus.

Now why is this Waste as defined by Lean? Simply because it is not a primary process to produce what the customer demands of an IT organization. Is it useful? Yes, nevertheless it can be very useful, because it prevents other wastes.

These other wastes include:
(i) - Having lost track of items which are important nevertheless. On of my customers, an organisation with a large IT-department, had programs running. These programs ran for years, and never got changed. When after some 10 years they had to be changed, the sources could, albeit with considerable effort, still be hunt down, but the development environment was lost, simply because no one knew it was important. So it is very important to make a list of ITEMS which are important to a project or organisation.

(ii) - In the previous example, I used the expression 'hunted down' on purpose. Looking for programs can be extremely effort costly, even with networks and search facilities available. This search effort is clearly a waste of time. Thus: For every item you deem important, write down WHERE

(iii) - Did it ever happen to you that the developer made three copies of the programs - just to be sure? Fine. Now which is the current version? Time to sort this out is waste is Lean terminology. That is why it is important to keep track of the STATUS.
Status will generally vary over time. With version 2.2 in production, version 2.3 may be in acceptance test, release 2.4 in development and release 3.0 on the drawing board. Unless you know which status each items has, you may have a problem by moving a wrong component into production.
Another pitfall is the release that was successfully developed, but which did not move to production because of other business concerns by the customer. After three years, no one remembers this stalled project and items from the most recent version may be used for an emergency production patch - with all disastrous consequences, because software suddenly fails as the item moved depends on other items changed in that release.

(iv) It is one thing to write a CMP once. It is quite another to stick to it. Therefore the processes to change items and to maintain the CMP must be described too, and be part of the CMP. The processes described in the CMP govern Items, the Storage, the Status and even the CMP itself.

agile requirements : lessons from 5 unusual sources

Just a short remark this post: the magazine Agile record has a nice article by Raja Bavani on requirements lessons from 5 unusual sources.

From observing restaurants and waiters, he learned:

1. Welcome customers and stakeholders with a smile whenever
you interact – even when you are on the phone
2. Listen well to understand the requirements
3. Rephrase or summarize your understanding to get confirmation
before you end a conference call or a meeting
4. Believe in your expertise and stay committed
5. Be flexible enough to re-prioritize and accommodate
changes as long as it is not too late
6. When it is too late, be polite and communicate the impact
7. Be open and ask for intermediate feedback during your interactions
8. Feel free to talk about ‘what else’
9. Value time and money
10. Apologize when things go wrong

He emphasizes no 3: rephrase or summarize each requirement to check if you understand it well. Though rephrasing every requirements may be overkill, imho it certainly pays to do this for every requirement that might be unclear or liable for misinterpretation. And of course no 1 is a great way to keep spirits up. In my current project their is one colleague that manages to find something fault with everything. Everything is useless. It is very tiring to work under such circumstances. Keep up a smile, and look for possibilities.

From observing airports and flights he learns:

1. Preparation is critical to success. This is applicable to the entire agile team, including product managers or product owners, agile project managers or scrum masters and agile teams.
2. If you arrive late, you miss the flight. In the same way, you can’t accommodate late arrival of requirements during iterations.
3. Any delays or changes can only lead to further delays.
4. Change management can never be effective when there is no support from all stakeholders. You cannot blame an individual or a small group of individuals when things go wrong because of ineffective change management.
5. Dependency management in large projects is necessary to avoid wait time and delays. In case of large projects with many related projects, we need a function or a team that plays a role similar to that of the control tower in airports. In most cases, we call it the governance team.

His third source are children. Children are curious and explore without inhibition, he says. Though I disagree with the latter, I'd like to stress the positive effects of curiosity. In my youth in native Netherlands, curiousity traditionally was not encouraged in children. Some old proverbs as an illustration: Children who ask are skipped over, children may eat everything but not know everything, a curious ann (een nieuwsgierig aagje), and do on. But curiousity is the engine of discovery.

Likewise, he learns the importance of communication skills from schools and teachers.

His last lesson comes from ant colonies. I'm not very convinced about what he writes here, so i'll skip this topic, though what he writes about team roles is true.

You can find the complete pdf here. Certainly worth a read!

Requirements - functional perspective, structural perspective, behavioural perspective

IREB, the International Requirements Engineering Board, makes a distinction between three types of modeling perspectives:

• Structural perspective
• Functional perspective
• Behavioral perspective

Each of these views can be modeled in a view, which are aptly named:
* Structural view
* Functional view
* Behavioral view

At first sight the latter of the two may look as overlapping. Let's have a look at these three perspectives.

The structural perspective concerns itself with the structure of the elements which make up the system.
In UML it is supported by the following types of diagrams:
* class diagram
* component diagram
* composite structure diagram

For the functional perspective, typical UML diagrams are:
* Activity diagram
* Use Case diagram

For the behavioral perspective, i think a typical UML diagrams is:
* machine state diagram


In the above text I used the word 'modelling'. I know that this word is sensitive, as some requirements specifiers maintain that modelling is part of design, not of requirements elicitation. That discussion is quite another topic, and I only used the word because the IREB uses it in this context.