What would you think specifically is the chief difference between CMMI and CMM
Level 2 for SQA?  Any new KPAs?  What's the significant difference?
I don't want to get us all compliant with something that's noncompliant in
2004..
Alice Copeland Brown

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

barry

you better start with PSP and TSP for a start

that will give you a good head in the way to achieve CMM  certification
also it will help you in acieving the sense of vary high quality
consciousness in your staff

regards
mangesh

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

I have added two files to the collection here. The
CMMI tutorial (cmmi_tutorial.pdf) approaches CMMI from
a systems engineering perspective. Even though I'm not
not personally totally convinced as a systems engineer
that CMMI is not a lot of overkill, rather than an
upgrade from EIA/IS 731, there may be few options
since the government seems committed to that path.

Since INCOSE, GEIA, and others did a large amount of
research to produce the EIA/IS-731 Systems Engineering
Capability Model (SECM) to bring together the SECAM,
SE-CMM, and the EIA-632 standard (Processes for
Engineering a System), I'm not entirely clear about
what the CMMI adds to the mix, other than muddying the
water by adding a lot of complexity. Maybe someone
will eventually explain it to me.

I also added some charts from Artisan (uml.pdf) on
using UML use-cases to model real-time and
mission-critical hardware and software systems, which
I think is pretty exciting. I still use a QFD analysis
for initial system definition, but I think UML has a
lot of potential for fleshing out and documenting the
system details.

Bonnie Arturo
Principal Systems Engineer

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Sarah,

I think this choice is analogous to an organization's choice to implement
either the Continuous or Staged versions of the CMMI. The Continuous model
is more likely to produce lasting process improvement gains, since the
implementation is designed to shore up an organization's weaker process area
by applying focused effort to improve that weakness. Such intense scrutiny
and attention is more likely to produce lasting (or 'continuous')
improvement since the parties involved sense involvement and commitment by
upper management in their daily activities.

Conversely, the Staged representation attempts to mimic the SW-CMM
successive pass/fail graded levels, which often forces organizations to
build a façade of process artifacts to pass the assessment, kind of like
cramming for a test, and relapse once the assessment target is reached.
Since the Staged representation is much, much easier to understand from
assessment point-of-view and hence much easier to judge the return on
investment ("Quality may be free, but it ain't cheap"), the Continuous
representation is anathema to most of management, particularly those
enamored of the cut-and-dried SW-CMM stepped grading levels. Systems
engineers in general seem to have a much greater appreciation for the subtle
theme of continuous improvement; i.e., it is not the grade that counts, but
the progress realized ("Maturity is a function of scar tissue." - Mark
Paulk).

The same logic is true for large organizations attempting to unite an
operating site consisting of several disparate programs with different
customers (commercial or government), different business goals and
requirements, and operating modes. Whereas it is much easier for such an
organization to functionally manage the program components under an umbrella
process structure (especially for organization-focused SW-CMM efforts), the
process improvement effects would be more meaningful and long-lasting if the
improvement efforts were tuned to a particular program's needs. This is
actually an area in which the individual and team oriented PSP and TSP
improvement models excel, by using Watts Humphrey's techniques for focusing
on a bottom-up approach to quality improvement. There is very little
information, unfortunately, coming from the SEI about using the PSP and TSP
in conjunction with CMMI to build an ideal process improvement discipline
tailored to the individual program business goals within an organization.

Bob Robinson

--- In cmmi_process_improvement@y..., "sheardsheard" <sheard@s...>
wrote:
If you have only one organization performing software and systems
engineering in a few projects, it's fairly clear to see how to apply
the CMMI to it. But how should large companies react, when they have
several pieces that they all want to reach some level?  Should they
assess all together, or allow the individual pieces to have
completely different processes but get, say, a Level 3 internally?
Should the companies try to bring all processes together under some
sort of umbrella process structure?

I am right now working with these issues and others and was wondering
if anyone out there has read anything with guidelines on this subject
or else has any opinions.

Thank you in advance

