Capability Maturity Model (CMM) using Mutable Patterns


Capability Maturity Model (CMM) using Mutable Patterns

v.070509.1

*
mu·ta·ble (myt-bl)
adj.
1.
a. Capable of or subject to change or alteration.
b. Prone to frequent change; inconstant: mutable weather patterns.
2. Tending to undergo genetic mutation: a mutable organism; a mutable gene.
*

CMM-SPC documentation framework to support and deliver sets of control points at
cycles of software development. How to resolve noun-verb pattern definition from sets
of control-points and shared cycle-time. Resolution and definition can be increased or
decreased to help awareness of reduced-size processes. Keywords: Capability Maturity
Model (CMM), Unified Modeling Language (UML) & Statistical Process Control
(SPC/Six Sigma)
____________________________________________________________

Quality depends on individual employees and that is wonderful if you're an artist like
Rembrandt, but what if the client recognizes operator John's finishing touch only in the
final product? When an organization is unaware that such things can be completed using
standardized methods, standards of process such as Unified Modeling Language,
Capability Maturity Model, Statistical Process Control or building an MS Access
database, the customer should be equipped to envision its own awareness. A framework
of standards that offers smart open-access into the product development processes, thus
formalize and predict by knowledge as the documentation will affect those requirements.

At the early stages of software development each person can know "WHEN" but not
"HOW" the customer requirements can be realized. Awareness before construction and
"think before doing" provided there are skills to envision how the data-imagery model
will resolve what the customer expects in quality.

Quality to improve itself is cyclic and repeatable to run concurrent with other product data
but what does the imagery of process-time to workflow look like?

For example; software development with very little documentation or control point data
looks like three idealistic circles each placed inside the larger circle. Each subsequent circle
represents one key process area of development. The bigger the circle the more time will it
take to resolve development of that circle process. In reality, one should expect things
related to project size to change, requirements gathering, thereby affect the outcome that
should predict the size of a circle. Size of circles and corresponding process time will
depend upon group participation and customer involvement. Product requirements for
example that ride along a process circle however, might share an inverse relationship to the
time it takes to complete the process. Simply put another way if the outline of Antarctica
were sketched across all the circles one could better envision the true nature of processes
and their cycle-time as these tend to rise or fall in accordance to resolving process time at
key areas within those processes. An idealistic circle brings little to light with regards to
resolution and some predictable behavior when each process seeks out a time-line that tells
everyone "when" to envision its final form.

Data collection and control points gathered from Statistical Process Control when
misunderstood often times will not get recorded nor get returned and then placement into
one of the correlated time-slots in the sketch described above. The sketch of Antarctica
depends on the coordinates (process cycle-times are not perfect circles) getting returned.
Just like coordinates work for maps, the pattern control points allow one to envision what
the combined processes will look like.

If the teacher and pupil were one of the same person their joined mutation is self-aware
of one another, an individual on the other hand with unique tasks to perform tend to remain
anonymous and aware only to their own needs. If each person is unaware to the big process
that affects to influence the client & product requirements, chances are the next customer
is too unique as well. Small processes start out slowly to understand the meaning for the
changes taking place. The process of awareness comes in support of the data control points
being returned from key process areas as the pattern takes shape.

Understanding the mutation within the pattern is the real power of software development.

Awareness feeds requirements which lead to improved analysis which define the composition
of the smaller processes and their imagery. Knowledge is based on the fact that everyone can
understand something that someone else performs because each person wants to succeed.
Each person has an open mind-set unto the process imagery. Charts, diagrams and specs-
data are static in terms of their feedback. Each person wants to succeed at their job too.
It becomes an opportunity for upper management to drive and steer the feedback that is
realized from the process imagery, optimal requirements that give each customer an
immediate return on feed-back into real-time process imagery.

Without open-ended process practices, development cycles, and documentation the
organization reverts back to experts to manage and control the processes on behalf of the
customer. Processes might have devices which are hard-wired and fixed for example, PLC's,
& Numerical Control. Requirements, setup, and their programming once up and running, are
fixed and stable albeit repeatable processes. An organization follows suit using equal auspices
that our expert can be called upon to perform the corrective actions when error occurs, this
allows our expert to resolve the action alert using programmed instructions. The expert
performs as expected. With each alert, bell or whistle perhaps the future need will require
the addition of structure to the corrective instructions. Each new alert tends to cast a larger
reflection of the product requirements then what the original requirements had involved.

Expert programming in less rigid domains will require improved resolution of the product
and/or cause for an alert whenever subtle changes occur to similar processes and product.

Expert operator knowledge comes in real handy when putting the finishing touches in the final
product which followed an alert. Prevention of errors on the other hand, is a process which can
be found to follow some rigid control constraints contained with sets of rules to follow. These
rule assumptions serve experts well when the process environment is under rigid control.

When a bell or whistle sounded alert an assumption is the same with any process that's
repeatable, there should be a pattern that matches the behavior of the process that causes it
to repeat. Alerts indicate when a rigid process is broken. The growth of unexpected mutations
during software creation is inevitable.

Process development which seeks to be self-aware with self-help will offer the greatest level
of maturity to the customer granted there is access to the product information. Solving a
process pattern for instance, gathering measurable control points (Statistical Process Control)
in conjunction with the Capability Maturity Model. Awareness of a new mutation has reached
the process pattern that was resolved from a set of measurable control points. Deterministic
assumptions require a web-service framework to increase that resolution from patterns to
execution of similar expert processes.

Mutable patterns in reduced processes open collaboration between people and their applications.
SPC in software development might have a couple points to measure, while repeatable processes
and a single pattern and rigid control like the PLC and CNC, one will find hundreds of points of
measure.

end.


.