IntelConfidential Page 1

SW development process and the “leading indicator”

F2F with Stefan & Pat – ww32’07

SW development process and the “leading indicator”

F2F with Stefan & Pat – ww32’07

Eyal Rozenblat

IntelConfidential Page 2

AbstractAbstract• In the past ~18 month, there is a “process improvement” activity being held in IDC

and especially in CCT-E• It is driven by a w.g., led by Eyal, which reports to ext. staff and get’s it’s approval for

the next step implementation, including new processes that are applied in the department. Moshe Kleyner is the “godfather” for this.

• This work went through the stages of status & needs collection (Q1’06), basis concept approval (Q4’06), pilot implementation approval (Q1’07), presentation to CCT staff (ww18’07 F2F) and eventually Q2’07 pilot, which led to the Q3’07 pilot before wide implementation in the department

• This improvement, of defining a “SW development process” for DTS departments, and the facilitation that supports it, is in full correlation with the task of defining a “leading indicator” for the process quality, asked by Siva

• This presentation is to share the concepts of the process, it’s current implementation, and proposed improved implementation (merging into the MPOR system) to CCT-W process owner (Stefan?) and MPOR system owner (Pat), to get agreement on implementation of it also in CCT-W, and also of building the “leading indicator” for DTS staff

• Note: ASVS DM decided to adopt this as well, but reorg and technical difficulties delayed it’s deployment in ASVS-IDC in Q3’07; will be implemented in Q4’07

• Other departments will follow later, and there is need to make progress gradually, focusing first on CCT-E/W, ASVS and possibly PTM (in that order)

IntelConfidential Page 3

AgendaAgenda

• The process concepts – Q4’06 approval• Presentation to ext. staff – Q1’07 CCT F2F• Pilot postmortem and feedback – EOQ2’07• Extension of the pilot scope to a full blown process and indicator• Merging with the MPOR system proposal

IntelConfidential Page 4

Former work presentationsFormer work presentations

• PVPD Development Process W/G Report –

• CCT-E process w.g. presentation to ext. staff – ww01’07

• CCT-E SW development process - ww18'07 F2F.ppt

• CCT-E SW development process pilot postmortem - ww26'07.ppt

• CCT-E SW development process pilot postmortem - after feedback .ppt

Microsoft PowerPoint Presentation

CCT-E process w.g. at ext. staff - ww01'

CCT-E SW development process pilot postm

CCT-E SW development process pilot postm

CCT ww18'07 F2F

IntelConfidential Page 5

Pilot extension to a full blown processPilot extension to a full blown process

• Dev. process includes several activities (such as requirement specification, code review, etc) that lead to a delivery of a “desired quality”

• Those activities may differ from one dev. item to another, from one team to the other depending of the item complexity, risk, implementer capability, etc

• Hence it needs to be considered and planned on a single dev. item basis - plan which become a commitment of applying these activities

• The consideration of what set of activities suite best an item is totally in the hands of the implementation owner, the PL, subjected to GL review

– DTS dev. item is the MPOR. We’re using the MPOR process / system.

• Those activities yield artifacts which are “work material”, such as an EPS document, test plan document. Reviews are held to assure their quality.

• Therefore the commitment for applying activities, is a commitment for developing those artifacts (and making them available for tracking as part of the process)

• Fulfilling the plan (rather than developing many artifacts) is considered a high quality process; gaps are considered issues in the process execution

• The level of applying the plan, is the essence of the “leading indicator”

IntelConfidential Page 6

Extending “activities” from the first 2Extending “activities” from the first 2

• The original pilot concentrated on two activities and artifacts1. Requirement specification - yielding “EPS”

2. Test planning - yielding a “test plan”

• Additional activities, as can be seen in the V model for example, are3. SW design – yielding an IPS

4. Coding – yielding “code review”

5. Unit testing – yielding “test results” / “unit test scripts”

• Additional activities may be defined by implementation owners as they see fit for them

• Each such activity yields an artifact which can be represented by a file, which is to be available (uploaded) to the system for tracking purposes

IntelConfidential Page 7

Localization / configuration of ones “default process”

Localization / configuration of ones “default process”

• The process / system will be released with those 5 “default” activities / artifacts, making this to be DTS “default process”

• At each level, additional activities / artifacts may be defined as part of the unit process activity, or removed from their “default process”– Example 1: in one department “code review” was defined, but a certain

group “removed” it from their “default process”– Example 2: in one department, new activity was defined, called “test

plan review”. It becomes part of all the subordinates default process, unless removed there

• Once such a definition is done, by whoever in DTS, this definition as an activity, is available for all DTS units, to define as part of their default process

• Thus the result of definition at each level, results in a default process for DTS, ~7 default processes (possibly the same) for DTS departments, few dozens for DTS groups, etc.

• Default process is of course inherited by the organization structure, allowing adaptation to the departments and groups different needs and development style

IntelConfidential Page 8

Default process hierarchical configurationDefault process hierarchical configuration

IntelConfidential Page 9

The planning stage – from “default” to “actual” process

The planning stage – from “default” to “actual” process

• Given a “default process” at some level, at the planning stage, the PL needs to select, per item, weather it will be developed for this specific item or not – By this he/she creates the “actual process” for any given MPOR

item that they committed to deliver– The system will provide the option to select per each item and

each activity “document” or “waiver”– This would typically be another “folder” in the dialog opens for

editing the item – the “dev. process” folder• The existing one may be called “execution” or any other reasonable

name

IntelConfidential Page 10

TrackingTracking

• The system shall track items Vs. their artifacts and give indications– When an item is marked “done” (either MPOR system or

MSProject) this is the time that a missing artifact is considered a violation to the process, and will appear in such a report

– The other report will be of the amount of the already developed artifacts, normalized to %, per each type (% of EPSs, % of IPSs, etc)

– The system shall build a progress line based on the delivery dates, calculating how many items should be developed at each such point

IntelConfidential Page 11

Tracking graphTracking graph

0

100

200

300

400

500

600

700

800

ww01 ww02 ww03 ww04 ww05 ww06 ww07 ww08 ww09 ww10 ww11 ww12 ww13

EPS

IPS

Code review

unit test

test plan

planed total

Actual total

% completion

IntelConfidential Page 12

The indicator calculationThe indicator calculation

• The indicator is of hierarchical nature• It is a simple division of the amount of developed items

(uploaded via he system) by the number of those that need to be done at a given time, by the MPOR commitment.– Say one team needed to do by ww07, 3 EPSs, 2 IPSs, 2 code reviews

and 5 test plans

– All adds up to 12 artifacts

– Say they did 2 EPSs, 1 IPSs, 2 code reviews and 4 test plans – total of 9 artifacts (and uploaded to the system) then they get 9/12 = 75% “grade” of process completion

– The group’s grade, containing this team, is calculated exactly the same, taking into account all the items from all of their teams

• Up to the department level, and up to DTS level!• We’ll probably have some target of 80%-85% desired

completion rate

IntelConfidential Page 13

Next stepNext step

• Q3’07 pilot in CCT-E• Q4’07 pilot / implementation in ASVS-IDC• CCT-W joining ???• ASVS joining after ASVS-IDC stabilizing• Go for merge with MPOR system after Q3’07 pilot

completion (or if Moshe will surprise us)• Eyal writing full specification document – WIP. Will

be sent to participants for review.• Implementation team availability for readiness for

Q4’07?

IntelConfidential Page 14

Q&AQ&A

IntelConfidential Page 15