Sarah Sheard
mail:  sheard at software.org (change the "at" to the at sign)
--- End forwarded message ---

If you have only one organization performing software and systems
engineering in a few projects, it's fairly clear to see how to apply
the CMMI to it. But how should large companies react, when they have
several pieces that they all want to reach some level?  Should they
assess all together, or allow the individual pieces to have
completely different processes but get, say, a Level 3 internally?
Should the companies try to bring all processes together under some
sort of umbrella process structure?

I am right now working with these issues and others and was wondering
if anyone out there has read anything with guidelines on this subject
or else has any opinions.

Thank you in advance

Sarah Sheard
mail:  sheard at software.org (change the "at" to the at sign)

Barry,

Here are my thoughts (I am an authorized lead assessor and have been
working with the CMM since 1990 either as a SEPG lead, or as a
consultant helping other organizations inplement quality programs).

There are two reasons to implement the CMM.  Someone told you to
(usually through contractual negotiations) or because it adds
business value for you.  In the case of the DoD world, it is often a
contractual requirements.

The focus of the CMM is to create repeatability in an ever improving
fashion and to reduce the organization's reliance on heroic
efforts.  If sounds from your note that your past successes have
been do to individual efforts.  The CMM wants to capture what you
did right and repeat for the future.

There is a cost associated with implementing the CMM.  The last time
I looked at the SEI literature, I think it stated that about 5% of
the organization's budget should be spent on process improvement
efforts.  I normally work with large organizations (600 - 1800 IT
employees) and 1% to 1 1/2% has been plenty for me.  If I were in an
organization of 5 to 10, I'm not sure that 5% is enough.

The CMM does not require documentation for the sake of
documentation.  It is meant to be reused and improved over time.
There is a cost for the first iteration through the process to get
everything in place.  Once it is in place things normally go faster
and cheaper.

I wouldn't worry about getting through all the KPAs at first.  Focus
on adding business value.  Only worry about crossing all the t's and
dotting all the i's if you are going to do a CBA IPI or a SCE.

In terms of cost, it is the organization's call as to how to recover
them.  They can either make it a line item and bill it, or they can
include it in the bundling of the labor rate.  What I have seen is
that unless the CMM is contractually required, it is in the bundled
rate.  I don't think the DoD is too tolerant of it being a line item
any more since by now, the CMM is expected to have already been
implemented.

I hope that helps.  If not let me know and I'll try to give you more
info.

Thanks...
--- Jay Pickerill
     NewLane Partners







--- In cmmi_process_improvement@y..., Barry Schweitzer
<barry_schweitzer@y...> wrote:
> As I mentioned in an earlier posting, my small
> business has acquired a subcontract which requires a
> significant investment over the way we currently do
> business. We think that part of the reason for our
> past successes is that we do pair programming and
> minimal documentation, focusing on the product and
> one-on-one interactions with the customer to ensure
> that all the system requirements and their operating
> requirements are satisfied.
>
> If we are to implement the SEI processes, with all the
> documentation requirements and external inspections,
> how much budget should we allocate for SEI CMMI
> process improvement? How do you decompose all the
> process overhead into manageable chunks and justify it
> to the business people?
>
> Since our prime contractor is attempting to be
> assessed at CMMI Level 4 this year, should we copy
> their processes and try to perform some subset of what
> they are doing, or just start from scratch and try to
> meet the process areas that support our business
> goals? Are there any existing guidelines for applying
> the SEI guidelines to very small business
> organizations?
>
> Barry Schweitzer
> Technical Lead
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com

As I mentioned in an earlier posting, my small
business has acquired a subcontract which requires a
significant investment over the way we currently do
business. We think that part of the reason for our
past successes is that we do pair programming and
minimal documentation, focusing on the product and
one-on-one interactions with the customer to ensure
that all the system requirements and their operating
requirements are satisfied.

If we are to implement the SEI processes, with all the
documentation requirements and external inspections,
how much budget should we allocate for SEI CMMI
process improvement? How do you decompose all the
process overhead into manageable chunks and justify it
to the business people?

