an alcatel company development processes – what’s new?

AN ALCATEL COMPANY

Development Processes – What’s New?

Development Processes – What’s New?

© 2001 Genesys Telecommunications Laboratories, Inc.

Customer Commitment CharterCustomer Commitment Charter

Alcatel's corporate commitment is to satisfy our customers. In all relationships with customers, Alcatel acts as a single entity and

speaks with one voice, whatever our internal organization. All Company functions contribute to customer satisfaction, even if not

directly connected with our clients. Each and every employee has a responsibility for improving customer

satisfaction. The Company commits to support employees in this goal. We permanently adapt our processes to reduce time to market and to

eliminate non-compliance. Increasing customer value is a key determinant in all Company

decisions. Key account plans are implemented on a regular basis, and customer

satisfaction surveys are published internally. Compliance with these principles is an important element of each

employee's training and performance evaluation.Serge Tchuruk


Requirements Management (1)Requirements Management (1)

How do we determine product requirements?– PM organization provides on behalf of customers– Techniques used to develop and understand: Critical

Requirements Analysis, Task Analysis, Use Cases– Documented in PRD

How are requirements documented and controlled?– PRD published in Digital Library following review (Review

& Approval Procedure)– Scope is negotiated between PM and project team– In scope requirements tracked using the RTM– RTM is baselined in the IPP at Gate 1; current status in

Project Dashboard (in Digital Lib)



How are changes to the requirements managed?– Scope changes are proposed, negotiated, agreed

on, and communicated. Changes to the project scope are reflected in the RTM. (Managing Change Procedure, Project Dashboard)

What types of requirements are specified?– Features/functions, performance/scalability,

usability, serviceability



How do we verify requirements are met?– Requirements are the basis of all downstream work: design,

coding, documentation, test plans, test cases. – State of the requirements are tracked using either Scopus or

the RTM until all in-scope requirements have been verified (test cases passed).

How do we trace requirements through design, code, and test?– RTM contains UID from PRD or FR number from Scopus– UIDs and FR numbers are referenced in Design

documentation and in Freeze Forms (to document implementation)

– Freeze Form version matches the ClearCase label version


Project Planning (1) Project Planning (1)

How do we do project planning?– Project Planning starts following a successful Gate

0 or the project listed as “pending” in the POR– Planning begins with review of the requirements

by the Project Core Team (PCT)– Major planning document is the IPP, which is

reviewed by the PCT and published in the Digital Lib

– Project scope is negotiated between Product Management (there may be multiple PMs) and the rest of the PCT (technique: Critical Requirements Analysis)


Project Planning (2)Project Planning (2)

How do we do Project Planning (continued)– Cost estimates are based on effort estimates; other

costs are added if appropriate (technique: Guru, Delphi, Pert)

– Project risks are identified and ranked according to their probability of occurrence and their impact

– Risk mitigation strategies and contingency plans are identified

– There is a work breakdown structure (WBS) – Identified tasks include time for walkthroughs and

inspections– Detailed schedules are derived using a template,

reviewed by the PCT, and published in the Digital Lib


Project Tracking and Oversight (1)Project Tracking and Oversight (1)

How do we track actual progress to planned progress?– Plans (IPP and detailed schedule) are baselined at Gate 1– Tracking happens at weekly PCT meetings– Actual data is entered into the Project Dashboard– Project metrics are generated using the Project Dashboard– Senior management reviews project status at bi-weekly

Project Status Reviews– Project cost data is entered into the cost tracking system

weekly


Project Tracking and Oversight (2)Project Tracking and Oversight (2)

What corrective actions do we take when actuals deviate from plans?– Project Dashboard calculates degree of deviation– When project metrics deviate from planned,

corrective action is taken– Actions include: reallocation of resources,

renegotiate project scope, modify schedule– Project risks tracked in the Project Dashboard are

examined during the weekly PCT meetings and migration strategies and contingency plans are applied as appropriate


Software Quality Assurance (1)Software Quality Assurance (1)

How do we assure quality is built into the system up front (instead of tested in at the end)?– Every project deliverable listed in the IPP is tested and baselined. Techniques:

walkthroughs, inspections, audits, dynamic testing. Tools: ClearCase, Digital Lib.– All requirements are documented, managed, controlled, and traced (RTM,

Managing Change procedure)– Prototype new technology/markets– Standards: unit test, coding, templates for all project deliverables– Standard process defined in Product Development Handbook (PDH)– Software Quality Management Plan is instantiated in the project IPP– Test Strategy defined in the Test Plan; extensive test cases developed based on

(and traced to) the requirements (RTM)– Practitioners are trained (Review & Approval trained moderator list, SQM & SCM

Auditor list)– Hot Fix root cause analysis– Monthly Quality Reviews identify and track effectiveness of corrective actions



How do we prevent products of questionable quality from being shipped?– Established release criteria – Defect reviews on all non-closed defects with PCT

and Technical Support– Weekly defect trend data reports show “incoming”

rate– Pre-release process for unreleased product

assures the customer knows what he is getting– QA checklist ensures all IPs are sound


Release Criteria (from SQMP)Release Criteria (from SQMP)

Reviews– Inspections – code inspection is mandatory for all new features,

significant changes, and anything considered to be high risk – Walkthroughs – mandatory for all major deliverables as listed in the

IPP Testing

– Unit testing is mandatory for all new features, significant changes, and anything considered to be high risk

– Functional and System Testing have successfully completed– Defect review has been held and all non-closed defects have been

acceptably dispositioned– Requirements Traceability Matrix has been completed– LSST and Performance testing, if specified as mandatory for the

project, have successfully completed– Migration, compatibility, and internationalization testing, if specified

as mandatory for the project, have successfully completed



