I subscribed to a CMMi mailing list in September, and have generally ignored it since (due largely to Hotmail’s inability to munch Subject lines in it’s filtering). I’m going to try and process the ~ 1300 messages that have backup up. Things of interest will be recorded.

Day 1…

  • Tailoring
    • Possible for
      • Template level
      • Organization standard process workflow
      • Process flow
      • Process flow artifacts
      • Life cycle model and related artifacts
      • Checklist
    • Not possible for
      • To a complete process area without appropriate justification
      • On roles of PM, SM, SQA, senior mgmt
      • On metrics beyond the scope of PCB
      • As an alternative for lack of resources
    • “Tailoring” is used to describe not only what the CMMi allows, but what the projects demand
    • Tailoring stands for having the deviation from organization defined process. For example your organization would have defined a template for software design, where as client wants in different format as per his requirement, here the client defined template will be tailored to your organization process / template. Same thing applies to all process/format/template etc.
  • Process
    • Behaviour currently exhibited by the org to accomplish work
    • Process: defined set of work in terms of activity sequence, for long-term objectives. Process requires collaboration from multiple roles (even from multiple departmental groups). Normally, process are broken into stages and each stage is closely controlled by a primary role. Examples: Project risk management process, Recruitment process, software requirement development process
  • Process definition/description – written/graphical representation of the process. The ‘desired’ way
  • Process area – a grouping in cmmi context of a group of practices
  • Having code standards helps with LOC estimates
  • Baseline – frozen work product accepted by the client
  • Good analogy for Maturity Levels (ML): Think of ML2 as triage – stabilizing the patient so that they can be treated; think of ML3 as the treatment. (Think of ML4 as wiring up the patient to really understand what is going on, and ML5 as preventative medicine). ML2 is the means by which we pull the man to shore; ML3 is giving him swimming lessons.
  • Procedure – The nature is almost similar to ‘process’, but for a short-term purpose (usually to realize a certain work product). Procedure requires only few roles – which are normally in the same departmental group. Examples: code inspection procedure, job interview procedure, restricted area access procedure, etc.
  • Activity – defined actions to be performed in a process/ procedure. An activity may involve more than one tasks to complete.
  • Work Instruction – detailed instruction to conduct an activity, usually by an individual role.
  • Task – individual action that is planned to fulfil an activity
  • PAL – Process Asset Library
  • If a process is seen as “our process” rather than “your process” it will probably encounter much less resistance.
  • Information security management systems. Guidelines for information security risk management
  • Tracability
    • If you have a reasonable trace from meaningful requirements to other meaningful artifacts, you won’t fail the RM or RD areas.
    • Set yourself up to trace only those items that you can trace easily, and where tracing makes sense to your team. Do this for one project or iteration. As you proceed, look at what you might want to change for the next project or iteration.
    • Look to change small things as soon as you see a better way to do them – or as soon as they cost more to do than the value returned.
  • SRS (Software Requirements Specification) Review Check list
    1. Functionality
      • Is the Vision / Purpose of the software to be developed clear?
    2. External Interfaces
      • What are the external interfaces in terms of Users, the system’s hardware, other hardware, other software, etc.?
    3. Performance
      • Were the performance criteria identified?
      • Was the speed, response time, recovery time of various software functions specified?
      • Are both static and dynamic requirements included?
    4. Attributes
      • Were the software attributes like usability, portability, reliability, availability, correctness, maintainability, security, etc. taken into consideration?
      • Has the correct set of requirements attributes been specified?
    5. Design Constraints
      • Are the design constraints addressed?
    6. Boundary Conditions
      • Are the Requirements specified within the bounds of the SRS?
      • Are the Requirement focusing on functional aspects without describing design or implementation details?
      • Are Requirements imposing additional constraints on the software?
      • Does the SRS properly permit a range of valid designs without specifying any particular design?
    7. Unambiguous
      • Does each requirement have one, and only one, interpretation?
      • Whether all every requirements stated in the SRS be mandatorily developed?
      • Has the customer’s language been used?
      • Whether Glossary of terms have been prepared?
      • Have diagrams been used to augment the natural language descriptions?
    8. Complete
      • Does the SRS include all significant requirements, whether related to functionality, performance design constraints, attributes, or external interfaces?
      • Have the expected ranges of input values in all possible scenarios been identified and addressed?
      • Have responses been included to both valid and invalid input values?
      • Have the core requirements been gathered in initial iterations to facilitate design of software architecture? (for Iterative approach)
      • Whether the requirements added during subsequent iterations are consistent with the requirements gathered upto previous iteration? (for Iterative approach)
      • Do all figures, tables and diagrams include full labels and references and definitions of all terms and units of measure?
    9. Consistent
      • Does this SRS agree with the Vision document, the use-case model and the Supplementary Specifications?
      • Does it agree with any other higher level specifications?
      • Is it internally consistent, with no subset of individual requirements described in it in conflict?
    10. Ability to Rank Requirements
      • Has each requirement been tagged with an identifier to indicate either the importance or stability of that particular requirement?
      • Have other significant attributes for properly determining priority been identified?
    11. Verifiable
      • Is every requirement stated in the SRS verifiable?
      • Is it possible to use a cost-effective process to check that the software product meets the requirement?
    12. Modifiable
      • Are the structure and style of the SRS such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style?
      • Has redundancy been identified, minimized and cross-referenced?
    13. Traceable
      • Does each requirement have a clear identifier?
      • Is the origin of each requirement clear?
      • Is backward traceability maintained by explicitly referencing earlier artifacts?
      • Is a reasonable amount of forward traceability maintained to artifacts spawned by the SRS?
      • Are all requirements traceable to the system level specifications?
      • Is requirement tracking done?
      • Is requirement traceability table made?
      • Are requirement specification document and RTT updated as and when requirements tracking done?
    14. Logical Database Requirements
      • “Have all logical requirements been specified for any information that is to be placed into a database? This may include:
        • Types of information used by various functions
        • Frequency of use
        • Accessing capabilities
        • Data entities and their relationships
        • Integrity constraints
        • Data retention requirements
    15. Standard Compliance
      • Have all requirements derived from existing standard and regulations been specified?
      • How will this be traced?
    16. Business Specifications
      • Are all supplementary business definitions and objectives listed in the document general, in the sense that none of them should pertain to one single business use case, business worker, or business entity?
      • Is it clear what the general principles are for how the organization interacts with external people or systems?
      • Is it stated what general objectives there are for speed, availability, response time, recovery time of various functions in the organization?
      • Whether all possible partial and full failure scenarios have been gathered?
      • Whether the boundary conditions of application have been gathered?
      • Have all objectives derived from existing standard and regulations been specified? How will this be traced?
    17. Others
      • Are acceptance criteria completely identified?
      • Are all the problems and requirements in the current system identified (if applicable)?
      • Is the flow and contents of information evaluated?
      • Is input, process and output information defined?
      • Is problem partitioning (functional decomposition) complete?
      • Has prototyping been conducted for the user/customer?
      • Are the requirement specification and the plans baselined?
      • Are requirements reviewed for completeness, feasibility, clarity, consistency and testability?
      • Are impact of change requests on the project plans, deliverables, and schedule identified?