Newsgroup: it.discussioni.iso9000
Titolo: ISO9000: Re:432 - ISO12207 vs ISO 1550

21/1/97
Spero sia interessante per tutti ricevere anche l'intero THREAD
sull'argomento ISO 12207  - ISO 15504.
Un saluto  Giovanni Serra   
gse...@mclink.it
I read with interest the justification for why 15504 does not use 12207
literally.However I am not convinced by the argument.
If the framework that we use for establishing processes is not the same as
that used for measuring then we will have difficulty assessing what we
establish.
I do not think that the two-party contract language, i.e.
acquirer-supplier
language,prevents  12207  process definitions being used in 15504. What is
nee-
ded
is that requirements in 12207 are structured into capability levels.
Regards
Jon Fairclough

21/1/97
I read Terry Rout's descriptions and Jon Fairclough's comments with
interest.
In SQJ Vol 5 no. 4 (Dec 96) I propose precisly what Fairclough
suggests, but I link it to the capability levels promised in SPICE.
Can Terry enlighten us about this intriguing menage-a-trois?

21/1/97
Useage :
ISO 12207 : assist company in establishing processes to acquire, supply,
develop, maintain or operate software products.
ISO 15504 : provide a methodology to assess processes in order to
establish the capability of such processes and to assist company to
improve these processes.  ISO 12207 being only one way of establishing
SW processes.
The combinations of ISO 12207, to establish the processes, and ISO
15504, to assess these processes in order to improve them, allows
company to use World Wide recognized International standards or
guidelines and facilitate the communications between Customers,
suppliers and subcontractors that could be spread around the world.  In
addition, ISO 12207 provides more details, on applicable SW processes,
for company wishing or actually working under an ISO 9001 Quality
System.
--
Francois Ouellette
President
LogiQual inc.
1350, rue lacoste
Longueuil (Quebec)
J4G 2J8
Tel : 
(514) 928-7100
Fax : 
(514) 928-8004
E-mail : 
logi...@total.net

24/1/97
   From: Raghu Singh
   ISO/IEC JTC1/SC7 WG7 International Convenor (ISO/IEC 12207)
   1. The "debate" on the two standards and their differences is
   interesting. I read the points raised by Messrs. Terry Rout, Jon
   Fairclough, Alan Jones, and Francois Ouellette.
   Thank you to the SUGaR moderator for inviting me into it.
   2. I agree with Jon and Francois. Since Alan agrees with Jon, I agree
   with Alan as well. I read Terry's paper, but I had difficulty
   understanding it fully. [May be I just got lost in the nuances of the
   English language.]  I will, in the following paras, summarize the basic
   concepts underlying ISO/IEC 12207 and discuss the conflicts that
   typically arise when developing standards such as 12207 and 155504.  I
   wrote a paper on 12207, which was published in Software Process.
   [Thanks, Alec Dorling]
   3. Basic concepts behind 12207.
        12207 covers the full life cycle of a software project (product or
   service); it caters to all the known parties that may be involved
during
   the life cycle at point or another; and it contains the very basic
   management, corporate functions for an organization.
        The life cycle of software is placed within the life cycle of its
   parent system; that is, the necessary system context is provided.
        The life cycle is architectured/framed in terms of a set of five
   "primary" processes, which one may employ to move a software project
   systematically from its cradle to its grave.  [Please note the life
   cycle was not framed in terms of phases, to which many persons were
   found to be allergic.]  These five primary processes are: acquisition,
   supply, development, operation, and maintenance.
        The aforementioned five primary processes are assisted by a set of
   eight supporting processes; each serves several primary processes with
a
   very specific purpose.  The supporting processes are: configuration
   management, documentation, verification, validation, quality assurance,
   joint review, audit, and problem resolution.  [Please note that
   "Evaluation" is not a supporting process; it is an elementary function
   that is conducted within a life cycle process internally, or between
two
   life cycle processes.]
        There is one special process, called Tailoring.  Its purpose is to
   formalize the tailoring of the primary and supporting processes for a
   software project.  This formalization was absolutely necessary to
   instill some sanity to compliance.  I am sure you know "compliance" and
   "tailoring" are not friends!]
        Then there are four organizational processes: management,
   infrastructure, training, and improvement.  These are defined at an
   abstraction level much higher than a primary or supporting process.  An
   organization may employ these four processes to perform at the