What processes do we use to ensure that defects do not “escape” into the field?– Early discovery of defects during walkthroughs and

inspections of requirements, design, code, docs, test plans and test cases

– Unit test prior to check in – Products built in a controlled production environment– Defects discovered during dynamic testing are logged and

tracked using our Defect Tracking System (Scopus)– Regularly scheduled defect reviews of all non-closed defects

logged in Scopus, includes Technical Support + PCT



What types of metrics do we collect, how are they used and by whom?– Monthly Quality Reviews by Product Organization Senior

Management (CTO staff):• Hot Fix root cause analysis• Defect trend data (weekly “incoming” rate)• Aging of hot fixes• Ratio of internally vs. externally found defects

– Purposes:• Closed loop corrective action (are the changes in process

effective?)• Release criteria (is the product ready for release?)



Describe our closed-loop corrective action process – both within engineering and between Tech Support and engineering– Hot Fix process (Daily Meeting for escalations)– Standard practice is to log and track defects using Scopus– Defect reviews prior to gate 3 includes Tech Support + PCT

Are we planning compliance with a quality framework?– Pursuing compliance with SEI CMM– Intent to comply with ISO 9001/2000 content – plan due by

end of year 2003


Software Configuration Management (1)Software Configuration Management (1)

How do we manage and control product baselines?– Two repository types: customer deliverables (ClearCase); project-related

deliverables (Digital Lib)– All deliverables are baselined– SCM roles and activities described in the IPP– Items to be kept under SCM identified in IPP– Status of items available: project-related items are either draft or published;

customer deliverables are versioned– Freeze Forms track code changes– Customer deliverables are regression tested following change to ensure no new

defects have been introduced– Production picks up code only from controlled baselines (ClearCase) and builds

IP in a controlled environment– Builds are executed according to a predefined script– IP description file identifies file version, build environment, patch level of the

environment– Archives are kept of everything (our code, third-party software, etc.)



– Branching and merging strategy is specified and implemented

– Tools from the “approved” list are used– Change Control ensures item versions are

updated when changes are approved• Changes are proposed (ER, scope change proposal in

Project Dashboard)• Change is analyzed, discussed, negotiated, and agreed

on with the PCT• Change is applied to all affected deliverables• Change is communicated to all affected parties



How many versions do we have under development at any given time? How do we manage them?– XING Shipping Approval Interface shows the

number of versions– Number of trunks and branches established and

maintained by the project CM Librarian; merge policy applied (fixes into various code streams)

– Maintenance Policy (two major releases concurrently)


Recommended ReadingRecommended Reading

Software Quality Management Plan Software Configuration Management Plan Managing ChangeDigital Lib – Engineering Page – Product Development Handbook – PDP

Project Management Guidelineshttp://genotype.genesyslab.com/xing/dl/retrieve/default.asp?item=B6C52FB62DB42BB229B02755A3DA2E56


Software Quality Management AuditsSoftware Quality Management Audits

Auditor must have gone through this training Name appears in the SQM Auditor list in Digital Lib Auditor is assigned during IPP compilation Audit responsibilities mostly at/around Gate

Reviews The audit is a sample – you don’t look at

everything The auditor “keeps us honest” by providing an

independent look at the project deliverables


Gate 1 SQM AuditGate 1 SQM Audit

PRD published in Digital Lib?– Presence of a Review Item List or other review report

verifies PRD was reviewed– Items on the Review Item List have all been addressed

(verify at least two items) IPP published in Digital Lib? (see PRD sub-items) Project Dashboard has been established in the Digital

Lib Major Cross-Dependencies are listed in the IPP Gate 1 checklist published Attend Gate 1 and provide findings on the above

items



Project Dashboard is up-to-date– Action items logged and tracked– Metrics supplied (schedule, cost, content variance)– RTM is up-to-date (approved changes applied)

• Verify change applied to any affected project work items (i.e., project schedule, design document)

– Project risks are being tracked Test Cases and Test Plan have been published

(verify review as per PRD) Gate 2 checklist published Attend Gate 2 and provide findings on the above

items



Project Dashboard is up-to-date– Actual data for schedule, cost, content – Action items closure– RTM complete

Test Reports exist and show acceptable results Defect Review has been held and metrics available

(number of defects not in pass or pass-warning status for each severity level)

Release Notes contain descriptions of defects not in pass or pass warning state

Gate 3 checklist published Attend the Gate 3 and provide findings on the above

items


Software Configuration Management AuditsSoftware Configuration Management Audits

Auditor must have gone through this training Name appears in the SCM Auditor list in Digital

Lib Auditor is assigned during IPP compilation Audit responsibilities mostly at/around Gate

Reviews The audit is a sample – you don’t look at

everything The auditor “keeps us honest” by providing an

independent look at the project deliverables


SCM Gate 1 AuditSCM Gate 1 Audit

Branching and merging strategy has been established and communicated to the development team

Branching and merging strategy is appropriate to the project (i.e., meets maintenance requirements)

ClearCase repository has been set up for the project (VOBs, branches, views established)

Attend Gate 1 and report findings on the above items



Code freeze label and Freeze Form exist Freeze Form and Scopus are consistent Verify fixes (i.e., hot fixes applied to a

previous version) have been applied according to the branching and merging strategy

Attend Gate 2 and report findings on the above items



Code freeze label and Freeze Form exist Freeze Form and Scopus are consistent Freeze Form and Release Notes are consistent Verify fixes (i.e., hot fixes applied to a previous

version) have been applied according to the branching and merging strategy

End-user documentation has been archived in ClearCase

IP has been verified (and CD if appropriate) Documentation CD and Technical Support

Knowledge Base have been updated Attend Gate 3 and report findings on the above items

an alcatel company development processes – what’s new?

Documents