CAUSAL ANALYSIS AND RESOLUTION SUPPORT (ML5)
The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance.
SG 1 Root causes of selected outcomes are systematically determined.
SP 1.1 Select outcomes for analysis.
SP 1.2 Perform causal analysis of selected outcomes and propose actions to address them.
SG 2 Root causes of selected outcomes are systematically addressed.
SP 2.1 Implement selected action proposals developed in causal analysis.
SP 2.2 Evaluate the effect of implemented actions on process performance.
SP 2.3 Record causal analysis and resolution data for use across projects and the organization.
Source: "CMMI for Development Quick Reference" (available from http://www.sei.cmu.edu)
quinta-feira, 17 de março de 2016
About CMMI-DEV (Concepts)
CMMI-DEV is divided into process areas (definitions below).
First things first:
Main concepts:
There are 22 Process Areas for CMMI-DEV and you can find the full list or process areas here.
Sources:
First things first:
- CMMI-DEV, V1.3 = "CMMI® for Development, Version 1.3" = Improving processes for developing better products and services
Main concepts:
- Process Areas (PA): A cluster of related practices in an area that, when implemented collectively, satitsfies a set of goals considered important for making improvements in that area.
- PA Groups: Support, Project Management, Process Management, Engineering
- Specific Goals (SG): A required model component that describes the unique characteristics that must be present to satisfy a process area.
- Capability Level: Achievement of process improvement within an individual process area; defined by appropriate SG and GG for a PA.
- Specific Practice (SP): An expected model component that is considered important in achieving a specific goal (SG); the specific practices (SPs) describe the activities expected to result in achievement of the SG of that area.
- Generic Goals (GG): A required model component that describes characteristics that must be present to institutionalize processes that implement a process area.
- Institutionalization: The ingrained way of doing business that an organization follows routinely as part of its corporate culture.
- Stakeholder: A group or individual that is affected by or is in some way accountable for the outcome of an undertaking; may include project or work group members, suppliers, customers, end users, and others.
- Relevant Stakeholder: A stakeholder that is identified for involvement in specific activities and is included in a plan.
- Maturity Level (ML): Degree of process improvement across a predefined set of process areas in which goals in the set are attained.
- Process Performance: A measure of results achieved by following a process.
- For a full glossary of terms see [1, 3].
There are 22 Process Areas for CMMI-DEV and you can find the full list or process areas here.
Sources:
- [1] "CMMI-DEV 1.3 - Technical Report", SEI, CMU/SEI-2010-TR-033 / ESC-TR-2010-033, Nov. 2010 (available at http://www.sei.cmu.edu; this is "the bible")
- [2] "CMMI for Development - Guidelines for Process Integration and Product Improvement", 3rd. Ed.; Mary Beth Chrissis, Mike Conrad, Sandy Shrum; Addison-Wesley
- [3] "CMMI for Development Quick Reference" (available from http://www.sei.cmu.edu)
CMMI-DEV Process Areas
CMMI-DEV V1.3 is divided into Process Areas (definitions here).
These are the 22 process areas for CMMI-DEV (in alphabetical order):
Sources:
2016-03-16, initial version
These are the 22 process areas for CMMI-DEV (in alphabetical order):
Sources:
- [1] "CMMI-DEV 1.3 - Technical Report", SEI, CMU/SEI-2010-TR-033 / ESC-TR-2010-033, Nov. 2010 (available at http://www.sei.cmu.edu; this is "the bible")
- [2] "CMMI for Development - Guidelines for Process Integration and Product Improvement", 3rd. Ed.; Mary Beth Chrissis, Mike Conrad, Sandy Shrum; Addison-Wesley
- [3] "CMMI for Development Quick Reference" (available from http://www.sei.cmu.edu)
2016-03-16, initial version
domingo, 13 de março de 2016
Case Study: EXOMARS TGO
What if you were to work for a mission that aims to find life on another planet?
Could you do it from Portugal?
Could you do it using agile methodologies for ESA?
What deliverables were you to deliver to your contractor?
On what language would you have to work on? And on what programming language?
How many time would it take per sattelite module and what statistics would it involve (#reqs to implement, #LOC, etc.)?
Tomorrow (2016-03-14) it's the launch of the first phase of the work of years here at Critical Software. At 9:31 from Casakhistan.
Could you do it from Portugal?
Could you do it using agile methodologies for ESA?
What deliverables were you to deliver to your contractor?
On what language would you have to work on? And on what programming language?
How many time would it take per sattelite module and what statistics would it involve (#reqs to implement, #LOC, etc.)?
Tomorrow (2016-03-14) it's the launch of the first phase of the work of years here at Critical Software. At 9:31 from Casakhistan.
- https://www.theguardian.com/science/2016/mar/13/exomars-giant-nose-life-on-mars-prepares-launch
- https://www.theguardian.com/science/across-the-universe/2016/mar/11/is-there-life-on-mars-exomars-trace-gas-orbiter-takes-up-the-search
Answers on a follow up. One of these days.
sexta-feira, 11 de março de 2016
About Earned-Value Management (EVM)
The topic here is Software Development, but with time you'll learn that a team without management will under-perform (and this is more true for large teams).
Sometimes, if you're a software engineer (or product assurance engineer) you'll be on progress meetings where the project performance is being reviewed and some strange acronyms will start being referred (CPI, SPI, etc.).
Some of these are Earned-Value Management Indicators (EVM Indicators). What are these? Google will tell you. For now I'll just share with you these neat cheat sheets and/or summaries:
There are also good books for a jump start on these topics:
PS. For a description of WISE EVM indicators please read the WISE Project Module Guidebook (INTERNAL). Examples of how they are shown internally to PMs can be seen here (INTERNAL).
PS. EVM is NOT enough for Project Monitoring and Control for certain levels of maturity as required by the Capability Maturity Model (CMMI). We'll need more on our QMS. More on this later on. One of these days.
(2016-05-12: Added book, WISE GBK, screenshot; 2017-05-02: shortened URL, minor rephrases)
Sometimes, if you're a software engineer (or product assurance engineer) you'll be on progress meetings where the project performance is being reviewed and some strange acronyms will start being referred (CPI, SPI, etc.).
Some of these are Earned-Value Management Indicators (EVM Indicators). What are these? Google will tell you. For now I'll just share with you these neat cheat sheets and/or summaries:
- http://www.velopi.com/images/Velopi%20PMP%20Cheat%20Sheet.pdf
- http://www.starpmo.com/downloads/00_PMP_Formulae_CheatSheet_Anil_Tanguturi.pdf
- http://leadinganswers.typepad.com/files/earned-value---one-page-summary-1.pdf
- http://www.cheatography.com/mrsb/cheat-sheets/project-cost-management/
There are also good books for a jump start on these topics:
- Project Management for Dummies (Stanley / Portny): Amazon.
PS. For a description of WISE EVM indicators please read the WISE Project Module Guidebook (INTERNAL). Examples of how they are shown internally to PMs can be seen here (INTERNAL).
PS. EVM is NOT enough for Project Monitoring and Control for certain levels of maturity as required by the Capability Maturity Model (CMMI). We'll need more on our QMS. More on this later on. One of these days.
(2016-05-12: Added book, WISE GBK, screenshot; 2017-05-02: shortened URL, minor rephrases)
sexta-feira, 4 de março de 2016
Milestone meetings and Milestone Reports (Waterfall)
Waterfall uses milestones at the end of phases as a formal moment to mark the closure that phase.
Each milestone meeting has a specific agenda, but typically will involve overviewing the work performed in the current phase, performing a walk-through of some deliverable documents, presenting some statistics on the work thas has been performed, making clear whatever open issues that were still left unclosed and a final special moment where the customer confirms that it's ok to move to the next phase (that statement should be present in the meeting minutes, by the way).
Typically it is a good idea that the QMS has some kind of guide to help the (project) management team as well as the rest of the team preparing the milestone meeting. Here's an example in the format of a "Project Life Cycle Milestone Meetings Guidebook" (internal) :
This NASA document has example TOCs for those reports (and much more):
(2016-05-05: added URL for MM GBK possible TOC)
Milestone Meetings
Every milestone must have milestone meetings. Some milestones have internal meetings as well as the external (i.e. with the customer) meetings. External milestone meetings typically involve several customer stakeholders for a large period of time (half a day, a full day or even more, depending on the agenda and on the complexity of the project). External meetings can involve travel to the customer premises (to Cannes or wherever the customer is located, which could be "nice").Each milestone meeting has a specific agenda, but typically will involve overviewing the work performed in the current phase, performing a walk-through of some deliverable documents, presenting some statistics on the work thas has been performed, making clear whatever open issues that were still left unclosed and a final special moment where the customer confirms that it's ok to move to the next phase (that statement should be present in the meeting minutes, by the way).
Typically it is a good idea that the QMS has some kind of guide to help the (project) management team as well as the rest of the team preparing the milestone meeting. Here's an example in the format of a "Project Life Cycle Milestone Meetings Guidebook" (internal) :
- https://quality.critical.pt/QMS%20PT/MAN-management/MAN-01-project-management/CSW-QMS-2009-GBK-03894-project-milestones-meetings.pdf#search=milestone%20meeting%20gbk
- Details on a possible TOC can be found here.
Milestone Reports
As a result of a successful milestone being achieved, a milestone meeting report is produced (and this is typically the exit criteria of the phases - the existence of an approved milestone review report by the customer).This NASA document has example TOCs for those reports (and much more):
Example of those deliverables are:
- PDR Report (Preliminary Design Review Report)
- CDR Report (Critical Design Review Report)
- QR Report (Qualification Review Report)
- AR Report (Acceptance Review Report)
quinta-feira, 3 de março de 2016
RESOURCE: On Software Development Methodologies
The non-exaustive-use-with-care list of resources on software development methodologies includes some additional information on the waterfall - agile/scrum "recipes" - some of which include variants and/or predecessors of it:
- https://en.wikipedia.org/wiki/Software_development_process - several methodologies listed including FDD, TDD, etc.
- https://en.wikipedia.org/wiki/Software_development_process#Spiral_development - focus on iterative deliveries and risk management as well as planning as explicit parts of the methodology
- https://en.wikipedia.org/wiki/Extreme_programming - unit testing, pair programming, involve the end-customer, stand-up meetings
- https://en.wikipedia.org/wiki/Software_development_process#Agile_development
- https://en.wikipedia.org/wiki/Scrum_(software_development)
Subscrever:
Mensagens (Atom)