Thursday, February 25, 2010

CMMI V1.3 CONSTELLATIONS

Adapted from SEI's V1.3 status presentation...

RD: Requirements Development
RM: Requirements Management
TS: Technical Solution
VAL: Validation
VER: Verification

SSAD: Solicitation &
Supplier
Agreement
Development
ARD: Acquisition
Requirements
Development
ATM: Acquisition
Technical
Management
AM: Agreement
Management
AVAL: Acquisition
Validation
AVER: Acquisition
Verification

SD: Service
Delivery
CAM: Capacity and
Availability
Management
SSD: Service
System
Development
SSM: Service
System
Development
SST: Service
System
Development
SC: Service Continuity
IRP: Incident
Resolution &
Prevention

Wednesday, February 24, 2010

CMMI V1.3 Webcast Notes

Source: Kishore Budde...

-
Changes are mostly based on CRs and the intention was not to raise the bar
- To Bring clarity to High Maturity Practices (finalized version will be ready by end of March or early April)
- Simplify Generic Practices
- Increase Appraisal efficiency
- Improve Commonality across Constellations (Dev, Svc, Acq)
- Officially CMMI v1.3 is expected to be launched by Novemmber 2010
Within the model: (cannot recollect changes to individual PAs at L2 and L3, the speaker was quickly moving between topics due to limited time)
  • We will get to see informative material on Customer Satisfaction ( there was no mention of it in earlier and current versions). However, no specific direct requirement in any PA
  • Elimination of GG4 and GG5 (proposed - final decision is pending with SEIs CCB)
  • Informative material will be added on confusing/dicy to interpret words such as: Process model, Business Objective, Sub Process etc
  • While number of PAs in Level 2,3 and 4 will remain as is, we can expect an additional PA OPM - Organization Process Management at L5 (part of OPP will be here, no additional requirements)
  • SPs in QPM are modified to link them well with CAR
  • 'Common Cause' concept is shifted from L5 to L4
  • We can expect to see informative material on Agile in about 9 PAs (so Agile officially takes its place in CMMI model)
  • Words in GG1 and GP3.2 to be simplified for better understanding
  • Changes V1.2 V1.3
    Pages 560 461
    GP 17 13
    SG 50 48
    SP 173 165
    PA 22 22/23
    GG 3 3

Appraisal related: (Few are listed below. More clarification will be provided on 18th March in a seperate webinar that focusses only for Appraisal tasks)

  • There will just be artifacts and Affirmation (concept of DA and InDA will be eliminated)
  • Expect Minimum Scoping rules
  • First Appraisal based on CMMI V1.3 can be expected in November 2011
  • During the one year sunset period (Nov 2010 - Oct 2011), Organization may chose to go for implementation based on v1.2 or v1.3
  • v1.2 appraisal result taken anytime before October 2011 will be valid for 3 years
  • CMMI v1.3 appraisal rating validity period may be increased (under consideration)
  • SEI plans to bring guidelines for SCAMPI A,B and C in one book. If thats not feasible; changes will be made to B, C handbook to reflect v1.3 changes

Transition & Training related:

  • Transition from v1.2 to v1.3 will first be launched (later v1.1 to v1.3 to be launched). One take online upgrade course to complete this transition
  • Lead Appraisers and Instructors in addition to taking the online course, should attempt and clear a test
  • 3 day Introduction to CMMI SVC will be made available and DEV will become supplement (It is the other way round till now)
  • Training material may not undergo too much of a change
  • Training costs are expected to remain constant
  • SEI looking at conducting 3 day Intro to CMMI SVC training through its partners (will be finalized by SEPG Conf in NA next month)
Note: All the above mentioned pointers are just to give a quick feel on what to expect in CMMI v1.3. Some of them may not see the light of the day and few new surprises can be expected.

Sunday, February 21, 2010

Statistical available tests


