Wednesday, August 31, 2005, 05:14 PM - CMMI, CMMI Publications, Intermediate Concepts, PersonalAs the start of the course approaches I am now investing a lot of time in studying CMMI standards.
I have now completed my pre class assignment for the course. I would like to make it available to all as a possible help in understanding Integrated Project Management process area better, here is the link to it Integrated Project Management.ppt. It is also available in the 'Files' section on the right side bar.
I will try to put narration to it in the coming days to make it easier to use and more informative.
Please if anyone gets the presentation let me know what you think of it.
| [ 0 trackbacks ] | permalink | ( 3 / 3378 )
Tuesday, August 30, 2005, 02:49 PM - PersonalHere I am back form vacation. I was for a first time on an "all inclusive" type of vacation. I must admit this is the laziest way to spend some time. I was with my family (daughter and girl friend) at Hotel Rubin in the St. Kostantin & Elena resort in north Bulgaria on the Black Sea coast.
Above is a picture of the beach, sea and the swimming pool in front of our hotel.
Here is my daughter on the side of the pool in front of the hotel. Our room was on second floor, exactly behind my daughter's head on the picture.
| [ 0 trackbacks ] | permalink | ( 3.1 / 2955 )
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 )
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:24 PM - PersonalI have recently been doing interviews for hiring software developers and software test engineers. Some of the interviewees were good professionals some not, however what amazed me is the lack of maturity in some of the organizations at which some of the candidates worked. Surprisingly enough these organizations were not small shops doing web sites for under 50$ per piece. I summarized the information I gathered in these interviews to make people aware of software reality.
The first shocking experience I had was during the second interview of a software engineer working at one of the major Bulgarian banks. They use software supplied by huge CMMI 5 certified Indian company, specialized in banking software. The Indian company had sent two engineers full time to support the system throughout the branches of the bank. As the engineer explained the guys were extremely helpful, friendly, knowledgeable and willing to help. She then started telling me that form time to time that the software will fail. Well I thought this is normal, it happens with all software. Then she told me how the issues get resolved. Basically she would call the Indian guys they would fix the software in couple of hours and put it as pilot in some of the bank branches. If it then runs ok for couple of days they install it in all branches. Then she started telling me about program improvements and changes and again repeated the deployment flow. She also added that it had happened sometimes that the program will fail in some of the branches and then it is really hectic process to repair the corrupted data. Was I shocked, in my 8 year experience in various companies none of them having any CMMI seal I had never seen such vivid demonstration of profanity and lack of responsibility. Not only were changes to the software made in an obviously uncontrolled manner, not only was validation and verification of any kind missing, but risk of failures was directly transferred to completely unaware end users having their savings at stake.
Few weeks later I interviewed software quality assurance engineer working for mid sized German company supplying reservation software to some of the biggest European airlines. The company at least in his words followed strictly Rational Unified Process. We had discussion on how long it takes to test particular project release and how he would estimate the effort needed to test particular project. To my amazement the QA expert told me that they release their software weekly with the changes that customers had asked for during the previous week and within one week or less they implement changes to functionality performed tests within a day and deployed the new version on Monday. He added that in several cases they had to rollback production servers during working hours as software failed. He then added that customers are pushing for quick releases and testing the application thoroughly would cost a lot. I were then thinking of all the frustrated people that lost their reservation data, missed a flight or in best case had to spend couple of days to make a simple reservation.
| [ 0 trackbacks ] | permalink | ( 0.8 / 1581 )