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
Thursday, November 20, 2008
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.
Subscribe to:
Posts (Atom)