Courtesy: Intuitive Biostatistics, Harvey Motulsky. Copyright © 1995 - Oxford University Press Inc.

CMMI V1.3

  1. Kind of stable release compared to the previous versions (software terminology)
  2. Clarifying and modernizing L4 and L5 practices - Increase depth and clarity of CAR and OID practices, Clarifying connection between statistical management of
    subprocesses and project management
  3. Create a lower ML version of CAR as it's felt CAR is valuable at any level of maturity.
  4. Release scheduled for 1st Nov, 2010
  5. Significant overlap in its adoption (v1.2 to v1.3 in an year)
  6. Consistency of practices across constellations - CMMI Dev (22 PAs), CMMI-Acq (22 PAs), CMMI-SVC (23 PAs) presently. Proposed - Common 16 PAs to all, Shared PAs bet'n constellations.
  7. Expanded coverage of model to include Agile, Lean Six Sigma
  8. IPPD will not be optional.
  9. Try to bring down GPs
  10. Appraisal methodology changes to make it more effective
  11. Changes to appraisal methodology so that Dev + SVC can be appraised in a single appraisal - Multiple model implementation...
  12. Reduce offsite effort for appraisals.
  13. REQM going back to PM

Wednesday, February 17, 2010

Unit Testing

What is a Unit Test Plan?


This document describes the Test Plan in other words how the tests will be carried out.

This will typically include the list of things to be Tested, Roles and Responsibilities, prerequisites to begin Testing, Test Environment, Assumptions, what to do after a test is successfully carried out, what to do if test fails, Glossary and so on

What is a Test Case?

Simply put, a Test Case describes exactly how the test should be carried out.

For example the test case may describe a test as follows:
Step 1: Type 10 characters in the Name Field

Step 2: Click on Submit


Test Cases clubbed together form a Test Suite

Test Case Sample


Test Case Test Case Input Expected Result Actual Result Pass/Fail Remarks
ID Description Data

Additionally the following information may also be captured:

a) Unit Name and Version Being tested
b) Tested By

c) Date
d) Test Iteration (One or more iterations of unit testing may be performed)

Steps to Effective Unit Testing:


1) Documentation: Early on document all the Test Cases needed to test your code. A lot of times this task is not given due importance. Document the Test Cases, actual Results when executing the Test Cases, Response Time of the code for each test case. There are several important advantages if the test cases and the actual execution of test cases are well documented.

a. Documenting Test Cases prevents oversight.
b. Documentation clearly indicates the quality of test cases

c. If the code needs to be retested we can be sure that we did not miss anything
d. It provides a level of transparency of what was really tested during unit testing. This is one of the most important aspects.

e. It helps in knowledge transfer in case of employee attrition
f. Sometimes Unit Test Cases can be used to develop test cases for other levels of testing

2) What should be tested when Unit Testing: A lot depends on the type of program or unit that is being created. It could be a screen or a component or a web service. Broadly the following aspects should be considered:

a. For a UI screen include test cases to verify all the screen elements that need to appear on the screens
b. For a UI screen include Test cases to verify the spelling/font/size of all the “labels” or text that appears on the screen

c. Create Test Cases such that every line of code in the unit is tested at least once in a test cycle
d. Create Test Cases such that every condition in case of “conditional statements” is tested once

e. Create Test Cases to test the minimum/maximum range of data that can be entered. For example what is the maximum “amount” that can be entered or the max length of string that can be entered or passed in as a parameter

f. Create Test Cases to verify how various errors are handled
g. Create Test Cases to verify if all the validations are being performed

3) Automate where Necessary: Time pressures/Pressure to get the job done may result in developers cutting corners in unit testing. Sometimes it helps to write scripts, which automate a part of unit testing. This may help ensure that the necessary tests were done and may result in saving time required to perform the tests.

If we already have automation, what's the need for Agents?

“Automation” and “agent” sound similar — but they solve very different classes of problems. Automation = Fixed Instruction → Fixed Outcome ...