corporate
   level -- beyond projects.  The primary processes are specific
   instantiations of the management process!
        For your information, the management process, and, therefore, all
   the primary processes, are based on the Plan-Do-Check-Act cycle.
        Two modes of the application of 12207 in order of decreasing
   preference:
        Mode (1). The organization, please -- institutionalize the 12207's
   life cycle processes you need by establishing relevant [modern]
methods,
   techniques, tools, and environments.  Please do this for both your
   organization and your projects.  To institutionalize the organizational
   processes (especially the improvement), you should employ several
   "tools" available in the discipline, such as the SEI CMM, ISO/IEC
15504,
   et. al.  The other processes may be used to develop
   checklists/questionnaire at a deeper level.  Once institutionalized,
use
   the environment.  Regularly, check the environment against the standard
   and the current best practices.
        Mode (2). For lack of a enviable environment, the parties may use
   the tailored standard directly on a project.
        Before closing on 12207 itself, I want to mention three points
that
   are usually missed or misunderstood.
        Point (1). If I were writing in a programming language, I would
   say: Development Process = Supply Process + Development Process;
   Operation Process = Supply Process + Operation Process; and Maintenance
   Process = Supply Process + Maintenance Process.  In other words, please
   don't execute the development, operation, or maintenance process
without
   attaching/appending it to the Supply Process!  Please see clause
   5.2.5.2.
        Point (2).  Ref: clauses 5.2.4.2 and 5.3.1.1.  5.2.4.2 asks the
   supplier to establish a life cycle model for the project.  A life cycle
   model is NOT a developmental model, but the former may include the
   latter.  The life cycle model would be in terms of all the applicable
   processes, activities, and tasks of the WHOLE standard.  Why?  Because
   the supply, development, operation, and maintenance impact each other.
   Clause 5.3.1.1 asks that the aforementioned life cycle model be fully
   supplemented/elaborated with the applicable activities and tasks of the
   development process.  BIG difference, and very critical to the success
   of any project.
        Point (3). On "contractual language."  This is tough, but I will
   try.  The standard NEVER says that it is primarily intended for
   two-party contracts.  Please see clause 1.2, para 3.  12207 is written
   in the style of contractual language (ie, in declarative).  Writing in
   imperative, interrogative, or exclamatory would create more problems
   than it would solve.  [For example, who would determine which clause
   needs a shall, a will, a should, a may, or a can?  Compliance with the
   standard would be either undefined or random.  Cottage industry folks
   would love non-declarative clauses, though.]  Only the declarative is
   appropriate for all situations: between parties in the same
   organization; between parties in separate organizations; and by an
   organization/person as a self-imposed task.
   4.  Now I will bring in ISO/IEC 15504 (SPICE).  I like SPICE and the
   ideas underlying and usefulness of it.  SPICE can be a valuable tool
for
   organizations.  But when such a tool is not based on a life cycle
   standard, then there is a problem, which may be detrimental more to the
   software discipline itself than to projects and organizations.
        One must "define" the processes that occur in a life cycle before
   one can even attempt to "define" an assessment process.  Otherwise,
what
   are you assessing, against what?  The pertinent assessment
   checklists/questionnaires/procedures must be derived from the life
cycle
   processes.  If an assessment process is not based on standard life
cycle
   processes, at least two things are likely to happen.  Three scenarios.
        Scenario (1): The assessment process does not use any standard
life
   cycle process at all.  The associated assessment instrument would be
too
   generic to be practically useful.
        Scenario (2): The assessment process creates its own life cycle
   processes.  This would inject another life cycle processes standard in
a
   market already crowded with such standards.  Chances are very high that
   an assessment standard would not cover the full spectrum of the life
   cycle.  [Please note that the 12207 effort was very careful not to have
   any clause that could interfere in the engineering and management
   decision making.]
        Scenario (3): The assessment process/instrument is based on
   consensus, standard life cycle processes.  The managers and engineers
   can use the standard life cycle processes to provide products and
   services; the assessment teams can use their assessment instruments;
and
   both would be compatible and measurable.
        I prefer Scenario (3).  12207 and 15504 become complementary
   standards, each serving the communities in its own way.
   5. Thanks for reading the above. Please forgive me for any errors; I
   will not have the time for proof reading.
   Regards,
   Raghu Singh