Thursday, November 10, 2005, 12:22 PM - CMMI, CMMI Implementation, CMMI Publications, Personal
I have recently decided to help make CMMI more popular in the industry here in Bulgaria. Most people have heard about processes, CMMI and things alike, but I think the culture is not here, yet.
I spoke to the editors of couple local publications to write some materials on CMMI, process improvement, PSP and related.
… and I got the first result.
Next Monday I am going to have my first article printed in InfoWeek, titled "About the benefits of implementing CMMI". The article is in Bulgarian, so it may not be easy for all web visitors to read. In summary it presents the challenges that many of the software organizations face like changing requirements, attrition… Then briefly explains what CMMI is and how it benefits software organizations. Finally I present an implementation approach based on SEI's studies on CMMI in small settings and the book "Making Process Improvement Work". The main points of the approach are:
1. Use continuous model to address the most acute pains and assure quick ROI. Use Capability Level 1 to remove immediate risks.
2. Rely on ISO 9001 for initial institutionalization, this will reduce cost and keep focus on the problems at hand
3. Focus on deployment and process adoption form the start, do not wait to have the perfect set of processes and then attempt to change people around them
4. Focus on measurement of business results, plan implementation and CMMI implementation progress
I hope the article will sparkle interest in the broader audience about CMMI. Up to now the awareness and will to adopt CMMI practices in Bulgaria had been primarily in software outsourcing companies, mainly due to external push for more mature process. However my recent observations show that most of the companies in Bulgaria employ least to say immature processes and often deliver poor results because of this. This is why my article focuses on result oriented CMMI implementation.
| [ 0 trackbacks ] | permalink |
( 3 / 3075 )Sunday, October 16, 2005, 10:00 AM - CMMI, CMMI Implementation, CMMI Publications
I did some reading on the SCAMPI family of methods lately. After all this is the climax of the SPI program, the points where you see what has been done and what lays ahead.
Unfortunately the materials available on the subject are not lots and are bit tough to discover. A lot of the material is only available to Lead Appraisers in the “toolkit” they receive, including the definitions of the SCAMPI B & C Methods.
I have found a number of links to interesting materials that can come handy to others trying to learn more on SCAMPI:
Appraisal Requirements for CMMI, Version 1.1 (ARC, V1.1) official document that describes the requirements for a method used in CMMI appraisal.
Standard CMMI® Appraisal Method for Process Improvement (SCAMPI), Version 1.1: Method Definition Document This is an official book on SCAMPI, it describes in detail the SCAMPI A method for appraisal. The first chapters of the book are targeted at mortals who are about the encounter one of the Lead Appraisers. Theses first chapters give overview of the process, the resource requirements, outputs etc.. I started reading it is nice, except that it uses the strange CMMI-ish language that requires translation to English.
SCAMPI B&C tutorial A presentation on the SCAMPI family of methods, contains lots of info in an easy to read presentation form
Project Selection for SCAMPI A This presentation gives some ideas about defining organizational scope and selecting projects.
PIID-SCAMPI-Tool A set of Excel files developed by Dr. Kneuper (see site) that can be used for summarizing and tracking information and results during an appraisal. The spreadsheets contain useful model and appraisal information like typical direct artifacts for all practices. The version of the tool available includes all PAs from maturity level 2 and 3 including IPPD and SS. Dr. Kneuper points that his tool resembles the one offered to lead appraisers by SEI. Thus we mortals again can take peek into the realm of the appraiser.
CMMI® SCAMPI Distilled: Appraisals for Process Improvement This is the book by Addison-Wesley and SEI on SCAMPI.
| [ 0 trackbacks ] | permalink |
( 3 / 2940 )Thursday, October 6, 2005, 10:02 PM - CMMI, CMMI Implementation, CMMI Publications, Personal
We had a meeting of spin-bg group. I had prepared a presentation on
1. "Intermediate Concepts of CMMI" course
2. CMMI Continuous Representation
3. The future of CMMI
The meeting was really good. Probably the first really interactive meeting that got people talking and sharing experience.
This I think started with our previous meeting where we had a guest lecturer. As one guy put it people start to feel comfortable sharing ideas and experiences and this is going to help the industry I hope.
There were also some good initiatives to share experiences on tool evaluation and implementation of certain practices.
I hope this spirit is not going to die out and bigger part of the industry is going to look at improvement, They really need to there are still companies around that do not even use simple source control
| [ 0 trackbacks ] | permalink |
( 3 / 5715 )Monday, September 5, 2005, 11:44 PM - CMMI, CMMI Implementation, Intermediate Concepts, Personal
To facilitate my learning of the CMMI I have developed an Excel sheet containing the titles of all CMMI key elements Process Areas (arranged by maturity level and Category), Specific Goals, Specific Practices, Generic Goals and Generic Practices.
I hope it may be of use to someone else trying to get grasp of this vast body of knowledge.
CMMI_breakdown.xls
| [ 0 trackbacks ] | permalink |
( 3 / 4318 )Sunday, August 14, 2005, 12:21 AM - CMMI, CMMI Implementation, Personal
Hello
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
different factors.
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
etc.).
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
here.
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
estimate.
You should try several times this on small scale
projects.
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
improvement works.
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
do.
| [ 0 trackbacks ] | permalink |
( 3 / 2715 )Back Next
6474495
