This blog is the temporary home of the Tulsa Hadoop Users Group.  Some of our exciting topics include:

• Hadoop configuration, setup, and development
• Mahout
• NoSQL
• NewSQL
• Map/Reduce and functional programming, parallel computation
• Sensor data aggregation
• Big Data business cases

The first meeting will be held on Thursday, March 14th at 6:00.  Thus far a location has not been determined.  Please stay tuned!  RSVP by signing up in the comments area below.  Thanks.

SharePoint Development Estimation using Function Points

Sometimes it can be very difficult to predict how much time it takes to develop a project in SharePoint. Many people claim to take the time it would take to develop a project in ASP.NET and double it for SharePoint. However I am a big fan of Function Points. So after getting a general idea of the project specs I go through these guidelines to classify the SharePoint components:

Inputs: Web Parts, Sites, Admin and Site Pages, Forms

Outputs: Web Part, Search, Reports, Custom Pages

Inquiries: Object Model Code, Simple Workflows

Logical Intermediate Files: Lists, Libraries, Content Types, Fields, XML/XSLT web part formatters

External Intermediate Files: Features, Solutions, BDC


For example, I am currently working on a custom search feature to be associated with specific metadata. Here is how I have classified the pieces of this project.

Inp: 1 web part for the Search Box
Out: 7 web parts for all the Search Results
Inq: 3 feature recievers
LIF: 1 advanced search xml properties
EIF: 3 features (search box page, advanced search page, search results page)

Great, now I apply a set of complexity multipliers for the low, medium, and high cases:

Inp x3 x4 x6
Out x4 x5 x7
Inq x3 x4 x6
LIF x7 X10 x15
EIF x5 x7 x10

Now I multiply everything and add up the columns

1x3 = 3
7x4 = 28
3x3 = 9
1x7 = 7
3x5 = 15

Low = 3 + 28 + 9 + 7 15 = 62

1x4 = 4
7x5 = 35
3x4 = 12
1x10 = 10
3x7 = 21

Med = 4 + 35 + 12 + 10 + 21 = 82

1x6 = 6
7x7 = 49
3x6 = 18
1x15 = 15
3x10 = 30

Hi = 6 + 49 + 18 + 15 + 30 = 118


Now lets bump those numbers up by a 15% fudge factor to account for SharePoint difficulties.

Lo = 62 x 1.15 = 71
Med = 82 x 1.15 = 94
Hi = 118 x 1.15 = 136


Finally if we take the square root of those numbers that gives us a first cut at the number of man-hours required to do this work.

Lo = 8
Med = 10
Hi = 12

Based on experience I know that this is probably just the amount of time to code up a solution to do this. Now we have to throw in some learning curves. After all just about every SharePoint project has components that are dissimilar to the existing codebase and thus has to be researched via blogs or experimentation.

We assume our learning curve follows a linear curve:
Y = a * X ^b

Where Y is the amount of extra man-hours required for learning, a is the amount of hours to learn just one component of this project, and b is the rate at which we are able to gain productivity from learning. Since we are using a square root of function points to estimate man-hours, the exponent of our learning curve is -1/2.

For each component of the function point model I am using for this example I estimate that learning how to do something will take 1 hour on the low end, 2 hours for medium, and 4 hours for the high end. So our learning curve is:

Ylo = X^-1/2
Ymed = 2X^-1/2
Yhi = 4X^-1/2

Since there are 15 components to the entire system our learning curves are:

Ylo = 0.26
Ymed = 0.5
Yhi = 1

Now these are the costs for a single unit. To get a total we have to add them up over all 15 components. Finally we add the function point man-hours to the learning curves to get an estimate:

Lo = 12
Med = 18
Hi = 28

These are pretty close to what I am able to do on my own. A much more skilled developer might be able to do this in less time but not half the time. For a less skilled developer the learning curve probably goes nonlinear.

Good topic of discussion over which technology fits into the structure of a knowledge project

Click Here

Who uses enterprise social content?

Market surveys indicate that about a third of companies were actively using knowledge based tools in their organization to cut costs, prepare for a greying workforce, etc. Unfortunately the 1:9:90 rule tends to to apply in organizations. The end result all too often is that the senior manager who thought it would be a good idea to use social media ends up being the only contributor, and shortly thereafter the iniative is dropped.

A lot of discussions are now being conducted around the concept of participation. However much is made of encoraging users to be contributors. In my experience users will contribute to a small extent but if they do not learn how to become consumers of new knowledge the diffusion of any innovative or productivity gains will be too small. Training is important to achieve this objective, but active training. Most corporate training is sanatized because its based on lectures. By creating a training that demands user involvement there is more retention and usage.

... stay tuned for a future post over small communities of practice