View
313
Download
2
Category
Preview:
DESCRIPTION
Citation preview
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
Recommended