Sunday, August 14, 2005, 12:21 AM - CMMI, CMMI Implementation, PersonalHello
I have not made any new postings for a while. Reason is I were busy.
I am now going for vacation so posts will be missing for at least two more weeks.
Good news is I will make some interesting posts afterwards. As I will be studying the CMMI models very hard next two weeks to assure success at the Intermediate concepts of CMMI course.
Also below I include one of my posting to the
cmmi_process_improvement Yahoo group (It is very good, join in case you are not a member yet). It is about estimation of software projects, it may be interesting to some of the visitors.
here is my 2 cents on the matter
It is probably best to get some reading on estimation.
There are many ways for estimating software projects.
Reality is estimation is more expert work(art) and
less defined formula. What you can do by formalizing a
process is to make your artists better (by avoiding
errors e.g. "I forgot we have to buy licenses" -
assignable deviation) and allow a newbie to quickly
step up and work like the experienced guys. Below I
have described what I use in estimation and have found
to be good approach. It is illustrative of the size
vs. effort dilemma.
First few introduction words. In my view "size
estimate" should be an estimate that does not take
into account schedule constraints, resource skill
level, associated risks, availability of tools etc..
Such estimate one can later use for comparing
projects, analyzing performance and influence of
A good example is the use of sq. feet to measure the
area of a house; this metric has relation to the cost
and duration of construction, but is not the only
factor. Comparing price per sq. feet gives good idea
of how luxurious a place is supposed to be.
A very simple example why you should not jump directly
to effort estimate is "a single woman gives birth in 9
months, but 9 women cannot give birth in 1 month" i.e.
timeline does not relate in linear manner to team size
to achieve same goal. Thus effort depends on project
duration and the esimtate for a single task effort
cannot be correct without taking the big picture of
the whole porject. There are many constraints you
have to account for some acting on task level
(resource efficiency) some acting on global project
scale (ramp up, integration, testing, number of
defects made that need fixing, schedule constraints
Having said this I suggest you the following:
1. Ask your guys when looking at specifications to
assign relative numbers to each item they estimate –
call these "estimation points". Similar to task
duration, but without thinking "John is not good in VB
it will take him longer, so I say 5 days" i.e. use
what extreme programming does estimate ideal
development hours without time for maintenance,
learning etc. This of course means you have to make a
WBS alike structure i.e. spilt work in small pieces
that can be compared amongst each other and can be
estimated with good degree of certainty. I most often
assign value of 10 to some very obvious item that is
often repeated pattern in the application e.g. master
detail form in a database application. Sometimes you
may create several different estimates based on
different solution alternatives refer to CMMI ML 3
Requirements Development and Technical Solution areas.
2. Sum the estimated values for all tasks
3. Next build list of all factors that influence the
project in a good or bad way. In my experience
organization wide checklist of items works very well.
The list may also contain some guidance for
quantification of the item. Some things to look at:
a. Is the technology new to the company? Is the
technology very new for everyone (likely to be risky)?
b. How senior are the people assigned?
c. What training is required? What is the ramp up
time i.e. how long would a person need to get
comfortable with the requirements
d. How much testing effort will be needed?
(proportional to development)
e. How much time and resource will you need for
integration and fixes, again proportional?
f. How much project management time will you need per
week or as percent of development?
g. How well have you performed on similar projects
even if you do not precisely know why e.g. you may
know that a particular customer is problematic and
things often do not work well.
h. Do you have to give warranty? How much resource
you need for this?
i. Is there some transition period during which you
have to provide extended support?
4. Taking into account the factors from point 3 above
estimate how long would it take to complete 10
"estimation points" from point 1 above. Apply only
those that influence single task like experience of
people, availability of hardware and other tools i.e.
ramp up, project management and testing do not go
5. Multiply the number from point 2 by the duration
from point 4 and divide by 10. This is the ideal
development time wihtout management, fixes,
integration or testing.
6. Taking into account project wide factors from point
3 (that were ignored in point 4) create the time
schedule for your project and the complete effort
estimate (ramp up time, project management, testing,
integration and any interdependencies come into play
here). As a rule of thumb team size you plan should
not exceed the square root of the project duration in
months e.g. if total effort is 9 months – team should
be of 3 or less people working for more then 3 months.
You can use Excel ot Project to lay out work. Useful
is to define milestones/phases(lifecycle) there are
many approaches to do this waterfall, iterative,
spiral (build guidance and provide training for your
guys when to use which; some organizations pick one
and work with it, until need for change is apparent).
7. Now add to the effort cost any additional costs –
equipment, licenses, travel, vacations (checklist
guidance helps here as well) this produces your cost
You should try several times this on small scale
Use you gurus to build your own solid process i.e.
good checklists and guidance, they will be very happy
to feel part of the effort and will ultimately like
more to work with things they made rather then things
you give them.
Data from estimation you should store in a global
location and later when analyzing the project or
milestones you will probably spot omissions in the
checklists, process or their use. This is how
I hope this is of some value to you. Basically you
should look at the bigger picture when costing
projects not only work needed by particular individual
for particular task. This will allow you to compare
efficiency of projects and teams to detect problems
and successes ultimately becoming better at what you
| [ 0 trackbacks ] | permalink | ( 3 / 629 )
Friday, July 15, 2005, 12:30 AM - CMMI, CMMI Implementation, Technology, Technology IdeasIf you have read one of my first postings (CMMI first post ) you know I have been looking for the right tools for the job up till now. It seems the search is almost over and I have found a solution that will require little or no programming effort and will allow to achieve the goals set forth in the earlier posting.
The solution I have in mind combines the latest Office technology from Microsoft to deliver flexible and easy to use system.
1. SharePoint Services
3. SQL Server
The idea is to organize the various artifacts in SharePoint to utilize its facilities for:
- organizing data in various views (grouped by, filtered, with only relevant information displayed)
- easy access via web interface
- provision for integration with Office, SQL Server and virtually all other MS Technology
- ability to version data
InfoPath provides means for editing structured data i.e. has advantage over Excel and Word with
- strong formatting i.e. users cannot involuntarily corrupt the format/schema
- validation facilities
- multiple views on data
- ability to sign documents electronically, important for documents that pass through review cycles
- ability to integrate with external data sources
SQL Server is of course providing facility for keeping data in a format that is easy to query, aggregate and analyze
Word and Excel are going to be used as report/result presentation tools.
The Big Picture
So far I had elaborated initial vision of the solution and only high level architecture.
In short we need:
1. Process Asset Library - holding different organizational process artifacts
2. Project Measurement Repository – this will hold the measurements we collect.
3. Per project repositories where project records will be held along with the projects defined processes
4. Additional data – these will be different lists with clients, contacts, suppliers, training & qualification records
The basic workflow for a contracted project will be:
1. Plan the project:
a. Input project summary info (planned cost, size, effort)
b. Create Project Repository
c. Create Project’s Defined process
2. Summarize milestone i.e. allocated engineers, planned and actual milestone data (effort, # defects, # change requests)
3. Complete the project
a. Enter completed project actual values and lessons learned, problem root cause analysis
b. Summarize the projects process specifics into the PAL as needed
Well this is what I am working on now. Once I make the complete solution from technology and requirements I will post more details.
I am also going to look at what the MS Team system is like as it may be just too similar to what I am doing. I am a bit afraid that it is going to be too much Microsoft Centric and integrated with Visual Studio, which of course is not good for .Net free projects.
Thanks for reading :)
| [ 0 trackbacks ] | permalink | ( 3 / 4228 )
Monday, July 11, 2005, 11:41 AM - Technology, Technology publicationsMicrosoft had published FabriKam DVD, a very nice SharePoint demo/tutorial with complete applications and several components that can be reused including ADSI integration and SQLXML web services.
The DVD can be ordered from MS site or can alternatively be downloaded from MSDN subscriber downloads.
| [ 0 trackbacks ] | permalink | ( 3 / 2277 )
Wednesday, July 6, 2005, 11:11 PM - PersonalI am very happy over the last three days I have had lots of visitors from all over the world. I hope the visits were worth the time. See statistics below
| [ 0 trackbacks ] | permalink | ( 3 / 511 )
Tuesday, July 5, 2005, 02:38 PM - CMMI, CMMI PublicationsThis is very interesting Microsoft's new MSF will be developed with the guidelines of CMMI in mind. This is great as it will arm the Microsoft community with suitable tools for the job, hopefully making great push in software quality.
I am a bit afraid that this may not actually work as planned, but at least the direction is right.
See MSF for CMMI
Indeed the whole site of David Anderson is very interesting, see Agile Management
| [ 0 trackbacks ] | permalink | ( 3 / 533 )