Since our prime contractor is attempting to be
assessed at CMMI Level 4 this year, should we copy
their processes and try to perform some subset of what
they are doing, or just start from scratch and try to
meet the process areas that support our business
goals? Are there any existing guidelines for applying
the SEI guidelines to very small business
organizations?

Barry Schweitzer
Technical Lead


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

I work for a well-known commercial airplane company with no official
position regarding CMMI, with the only advisory that "it is up to the
organizational management and business requirements" to dictate the
path taken. Since parts of our organization have already decided to
adopt the CMMI approach, our process improvement leadership hopes that
within the next few years they will see some "measurable results". For
our division, we are personally committed "to maintain the course of
Software-CMM since we are very successful in using this model and it
integrates well with our People CMM approach".

Coupled with the organization process and product efficiency gains due
to some pilot PSP and TSP successes, we are reluctant to switch to the
SEI latest flavor-of-the-month (CMMI), particularly when SEI seems to be
waffling on some of the migration and deployment issues. The most
important thing is to pick a course and stick to it. Perhaps if you
are just starting out on a process improvement journey, CMMI may be
the way to go, since SEI seems committed to that as the only future
option. To quote some quotes already quoted by John Vu:

"It is foolish to board a boat if you do not intend to cross a river".
- Lao Tsu

"When the boat is at the pier, the water is shallow and no one is
afraid, but in the
middle of the river where the water is deep, everyone is fearful of
drowning".
- Lao Tsu

John Vu Translation: Many organizations express their willingness to
improve their process but after an assessment, when their maturity is
well known, that willingness can sometimes disappear, often in the
middle of an action plan implementation and when a considerable amount
of money, resources, and time has been committed. This is the wrong
time to realize what process improvement really means.

Jan Winters
Software Lead Engineer

--- In cmmi_process_improvement@y..., "alicecbrown" <alicecbrown@y...>
wrote:
> Someone said that the CMM is no longer being supported by the SEI
> after 2003.  Is this true?
> I'm going after some quality related objectives that deal with a
> specific project.  Can some of you give me some examples that don't
> involve '100%'?
> Thanks

Someone said that the CMM is no longer being supported by the SEI
after 2003.  Is this true?
I'm going after some quality related objectives that deal with a
specific project.  Can some of you give me some examples that don't
involve '100%'?
Thanks

I'm a little curious about the whole function point
counting ritual. Even though I agree that counting and
predicting lines of code is pretty useless, since
skilled programmers generally produce more efficient
programs with less lines, why are there so many
variations of function point counts? From the simple
initial origins developed by Allan Albrecht, I see
unadjusted IFPUG function point composite counts, the
evolved Galorath function points, feature points, 3D
function points, and all the other attempts to create
a better mousetrap. What is there about function
points that distinguishes a 8000 sq. ft. industrial
complex from a 8000 sq. ft. brick and marble mansion,
provided the number of doors, windows, and stairs is
about the same?

If the function point counting seems a little
arbitrary, then the Caper Jones backfiring to get the
function points translated back in lines of code
really seems like black magic. I guess as long as
everyone in the organization uses the same rule set
and function weights, then the results would be
consistent for that organization, but the use of
multiple "magic number" values by backfiring to
produce a simple scalar to appease management and the
customer has to compound the induced errors. If
management and the customer then use this erroneous
value as a decision pivot, the business impact could
be substantial.

Why is the IFPUG a closed group, with the inner
secrets only available to those large corporations
willing to pay the annual membership fee? Is using a
Certified Function Point Specialist the only way to
get an objective FP count, since seasoned software
engineers on a program will use their intuitive
knowledge to tilt a user count? Since my small
business has operated very successfully using agile
pair-programming techniques for quite some time, we
are kind of awed at the level of overhead labor
required for our recently awarded subcontract, which
dictates the use of CMMI and function points linked to
the prime contractor's processes to track our product
delivery performance.

Barry Schweitzer
Technical Lead

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

