Loading ...
Sorry, an error occurred while loading the content.

Measurement Repository for MA and for OPD

Expand Messages
  • stathopoulosg
    CMMI Experts: I have been following this group for some time and decided to post a question seeking some help. My question is: What is a measurement
    Message 1 of 6 , Jan 6, 2010
    View Source
    • 0 Attachment
      CMMI Experts:

      I have been following this group for some time and decided to post a question seeking some help. My question is: What is a measurement repository supposed to look like? Specifically, I'd like your collective thoughts on the differences in measurement repositories under MA vs. OPD. My understanding is that a measurement repository with regard to MA is simply a project's collection of measures. The repository design may be a simple document listing other artifacts (i.e. the cost measures are in this spreadsheet, while the test measures are in the bug tracking tool). Furthermore, I don't think that the measurement repository needs to be structured database of all the project's specific measures. This is costly and may not be the best use of resources. Am I on track so far? For the Organization, under OPD, can the Measurement Repository be similar to the project measurement repository design of a central directory of artifacts? I.e. does it have to be an explicit, structured collection of measures in one "database"? Thank you in advance for your feedback - GS.
    • Ebert, Christof
      Good day, A measurement repository is a repository (or storage) used to collect and make available measurement data. Such repository contains or references
      Message 2 of 6 , Jan 6, 2010
      View Source
      • 0 Attachment
        Good day,

        A measurement repository is a repository (or storage) used to collect
        and make available measurement data. Such repository contains or
        references actual measurement data and related information needed to
        understand, analyze and utilize (e.g., for estimations or statistical
        management) the measurement data.

        The requirements to such repository are detailed in ISO/IEC 15939
        (Software Engineering - Software Measurement Process) and CMMI-DEV, MA,
        SP 2.3 (Manage and store measurement data, measurement specifications,
        and analysis results). Some implementation guidance is provided in
        CMMI-DEV, OPD, SP 1.4 (Establish the Organization's Measurement
        Repository). As you point out correctly, the implementation itself is
        not detailed or requested in a specific format by standards or by the
        CMMI. It would be against the basic attitude of such standards to
        require a specific tool, because tools heavily depend on organization,
        distribution, size, complexity of products, etc. However, if your
        engineering and IT need to comply to risk management standards (e.g.,
        SOX), there are more restrictive requirements on accessability, security
        and persistence of measurement data.

        From our practical experience in establishing measurement programs in
        small and large organizations, it is sufficient to start out with a lean
        spreadsheet approach to collect initial measurements and prototype how
        reports, access and user interfaces need to look like. Definitions and
        analysis guidance can be set up with a wiki. Raw data and reports should
        be readily accessible from project and process intranet sites. Never
        keep the repository as isolated files, or measurements won't be used.
        Later on we recommend a central database with intranet access for
        definitions, raw data, reports and analyses, because spreadsheets tend
        to explode and consume overheads for distribution and maintenance.
        Ensure you secure the data both physically and with the right governance
        schemes because it is sensitive in many respect. Avoid dumping too much
        data in such repository. A measurement repository is not a data
        cemetary!

        For more information on measurement and the underlying processes and
        tools check the book: Software Measurement. Springer, ISBN
        9783540716488, New York, 2007, URL:
        http://www.amazon.com/gp/product/3540716483
        It is a good hands-on starting point with necessary measurement
        foundations, best practices, many industry case studies, measurement
        examples, and benchmarks both for IT and engineering organizations.

        best regards
        -Christof Ebert
        http://www.vector.com/consulting
        http://www.linkedin.com/in/christofebert

        -----Original Message-----
        From: cmmi_process_improvement@yahoogroups.com
        [mailto:cmmi_process_improvement@yahoogroups.com] On Behalf Of
        stathopoulosg
        Sent: Wednesday, January 06, 2010 11:21 PM
        To: cmmi_process_improvement@yahoogroups.com
        Subject: [CMMi Process Improvement] Measurement Repository for MA and
        for OPD



        CMMI Experts:

        I have been following this group for some time and decided to post a
        question seeking some help. My question is: What is a measurement
        repository supposed to look like? Specifically, I'd like your collective
        thoughts on the differences in measurement repositories under MA vs.
        OPD. My understanding is that a measurement repository with regard to MA
        is simply a project's collection of measures. The repository design may
        be a simple document listing other artifacts (i.e. the cost measures are
        in this spreadsheet, while the test measures are in the bug tracking
        tool). Furthermore, I don't think that the measurement repository needs
        to be structured database of all the project's specific measures. This
        is costly and may not be the best use of resources. Am I on track so
        far? For the Organization, under OPD, can the Measurement Repository be
        similar to the project measurement repository design of a central
        directory of artifacts? I.e. does it have to be an explicit, stru!
        ctured collection of measures in one "database"? Thank you in advance
        for your feedback - GS.
      • EDWARD F WELLER III
        I might add one point to Christof s excellent post - assumptions and rationale for estimates and other significant events affecting the project should be
        Message 3 of 6 , Jan 6, 2010
        View Source
        • 0 Attachment
          I might add one point to Christof's excellent post - assumptions and rationale for estimates and other significant events affecting the project should be available in the repository.
           
          A case in point - I was reviewing a project and was unable to understand why the estimates doubled at the "low level design" re-estimate. After following a trail through multiple people someone finally mentioned that parts of a cancelled project were added to the one I was looking at. There was no way to understand from the data in the repository that the re-estimate was not a correction of an earlier error in estimating.
           
          Knowing why the data is the way it is is as important as the data itself.
           
          Ed
        • Bruce R. Duncil
          Hi GS, As you have found, there are any number of pre-cut, ready-to-install solutions for sale or otherwise that may or may not solve your specific business
          Message 4 of 6 , Jan 7, 2010
          View Source
          • 0 Attachment
            Hi GS,
            As you have found, there are any number of pre-cut, ready-to-install
            solutions for sale or otherwise that may or may not solve your
            specific business problem.

            An organization aspiring to Level 2, especially Level 3, maturity
            should be becoming more adept at taking customer requirements and
            delivering quality products on-time and on-budget. Why not take the
            opportunity to apply that same approach to successfully addressing
            this (internal) customer need?

            Who are the customers and end-users of your data, its analysis,
            reports and subsequent actions? What are their needs? What data? What
            kind of information management system will support them and fulfill
            those needs? What is it's design? How would you develop it? By when?
            At what cost? How will it be operated and used? And how will you know
            whether it's successful?

            What is it you are really trying to accomplish in the first place?

            By all means leverage the success of others and current technology.
            But I recommend you do it in a way that is commensurate with your
            aspiring capabilities. Besides, in doing so, you will have
            demonstrated that you are also capable of satisfying the goals of
            many of the other CMMI process areas. Simply installing a tool and
            calling the job done would lead me toward the opposite conclusion.

            Hope this is helpful to you.
            Bruce
            www.alderonconsulting.com



            At 05:20 PM 1/6/2010, you wrote:
            >
            >
            >CMMI Experts:
            >
            >I have been following this group for some time and decided to post a
            >question seeking some help. My question is: What is a measurement
            >repository supposed to look like? Specifically, I'd like your
            >collective thoughts on the differences in measurement repositories
            >under MA vs. OPD. My understanding is that a measurement repository
            >with regard to MA is simply a project's collection of measures. The
            >repository design may be a simple document listing other artifacts
            >(i.e. the cost measures are in this spreadsheet, while the test
            >measures are in the bug tracking tool). Furthermore, I don't think
            >that the measurement repository needs to be structured database of
            >all the project's specific measures. This is costly and may not be
            >the best use of resources. Am I on track so far? For the
            >Organization, under OPD, can the Measurement Repository be similar
            >to the project measurement repository design of a central directory
            >of artifacts? I.e. does it have to be an explicit, structured
            >collection of measures in one "database"? Thank you in advance for
            >your feedback - GS.
          • Peter
            One point to add to Christof s response. The focus of MA is to understand what measurements are useful and how they will be collected, analysed and stored. The
            Message 5 of 6 , Jan 8, 2010
            View Source
            • 0 Attachment
              One point to add to Christof's response. The focus of MA is to understand what measurements are useful and how they will be collected, analysed and stored. The focus within the ML3 process areas is the access and usage of these data. Now that you have them, how can they be accessed and used most effectively to estimate, plan and manage projects? Thus, the collection of data in MA is the main focus point, while the availability of these data is critical in the measurement repository.

              Peter.
              www.qpit.ltd.uk


              --- In cmmi_process_improvement@yahoogroups.com, "Ebert, Christof" <christof.ebert@...> wrote:
              >
              >
              > Good day,
              >
              > A measurement repository is a repository (or storage) used to collect
              > and make available measurement data. Such repository contains or
              > references actual measurement data and related information needed to
              > understand, analyze and utilize (e.g., for estimations or statistical
              > management) the measurement data.
              >
              > The requirements to such repository are detailed in ISO/IEC 15939
              > (Software Engineering - Software Measurement Process) and CMMI-DEV, MA,
              > SP 2.3 (Manage and store measurement data, measurement specifications,
              > and analysis results). Some implementation guidance is provided in
              > CMMI-DEV, OPD, SP 1.4 (Establish the Organization's Measurement
              > Repository). As you point out correctly, the implementation itself is
              > not detailed or requested in a specific format by standards or by the
              > CMMI. It would be against the basic attitude of such standards to
              > require a specific tool, because tools heavily depend on organization,
              > distribution, size, complexity of products, etc. However, if your
              > engineering and IT need to comply to risk management standards (e.g.,
              > SOX), there are more restrictive requirements on accessability, security
              > and persistence of measurement data.
              >
              > From our practical experience in establishing measurement programs in
              > small and large organizations, it is sufficient to start out with a lean
              > spreadsheet approach to collect initial measurements and prototype how
              > reports, access and user interfaces need to look like. Definitions and
              > analysis guidance can be set up with a wiki. Raw data and reports should
              > be readily accessible from project and process intranet sites. Never
              > keep the repository as isolated files, or measurements won't be used.
              > Later on we recommend a central database with intranet access for
              > definitions, raw data, reports and analyses, because spreadsheets tend
              > to explode and consume overheads for distribution and maintenance.
              > Ensure you secure the data both physically and with the right governance
              > schemes because it is sensitive in many respect. Avoid dumping too much
              > data in such repository. A measurement repository is not a data
              > cemetary!
              >
              > For more information on measurement and the underlying processes and
              > tools check the book: Software Measurement. Springer, ISBN
              > 9783540716488, New York, 2007, URL:
              > http://www.amazon.com/gp/product/3540716483
              > It is a good hands-on starting point with necessary measurement
              > foundations, best practices, many industry case studies, measurement
              > examples, and benchmarks both for IT and engineering organizations.
              >
              > best regards
              > -Christof Ebert
              > http://www.vector.com/consulting
              > http://www.linkedin.com/in/christofebert
              >
              > -----Original Message-----
              > From: cmmi_process_improvement@yahoogroups.com
              > [mailto:cmmi_process_improvement@yahoogroups.com] On Behalf Of
              > stathopoulosg
              > Sent: Wednesday, January 06, 2010 11:21 PM
              > To: cmmi_process_improvement@yahoogroups.com
              > Subject: [CMMi Process Improvement] Measurement Repository for MA and
              > for OPD
              >
              >
              >
              > CMMI Experts:
              >
              > I have been following this group for some time and decided to post a
              > question seeking some help. My question is: What is a measurement
              > repository supposed to look like? Specifically, I'd like your collective
              > thoughts on the differences in measurement repositories under MA vs.
              > OPD. My understanding is that a measurement repository with regard to MA
              > is simply a project's collection of measures. The repository design may
              > be a simple document listing other artifacts (i.e. the cost measures are
              > in this spreadsheet, while the test measures are in the bug tracking
              > tool). Furthermore, I don't think that the measurement repository needs
              > to be structured database of all the project's specific measures. This
              > is costly and may not be the best use of resources. Am I on track so
              > far? For the Organization, under OPD, can the Measurement Repository be
              > similar to the project measurement repository design of a central
              > directory of artifacts? I.e. does it have to be an explicit, stru!
              > ctured collection of measures in one "database"? Thank you in advance
              > for your feedback - GS.
              >
            • Bruce R. Duncil
              And then back to the original question: What is a measurement repository supposed to look like? Hello again, GS - The term measurement repository is a
              Message 6 of 6 , Jan 8, 2010
              View Source
              • 0 Attachment
                And then back to the original question: "What is
                a measurement repository supposed to look like?"

                Hello again, GS -
                The term 'measurement repository' is a generic
                phrase within CMMI used to describe where your
                organization and project data are housed. There
                are no prescriptive requirements as to its
                function, content, structure, location, or method
                of operation. A mature "repository" can and often
                does include multiple systems and/or system
                components and interfaces over a variety of
                technology platforms and tools. Only your company can answer those questions.

                As I mentioned, there are many off-the-shelf
                tools that likely will NOT, especially
                collectively, solve your business problem, even
                with extensive modification and installation actions.

                The focus of MA is that you define your
                information needs and the measures that will
                address them, and provide for the collection and
                analysis methods, and then that you collect,
                analyze, store and communicate those measures and
                analysis. The focus of OPD is that you establish
                and maintain a repository (one or more systems)
                as an asset to support your projects' and
                organizational data, information and knowledge requirements.

                Thinking of an "MA repository" as simply a
                collection of project measures is potentially
                short-sighted, although it may suffice for some
                very limited purposes. Similarly, trying to use
                in a Level 3 setting an over-simplified structure
                that may work for limited Level 2 maturity can be
                disastrous. Thinking in terms of an "MA"
                repository and a separate "OPD" repository - one
                or more potentially duplicative or redundant
                systems that are "process area focused" - can be
                extraordinarily self-limiting. This may also lead
                you to having to scrap your MA/Level 2 repository
                and start completely over building your OPD/L3
                repository. Use the principles in DAR to make the
                decision among alternatives based on your best
                criteria, not based on what's too hard for some.

                Consider your needs for collecting and managing
                project data (e.g., from PP and PMC), process
                data (from PPQA, OPF, GP 2.8, GP 2.9, GP 3.2,
                etc.), and product quality data (from REQM, PPQA,
                CM, GP 2.9, etc.) as well as organizational data
                (from OPF, OPD, OT, DAR, GP 3.2, etc.). But
                don't forget about business and customer data,
                product data, and all the other myriad
                information and knowledge requirements associated
                with operating a successful business. Then I
                suggest re-reading my previous post if you really
                want to get started working to achieve your business goals.

                Best Regards,
                Bruce
                www.alderonconsulting.com








                At 07:57 AM 1/8/2010, you wrote:
                >
                >
                >One point to add to Christof's response. The
                >focus of MA is to understand what measurements
                >are useful and how they will be collected,
                >analysed and stored. The focus within the ML3
                >process areas is the access and usage of these
                >data. Now that you have them, how can they be
                >accessed and used most effectively to estimate,
                >plan and manage projects? Thus, the collection
                >of data in MA is the main focus point, while the
                >availability of these data is critical in the measurement repository.
                >
                >Peter.
                >www.qpit.ltd.uk
                >
                >--- In
                ><mailto:cmmi_process_improvement%40yahoogroups.com>cmmi_process_improvement@yahoogroups.com,
                >"Ebert, Christof" <christof.ebert@...> wrote:
                > >
                > >
                > > Good day,
                > >
                > > A measurement repository is a repository (or storage) used to collect
                > > and make available measurement data. Such repository contains or
                > > references actual measurement data and related information needed to
                > > understand, analyze and utilize (e.g., for estimations or statistical
                > > management) the measurement data.
                > >
                > > The requirements to such repository are detailed in ISO/IEC 15939
                > > (Software Engineering - Software Measurement Process) and CMMI-DEV, MA,
                > > SP 2.3 (Manage and store measurement data, measurement specifications,
                > > and analysis results). Some implementation guidance is provided in
                > > CMMI-DEV, OPD, SP 1.4 (Establish the Organization's Measurement
                > > Repository). As you point out correctly, the implementation itself is
                > > not detailed or requested in a specific format by standards or by the
                > > CMMI. It would be against the basic attitude of such standards to
                > > require a specific tool, because tools heavily depend on organization,
                > > distribution, size, complexity of products, etc. However, if your
                > > engineering and IT need to comply to risk management standards (e.g.,
                > > SOX), there are more restrictive requirements on accessability, security
                > > and persistence of measurement data.
                > >
                > > From our practical experience in establishing measurement programs in
                > > small and large organizations, it is sufficient to start out with a lean
                > > spreadsheet approach to collect initial measurements and prototype how
                > > reports, access and user interfaces need to look like. Definitions and
                > > analysis guidance can be set up with a wiki. Raw data and reports should
                > > be readily accessible from project and process intranet sites. Never
                > > keep the repository as isolated files, or measurements won't be used.
                > > Later on we recommend a central database with intranet access for
                > > definitions, raw data, reports and analyses, because spreadsheets tend
                > > to explode and consume overheads for distribution and maintenance.
                > > Ensure you secure the data both physically and with the right governance
                > > schemes because it is sensitive in many respect. Avoid dumping too much
                > > data in such repository. A measurement repository is not a data
                > > cemetary!
                > >
                > > For more information on measurement and the underlying processes and
                > > tools check the book: Software Measurement. Springer, ISBN
                > > 9783540716488, New York, 2007, URL:
                > >
                > <http://www.amazon.com/gp/product/3540716483>http://www.amazon.com/gp/product/3540716483
                > > It is a good hands-on starting point with necessary measurement
                > > foundations, best practices, many industry case studies, measurement
                > > examples, and benchmarks both for IT and engineering organizations.
                > >
                > > best regards
                > > -Christof Ebert
                > > <http://www.vector.com/consulting>http://www.vector.com/consulting
                > > http://www.linkedin.com/in/christofebert
                > >
                > > -----Original Message-----
                > > From:
                > <mailto:cmmi_process_improvement%40yahoogroups.com>cmmi_process_improvement@yahoogroups.com
                > > [mailto:cmmi_process_improvement@yahoogroups.com] On Behalf Of
                > > stathopoulosg
                > > Sent: Wednesday, January 06, 2010 11:21 PM
                > > To:
                > <mailto:cmmi_process_improvement%40yahoogroups.com>cmmi_process_improvement@yahoogroups.com
                > > Subject: [CMMi Process Improvement] Measurement Repository for MA and
                > > for OPD
                > >
                > >
                > >
                > > CMMI Experts:
                > >
                > > I have been following this group for some time and decided to post a
                > > question seeking some help. My question is: What is a measurement
                > > repository supposed to look like? Specifically, I'd like your collective
                > > thoughts on the differences in measurement repositories under MA vs.
                > > OPD. My understanding is that a measurement repository with regard to MA
                > > is simply a project's collection of measures. The repository design may
                > > be a simple document listing other artifacts (i.e. the cost measures are
                > > in this spreadsheet, while the test measures are in the bug tracking
                > > tool). Furthermore, I don't think that the measurement repository needs
                > > to be structured database of all the project's specific measures. This
                > > is costly and may not be the best use of resources. Am I on track so
                > > far? For the Organization, under OPD, can the Measurement Repository be
                > > similar to the project measurement repository design of a central
                > > directory of artifacts? I.e. does it have to be an explicit, stru!
                > > ctured collection of measures in one "database"? Thank you in advance
                > > for your feedback - GS.
                > >
                >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.