As we journey along toward CMM Level 2, I am working on the following
to get the most Return on my Investment.  Can you think of a better
way to state the Quality Objectives?
					 Major NOE V4 /HSBY Risks

Situation Risk Quality Objective
No formal sit-down review exists for the primary specifications of
the system: the Product Specs and the Technical Specs.  This is
where `hidden' obstacles can be surfaced and
ambiguities/misunderstandings can be clarified.  Had the
questions, "Can this be stopped and re-started?" been asked about
Global Data Management, our problems might have been solved through
prototyping in that area. Expensive mistakes are made as
development proceeds due to inadequate reviews; e.g., PS passed with
serious inadequacies within. Requirements are written that are
untestable, unquantified, and easily misunderstood (ambiguous), but
are `passed'. 100%  PS and TS reviews will be held formally in a
video or face-to-face setting, providing opportunity for discussion
of each requirement.
The test engineer has seen no documentation of the Data Dictionary,
the Message Protocol of NDDS, built by a subcontractor. Lack of
documentation from the subcontractors prevents clear understanding
and the writing of clear test cases/conditions  . (e.g., What does
the data look like within the message?  Am I looking at control
characters, headers, footers, etc from RTI who developed NDDS?
	 100% of all documentation from the contractor will be
delivered and reviewed prior to verification/validation.
100% of the data formats from the subcontractor will be reviewed and
approved by the NOE V4 TPL/team.
Commands are lumped together in the PS, with few interfaces defined
specifically or showing their sources and destinations.
Turning the specification into test cases is therefore difficult.
	 Testing will be done on one case, treating all the other
conditions as `the same', when the behavior is actually different
(e.g., 6 error codes are shown on P. 11 of the HSY PS, but it is not
clear if the system responds differently to each condition) 100%
of all inputs and outputs will be defined separately and thoroughly,
including units, data rates, anomalies, and ranges.

Functions are in the Technical Spec which are not being used. (e.g.,
DHCP), as well as in the Product Spec (e.g., 140 NOE 771 21)
	 Interfaces can be defined and test cases designed for these
undeleted items that waste time and create confusion.  User's guides
could be written, misinterpretations made of the specifications.
	 100% of all delayed or deleted features/functions will be
deleted from the specifications within one month of the decision
being made.
The behavior of certain states is unknown (e.g., What happens when
the HSBY sends a message to the Device Manager, but the Device
Manager doesn't respond?) or not documented in the TS. If test cases
or results are unknown and documented for 80% of all probable
conditions, either at the Verification/Validation, Qualification or
Unit Test, the system cannot be thoroughly tested. 80% of all
known messages/commands for all identified modes, their stimulus and
possible response (or lack of) shall be tested and results documented.

(If a case can be made that some commands behave in precisely the
same manner as another under the same conditions, that would be a
reason for NOT testing such a command.)

Object oriented analysis/design/programming is not well known or
understood within the team.  Clear documentation of base classes and
identification of the subclasses would allow for design of a set of
test cases for the base class, and any extra test cases for the sub-
classes (because of their extra features). Opportunities for
design/re-use of test cases, addition of test cases for sub-classes
(without expensive re-testing of the entire base class) can be lost.
Lack of clear documentation makes the reason behind these savings in
money unclear. All team members should be trained in Object Oriented
Design Standards and the accompanying documentation.
A Qualification Plan exists for the `old HSBY".  This is to be used
because `the functionality for the newly-coded HSBY is the same'.
	 This may not be true, as the behavior of the new code may 1)
harm the old functionality or 2) introduce new behaviors. 100%
of all test cases shall trace to the Technical Spec, which shall
trace to the Product Spec.
The Qualification Plan in turn shall trace to the Product Spec.
Each component/function (Telnet, HTTP Server, FTP Server, Device
Manager, HSBY task initialization, DHCP Server, Global Data
Enhancements, I/O Scanner Enhancements) has had the Technical
Specification portion written separately.  Clear interfaces between
them all have not been documented.  (It appears that all components
interface with the Device Manager). Without analysis and detailed
definition  of the interfaces among these components, the risk exists
that certain behaviors will not be tested and problems will occur in
the field or at Qualification time.  Especially, the interfaces
between the Global Data and DM/NDDS should be defined and tested
because
1) Problems have already occurred with Global Data Enhancements and 2)
NDDS is built by a 3rd Party. 100% of all interfaces between
Schneider functions and 3rd Party functions shall be rigorously
identified and tested.
100% of the relationship/interfaces between each component and all
others shall be defined.  Where there is NO interface between
components defined that too shall be stated.
The Software Development Process indicates Unit Tests are performed,
as well as Validation tests.  However, there is no Root Cause
analysis task identified.  This process should be included in order
to determine if the defect is caused by code only, a design defect or
a disconnect/inadequate requirement. Qualification will start and
a basic disconnect will be discovered because the root causes were
not discovered of the IPRs. 100% of all Urgent and High IPRS will
have root cause analysis performed to determine if an incomplete or
faulty set of requirements is at fault.
We are in Verification/Validation but all of the NOE V4 Technical
Spec has not been completed. I am also receiving new versions of the
HSBY Technical Spec.

Staggered integration and verification is quite proper, but only if
all the interfaces have been tightly defined.  Each source and
destination of every message/command/input/output is known.
	 Disconnects among the portions will provide a false sense of
Verification Testing complete, because those relationships have not
been certified as separate and independent. 100% of all
interfaces among components will be defined.  100% Validation testing
will be re-done of any components (i.e., where heretofore
undocumented relationships are uncovered ) as validation proceeds.

Too bad, the table formatting was lost.

Several CMMI references were added to the Files area over the weekend
and a Training folder was added to the Bookmarks area. Please feel
free to upload additional resources to the Files area, and bookmarks to SEI
authorized training partner sites and projected training schedules
into the Training folder.

Bob Robinson

I work for a SW-CMM Level 4 organization that has
recently successfully acquired a global network
communications contract, taking over for a company
which defaulted on a multi-year effort consisting of
100,000 source lines of C++ code and is currently
closing out the remnants of their business units. As
part of the strategy to ensure that a similar contract
runaway doesn't happen again, the prime contractor has
required that my organization produce a detailed
parametric cost model (using SEER-SEM, COCOMO, or
SLIM) with product size estimates in Function Points
or lines of code estimates to track in monthly Earned
Value reports as a measure of contract progress.

Since the existing software is functional and mostly
salvageable, we view this effort as mostly an
optimization and maintenance job. The existing design
works, but fails to meet a large percentage of the
real-time requirements. The defaulting contractor used
Function Points to measure progress and gauge scope
creep, but failed to capture those non-functional
requirements (how, when, where, and how) that are
critical to the end-users, such as interactive
response times, data security, and stressed system
scalability. Since the lines-of-code count will
probably be reduced and the Function Point tally will
remain relatively constant in the optimized end
product delivered by my organization, we are
struggling to come up with an appropriate contract
productivity measure to present our customer in our
software management plan and metrics delivery. Has
anyone in the group dealt with a similar problem in
metrics collection/analysis?

Like most of the SEI-disciplined world, we are also
looking toward CMMI as the most likely future
organizational process discipline model, but we feel
that much of the added systems discipline burden will
be assumed by the software staff, especially in the
beginning stages. As the software organization
matures, particularly in the higher CMM levels, the
software practitioners begin taking on a larger
percentage of tasks once relegated to the systems
planners, both in the requirements planning and the
verification testing activities.

Bill Alexander
Senior Project Analyst

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Good comments, Bart!
I have written a paper called, What Is Senior Management Commitment,
which addresses how to get senior managers to commit to CMMI or any
other kind of process improvement. I will send this paper to anyone
who requests it by off-line email to
sheard@...

Sarah Sheard


--- In cmmi_process_improvement@y..., bartham@a... wrote:
>
> > 1. How do I initiate the entire Process? What would the the first
step?
...
>
> You need upper management to tell you what their biggest problems
are.  Pick
> the easiest one and work it first, you want a quick win.  Then get
middle
> management to give you a list of their problems.  Create a software
> development life cycle and start to fill in the processes as they
are
> completed.  Keep this visible to everyone so that you are not
creating a
> "secret scheme".  Be open to comments, and feel free to reject them
if they
> do not fit with what you want to accomplish.
...
> I hope that this helps more than it confuses.
>
> Bart

Bill,

I still have to wonder why the organization would pursue "Level 4 for
software and Level 2/3 for everyone else?".  Is the philosophical intent of
CMMI not to better control the overall software life-cycle by melding the
systems and software disciplines (either by moving the software engineers to
the left to apply systems engineering principles, or moving the systems
engineers to the right to gain more control by continued involvement past
the requirements definition phase, depending on the organizational bias), so
that moving an organization's goals toward CMMI should involve more than
just expanding the scope of SW-CMM?

Even though jump-starting the organization's systems engineering groups (who
in many cases evolved from a hardware engineering background) into CMMI
involves a paradigm shift about as radical as the transition of software
engineers to structured analysis in the 1970s, systems engineers have
evolved along a different path and are generally more aware and competent in
the requirements management and risk management process areas in many cases
than their software counterparts, greatly aided by the collaborative efforts
of INCOSE and the maturation of university Systems Engineering curriculums.
Wouldn't a more logical approach for a SW-CMM Level 3 software organization
attempting a migration to CMMI be to start from a relatively blank sheet;
i.e., not throw away the existing gains from SW-CMM and EIA/IS 731, but
focus on the overall organizational systems and software engineering
maturity by revamping all existing processes to reflect a unified approach,
possibly with CMMI Level 3 as a stretch goal?

From a cursory Venn diagram approach, the CMMI-SE/SW is wholly contained in
the CMMI-SE/SW/IPPD superset, adding only the Level 3 PAs Integrated Teaming
(PA 170) and Organizational Environment for Integration (PA 169). The
CMMI-SE/SW/IPPD representation is then wholly contained in the supplier
sourcing superset, CMMI-SE/SW/IPPD/SS, which adds only the Level 3 PA
Integrated Supplier Management (PA 168). From a flat-weighted analysis,
CMMI-SE/SW (22 PAs) covers 91.67% of CMMI-SE/SW/IPPD (24 PAs) and 88% of
CMMI-SE/SW/IPPD/SS (25 PAs). From just a lexical analysis, though, the
Integrated Product and Process Development (IPPD) representation involved a
great deal more inter-group coordination and melding the systems and
software engineering disciplines than the previous maturity models
envisioned or intended. Implementing a "self managed and empowered"
Integrated Program Team (IPT) as detailed in the model description would
require a significant resource commitment for co-located business, systems,
and software organizations, but could severely tax the bottom line for those
large, geographically distributed organizations, particularly if "customers,
suppliers, and other stakeholders outside of the organization as
appropriate" were included in the team composition as suggested in PA
170.N101.

Bob Robinson

-----------------------------------------

From:  "mr_hoff" <mr_hoff@...>  Date:  Fri Jun 28, 2002  10:10 am
Subject:  My Hello

**** I'm currently on a team that is leading a process improvement effort
that includes SW-CMM, CMMI, ISO 9000:2000, Lean  Enterprise, and a few
internal initiatives.

We're struggling with issues such as, "How do we architect our processes to
meet all of the requirements?", "How do we pursue Level 4 for software and
Level 2/3 for everyone else?", and "Just what does  IPPD mean?"

I'd like to hear any suggestions or experience folks have!

Bill Dickerhoff

I would concur that the SEIR is an invaluable source of background
knowledge. I have a platinum membership there, obtained by submitting
material to be posted on the site, and routinely use the search facilities
there to query both their resources and those on the main SEI site. Any
articles or dead link notifications that I have posted there have resulted
in a prompt response and affirmation from Michael Zuccher at the site. My
only (minor) complaint with SEIR is with the data latency, since as a
general purpose community-supported repository, substantial blocks of time
(months) may elapse before "late-breaking" data is contributed and the site
updated. The SEIR, in addition to the Software Productivity Consortion for
member companies, is still one of the best consolidated sources of process
improvement information on the Internet. Some of the articles posted in
Files section of this group were doubtless filtered from the vast bodies of
knowledge at the SEIR and SPC.

The purpose of this site is moderated discussion of CMMI and other process
improvement issues, with relatively real-time response from the
membership-at-large, which includes some experts in the process improvement
field and others who hopefully have encountered process improvement
obstacles and devised ingenious ways to use their organizational resources
to handle these obstructions and increase their individual and aggregate
process discipline. This group, like other web-based discussion groups,
attempts to provide peer-to-peer assistance for specific issues raised by
the membership. It is not intended as a replacement for any other entity,
nor to duplicate the functionality of the SEIR or any other existing process
improvement body. A discussion group such as this one only functions when
there is interactive dialogue between the participants. If you have
questions, please ask them; if you have encountered and overcome process
improvement roadblocks the same or similar to those raised in the questions,
attempt to help others facing the same issues. If you need process
improvement in a nutshell, try Mark Paulk's proverbs at

http://www.stsc.hill.af.mil/CrossTalk/1997/jan/proverbs.asp

Bob Robinson
CMMI Process Improvement Moderator

--- hugbug2534 <swimmother@...> wrote:
> To: cmmi_process_improvement@yahoogroups.com
> From: "hugbug2534" <swimmother@...>
> Date: Tue, 02 Jul 2002 11:48:15 -0000
> Subject: [cmmi_process_improvement] SEIR
>
Hello,

What is the difference between this discussion group and information and the
Software Engineering Institute's Repository. They have lots of links and
information there.

http://seir.sei.cmu.edu/

They have a section entitled 'Ask the Group' plus they have lots of
presentations; It is also free but you must register just like this one. Is
it simply people don't know the other one exists?

Just not sure why we are duplicating work here when the SEIR has been in
existence for some time.


To unsubscribe from this group, send an email to:
cmmi_process_improvement-unsubscribe@yahoogroups.com

</tt>



<tt>Your use of Yahoo! Groups is subject to the <a
href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of
Service</a>.</tt>
</br>

</body></html>



=====
Bob Robinson

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Hello,

What is the difference between this discussion group and information
and the Software Engineering Institute's Repository.  They have lots
of links and information there.

http://seir.sei.cmu.edu/

They have a section entitled 'Ask the Group' plus they have lots of
presentations.  It is also free but you must register just like this
one.  Is it simply people don't know the other one exists?

Just not sure why we are duplicating work here when the SEIR has been
in existence for some time.

I recently added a new Cost Estimation folder to the Files area of this
group (http://groups.yahoo.com/group/cmmi_process_improvement/files/),
containing papers on the University of Southern California COCOMO II tool,
Galorath commercial SEER-SEM tool (with parameter and scope comparisons to
COCOMO), and the East Tennessee State University COSMOS tool. Since
historical cost collection and analysis for estimation of future software
production costs is a critical component in fulfilling the CMMI process area
disciplines, selection of the most appropriate tool (or tools) for your
organization is key to procuring new business by obtaining accurate job
estimates.

One of the discriminating factors in tool choice is the core metric used for
measuring basic software practitioner productivity. Although the choice of
Function Points (FPs) or Source Lines of Code (SLOCs) is often driven by
program or organizational directives, both have advantages and shortfalls as
productivity measures. The difficulty in universally applying FP techniques
to obtain consistent scalar results, along with the shrouded authenticity
induced by IFPUG proprietary rules and the gray area accompanying the use of
backfiring for entry into COCOMO, point to the unsuitability of Function
Points as a sole measure of productivity. Conversely, SLOCs are of little
use in measuring the effort required to build a product using graphical
languages, 4GL code generators, or web implementations. Neither SLOCs nor
FPs are ideal for estimating the effort involved in
re-architecting/re-engineering or maintenance life-cycles, where the net
effect of a fairly extensive effort would show negligible impact on FPs
(provided the internal and external interfaces were not impacted) and may in
fact show a reduction in source code size due to increased efficiency and
elimination of dead code.

What are the group experiences in specifying a meaningful expression of
software practitioner productivity in these or other difficult-to-gauge
software labor activities? Short of relying on IFPUG to resolve any FP-based
contract management issues, what are peer-to-peer techniques for assuring
that all stakeholders operate from the same set of assumptions and weighting
factors?

Bob Robinson
CMMI Process Improvement Group Moderator

well....glad to have it.  will keep in touch with you all....as we
explore cmmi from now until who knows.

bill deibler
www.ssqc.com

Hi,

I work for Networl Solutions Ltd. We at NetSol do dont
have any processes in place, However the company has
decided to put all the processes in place and go in
for a CMMI Level III assessment. I have been given the
responsibility to coordinate these activities.
I request your guidence on this, there are a few
things I need to how...
1. How do I initiate the entire Process? What would
the the first step?
2. How are the people who would get involved in
drawing up the processes?
3. Who are the people who would be involved in
implementation and coordination?
4. How do we determine if we are on the right path?

Please let me know is there are any typical road maps
available.

Regards,
Krishna S P

=====
Krishna S P

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Hello folks,

Our friendly moderator, Bob, inviting me to join this discussion
group.  I'm currently on a team that is leading a process improcess
improvement effort that includes SW-CMM, CMMI, ISO 9000:2000, Lean
Enterprise, and a few internal initiatives.

We're struggling with issues such as, "How do we architect our
processes to meet all of the requirements?", "How do we pursue Level
4 for software and Level 2/3 for everyone else?", and "Just what does
IPPD mean?"

I'd like to hear any suggestions or experience folks have!

Bill Dickerhoff

I am a new member of this group, so if I cover old ground, please be
patient.  I do software metrics and I understand CMM.  However, I run into
the following situation on a regular basis.  I am asking how you handle it.

"So you're CMM5, so what?  How will that solve my sales, inventory,
distribution or capital problems?  How do I know if I am understaffed,
overstaffed or properly staffed?  Why should I pursue CMM if I am pursing
CRM or Six-Sigma?  Which companies in the US are at which levels...?"

hello all
I am currently working on customization of the CMM to be applied in a
academic environment

a lot of things have been done and am working on putting them together to
form a sub-framework

any body having any previous exp. / info on the same may please convey,
that will increase my exposure also
thanks and greetings in advance

reply,

Prof. Mangesh Bedekar
Lecturer, Computer Department
K. K. Wagh College of Engineering
(University of Pune), Amrutdham,
Nashik, M.S. PIN - 422 003 INDIA

Welcome to all the new CMMI Process Improvement group members.
Hopefully the synergy produced by the individual contributions and
group interactions will be beneficial to process improvement efforts,
both in your personal productivity and in your working environment.
If you haven't already browsed the Files area, along with the Bookmarks,
please explore both. Recently added to the Files area is an Excel spreadsheet
which maps the SW-CMM v1.1, ISO 9001:2000, and EIA/IS 731 software and
systems engineering process improvement frameworks to CMMI v1.1
on a paragraph-by-paragraph basis.

Post your questions and responses directly from the site, or send
messages to cmmi_process_improvement@yahoogroups.com. Do not send
irrelevant advertisements, since this is not a forum for SPAM, and many
people consider this type material annoying. Any such material will be
filtered by the moderator to prevent widespread distribution to the
members, and continued abuse could result in membership termination.

Again, thanks for joining the group and please contribute any materials
or links that you have found particularly effective in your CMMI
deployment efforts. If you questions about this integrated systems and
software process improvement paradigm, please post them, since others
are very likely facing the same issues.

Bob Robinson
CMMI Process Improvement Group Moderator

Hi Members,

Let us thank BOB first for creating this yahoo group.

I work as a Quality Analyst, in India.

I would like to know the names of those companies who are assessed at
any level of CMMI.

Looking forward to hear from all,

Ram