DEC TP WORKcenter: A Software Process Case Study. Ernesto Guerrieri and Bruce J. Taylor ABSTRACT

Transcription

1 DEC TP WORKcenter: A Sftware Prcess Case Study by Ernest Guerrieri and Bruce J. Taylr ABSTRACT DEC TP WORKcenter is Digital's bject-based prductin system develpment envirnment fr Applicatin Cntrl and Management System TP applicatins. Gals fr the DEC TP WORKcenter prject were t meet custmers' requirements, t prvide superir prduct quality, and t maintain schedule predictability. Mdern sftware prcess techniques helped t achieve an apprpriate balance in reslving the inevitable cnflicts between prject gals. A critical analysis f each sftware prcess shws its effect n the engineering team, the prduct, and the prject schedule. Changes t the prcess were implemented based n the team's experience and quality metrics. Recmmendatins t ther prject teams are ffered based n the cnclusins drawn frm the DEC TP WORKcenter prject. INTRODUCTION The DEC TP WORKcenter prduct is an interactive prductin system applicatin develpment envirnment specifically custmized fr Applicatin Cntrl and Management System (ACMS) transactin prcessing (TP) applicatins.[1] Develpment f the DEC TP WORKcenter bject-based develpment envirnment started in 1991 in respnse t requests frm a number f Digital's ACMS custmers. They wanted a tl that culd help them t Perfrm cnfiguratin management f ACMS applicatin cmpnents Track ACMS applicatin cmpnents Obtain a mre efficient build mechanism fr ACMS applicatins The prduct develpment team cnsisted f a team leader, an architect, six sftware engineers, a quality engineer, tw test engineers, and tw dcumentatin writers. The average experience f the team was seven t eight years f industrial experience (with at least three members having ver ten years f experience) in a wide variety f sftware industries, including defense-riented develpments. This breadth f experience was imprtant in the creatin and adptin f the develpment prcess.

2 The key gals f the prject were t prvide Custmer-defined prduct requirements Cmpliance with the prduct requirements specificatin A high-quality prduct Delivery n schedule Fr the custmer satisfactin gal, we describe ur use f Cntextual Inquiry, Quality Functin Deplyment, cnceptual mdeling, and rapid prttyping. We als describe a frmal requirements dcumentatin technique t analyze requirements and guide later sftware phases. Fr the quality gal, we describe the use f the requirements dcument, the interface and design review prcess, and the use f inspectins. We mentin functinal testing as guided by the requirements dcument. Fr the schedule gal, we discuss the rganizatin f the team int wrking grups and the use f the requirements dcument t ensure cverage f a requirements matrix. Finally, we describe several management prcesses fr balancing cnflicting gals and assessing prject dependencies and risks thrugh prcess metrics. Frm this experience, we have frmulated a cllectin f recmmendatins that we feel are true nt nly fr the DEC TP WORKcenter prject but fr all prjects. THEME Every engineer n the DEC TP WORKcenter develpment team had experience with frmal r semifrmal sftware develpment prcesses. The psitive experiences came frm prjects that were develped smthly and withut incident. The negative experiences stemmed frm prjects that ended in disaster in spite f (r because f) frmal develpment methdlgies. The entire engineering team, hwever, was enthusiastic abut frmal plicies, as lng as the team culd be in cntrl f the prcess. The team's unfficial mtt was "Use the prcess, but dn't let the prcess use yu." Thrughut the develpment cycle, we lked fr frmal techniques t cntrl varius parts f ur wrk, and then tried t adapt these techniques t the particular requirements and capabilities f ur develpment team. In sme instances, we were able t install a frmal mechanism with little r n mdificatin; but fr mst cases, we had t refine the mechanism, using the

3 fllwing steps. 1. Dcument the mechanism. 2. Test it n a realistic sample task. 3. Cllect bjective measures f hw well it wrked. 4. Adapt the mechanism. 5. Repeat until satisfied. We never used cmplex metrics, sftware physics, r deep analysis; the key t any success was t keep the prcess simple and t cntinually adapt it t fit the nature f the task and the team. Once we were satisfied with the prcess, we tried t apply it unifrmly and cnsistently acrss the prduct develpment. DESIGN REQUIREMENTS Because the DEC TP WORKcenter prduct was the result f a custmer-driven prcess, we were faced with a number f challenges, which can be categrized int the fllwing three areas. Gathering custmer requirements efficiently, accurately, and bjectively Capturing and integrating the requirements f several custmers int a single, cherent specificatin Recrding the requirements specificatin s that it culd be used as a reference during design and testing phases With the help f Digital's Sftware Engineering Technlgy Center (SETC), we fcused n tw techniques fr gathering requirements: Quality Functin Deplyment and Cntextual Inquiry. Furthermre, we utilized a frmal requirements specificatin dcument t capture the results f these techniques. We als utilized prttypes t validate ur understanding with the custmers and dcumented this in anther dcument, the DEC TP WORKcenter Cnceptual Mdel. Quality Functin Deplyment Quality Functin Deplyment (QFD) is an exercise in frming cnsensus amng team members (including custmers and develpment partners) fr identifying key requirements.[2,3] In a previus prject, QFD techniques had been perfrmed fr many f the same functinalities f the DEC TP WORKcenter prduct. We evaluated the validity f the data and results f QFDs fr that prject t determine if they culd be applied t the verlapping features in

4 the DEC TP WORKcenter prduct. This methd allwed us t take advantage f valid QFD data and results withut incurring the cst f prducing them. Apart frm the reuse f valid QFD results, we fund QFDs t be a fairly expensive way t gather requirements. The QFD techniques invlve a great deal f preparatin, custmer participatin, and analysis. The results, hwever, justified the effrt expended. We emerged frm the QFD prcess with a priritized list f requirements. Fr each requirement, we als identified (1) hw well the current prducts satisfy the requirements, and (2) hw well the cmpetitin satisfies the requirements. All f these factrs were expressed as numbers and culd be readily ranked fr imprtance, cst, and benefit. Once the requirements were ranked, we determined the features t be included in the prduct based n resurces and prjected market dates. These decisins were then validated by the custmers wh had been invlved in the initial requirements gathering. Recmmendatin: Reuse QFD data. Existing QFD data (either QFD input data and/r requirements resulting frm the QFD) may be reused upn assessment f their validity. Cntextual Inquiry Acting n the advice f the SETC, we used Cntextual Inquiries (CIs) t gather requirements.[4,5] CIs are structured visits t selected custmer sites t recrd exactly hw the custmer develps ACMS applicatins tday, and exactly hw a prpsed slutin culd imprve the custmer's prductivity. This technique invlved a great deal f analysis and was an expensive way t gather requirements. We feel it was wrth the cst because it gave us cnfidence in ur requirements list. We were able t cmpare the requirements against actual custmer activities t determine: 1. Thse requirements n the list that wuld nt be used by the custmers 2. Thse custmer activities that wuld nt be supprted by the prduct as described in the requirements list Bth the CI and QFD techniques yielded firm, bjective requirements specificatins that culd be cmpared, ranked, and further analyzed. In retrspect, the CIs that had the mst impact were the nes that were prperly dcumented fr future reference immediately after the CI visit.

5 Recmmendatin: Dcument Cntextual Inquiry Data. In rder t trace infrmatin t the CI and/r reuse its data, the CI visit needs t be frmally dcumented. Requirements Specificatin We needed an effective way t capture and cmbine the prduct requirements int a frmal specificatin that culd be used as a benchmark fr develpment. Several engineers n the team had a backgrund in prgramming fr the Department f Defense and were familiar with the DD-STD-2167A develpment prcess.[6] These engineers cnvinced the team that the prcess is beneficial if it is simplified and streamlined. Accrdingly, the team analyzed the DD-STD-2167A Sftware Requirements Specificatin frmat and mdified the frmat t the prject's needs. As a result, the team prduced a requirements specificatin dcument that matched the scpe f the prject, reflected the backgrund f the team members, and traced the rigin f the custmer requirements. The final dcument was 40 pages f semifrmal prse and has remained current fr the duratin f the prject. We have used the requirements dcument as an imprtant data surce in later develpment phases. During sftware design, we cmpared design features t the requirements dcument t eliminate unnecessary design frills and t detect requirements that were nt met. We referred t the requirements specificatin t develp a test suite fr cmplete testing f all prduct features. T ensure the use f the requirements specificatin, the dcumentatin shuld be kept as shrt as pssible, as cncise as pssible, and as descriptive as necessary. Recmmendatin: Custmize the requirements specificatin. The level f frmality f the requirements specificatin shuld reflect the purpse f the dcument. Furthermre, it shuld be as shrt as pssible, as cncise as pssible, and as descriptive as necessary. Prttypes and Cnceptual Mdel While we were preparing the requirements specificatin, we als built tw prttypes f the human interface fr the DEC TP WORKcenter envirnment. The first prttype existed nly n paper as a series f Mtif windws that illustrated hw we imagined the main functins f the DEC TP WORKcenter wuld perate. We shwed this paper prttype t custmers, asked fr their feedback, and made extensive mdificatins based n their reactins. We repeated this prcess at least three times. In retrspect, it was an expensive way t refine the interface, but it gave us cnfidence that we were building the crrect interface t ur

6 prduct. This paper prttype was captured in a frmal dcument called the DEC TP WORKcenter Cnceptual Mdel and wuld later supprt the DEC TP WORKcenter Functinal Specificatin and the user interface design. T demnstrate that the prduct was practical and t get sme initial perfrmance results, we als cnstructed an executable prttype f a few prduct functins. This activity was valuable in demnstrating feasibility, but it had tw unfrtunate side effects. First, it distracted the team frm the design prcess, which caused the schedule t slip. Secnd, we did nt have the sense t discard the prttype after it served its purpse. The engineering prttype suddenly became the first base-level cde and entered the main line f develpment. Eventually, we had t rewrite mst f the prttype cde, which was a mre cstly prcedure than starting with a clean design. The engineering prttype can be a valuable step if it has a well-defined purpse and if it is discarded when that purpse is served. Recmmendatin: Restrict prttype usage. The engineering prttype can be a valuable step in prduct develpment, if it has a well-defined purpse and if it is restricted t that purpse. DESIGN PHASE We used several techniques during the design phase, including Feature-based wrking grups Electrnic design ntebk Layered apprach t bject-riented design Detail-level design header files The feature-based wrking grups allwed the team t develp the high-level design in parallel in a cncentrated perid f time. The utput f each feature-based wrking grup was kept in an electrnic design ntebk and frmed the evlving high-level design. Once the high-level design was cmpleted, the team reviewed the design t validate cnsistency and integrity t prduct requirements and between interacting r dependent prduct features. A layered apprach t the bject mdel was used t describe the design f the prduct. The layered apprach allwed fr easy separatin f the bject-riented design frm the bject-riented features f the prduct. After the high-level design was cmpleted, header files were used t define the detail design f the prduct.

7 Feature-based Wrking Grup Technique During the design phase, we defined the majr features f the prduct and determined which requirements affected which feature. We then frmed feature-based wrking grups (FBWGs) t develp the design f each feature with respect t its assciated prduct requirements. Team members participated in the FBWG f interest t them, and a designated respnsible individual (DRI) led each FBWG. Since the number f team members was less than the number f wrking grups, team members participated in mre than ne FBWG. There were apprximately twice as many features as there were team members. Cnsequently, each team member was a DRI f apprximately tw FBWGs and participated as a member f apprximately six ther FBWGs. Once membership f the varius FBWGs was established, the FBWGs met, depending upn the availability f the members. Meeting cnflicts were avided by tracking FBWG meetings n a white bard. Table 1 illustrates the team members' participatin in the varius FBWGs fr the DEC TP WORKcenter prject. The clumns in Table 1 represent the varius FBWGs, and the rws represent the prject team members. The entries in the table indicate the rle that a specific team member played in the specific FBWG. The lad clumn indicates the verall rle (number f FBWG DRI rles, number f FBWG member rles) the team member played acrss all FBWGs. Table 1 Feature-based Wrking Grup Matrix Team Lad WG WG WG WG WG WG WG WG WG WG WG WG WG WG WG WG WG WG WG Member D/P Engineer 1 1/11 P.. P D P P. P P P P. P.... P Engineer 2 2/5... D. D.. P. P... P.... Engineer 3 2/8 P... P P D.... D.... P P P Engineer 4 2/9 P P.. P... P D. P. P.. D P. Engineer 5 4/8 D P D. P. P P..... D D.... Engineer 6 1/9. P. P P P... P P. D. P P... Engineer 7 1/ P.. D Engineer 8 3/ D.. D..... P D. Engineer 9 2/7 P D..... P D P. P P Dcumentatin Writer 1 0/ P... Dcumentatin Writer 2 1/3. P P..... D... Ntes: D -- Designated respnsible individual fr the WG P -- Participant in the WG

8 Dependencies r interactins between prduct features needed t be managed. If a team member's participatin verlapped with the interacting features, that persn prvided a means f cmmunicating amng the assciated FBWGs. Otherwise, the crrespnding DRIs prvided this exchange f infrmatin. Als, the prject leader and the architect attempted t attend all meetings t guarantee cnsistency acrss the varius FBWGs. This allwed us t reslve many issues cnsistently, but we wuld have benefited frm a mre frmal mechanism fr settling design disputes. The FBWGs cntinued t a lesser extent during the detail-level design, but the issues were narrwer in nature and were dealt with by the FBWG DRI and the affected cmpnent DRIs. In cnclusin, the FBWGs prvided clear assignment f respnsibility and guaranteed that the design was cvered by mre than ne team member. Due t their parallel nature, the FBWGs had n adverse affect n the schedule. Unfrtunately, even fr small grups, the FBWG generated t much specializatin f knwledge. Recmmendatin: Adapt the design prcess. The design prcess shuld be adapted t meet the schedule and resurce cnstraints. Electrnic Prject Ntebk The minutes and draft/final design f each FBWG were recrded in an electrnic prject ntebk. The electrnic prject ntebk prvided a means f cmmunicating the evlving design f the prduct amng the team members. Once entered int the ntebk, the infrmatin was made available t the team. Als, the entries psted in the ntebk during the day were cllected and mailed electrnically t the team members every night s that the team remained current n all design issues and decisins. This prved an efficient methd fr cmmunicating the infrmatin t the entire team as well as fr recrding the infrmatin fr later use. Withut a gal t prduce a frmal design dcument, the team members were nt as careful in dcumenting their design. Furthermre, the design was dispersed ver a set f ntebk entries that created issues in tw areas: Cnfiguratin management: Which ntes frmed the current set f design ntes? Inspectin difficulty: Which versin f a design nte was a surce dcument? The electrnic prject ntebk was nt limited t the design phase but was used t recrd and exchange infrmatin thrughut the phases f the prduct develpment life cycle.

9 Recmmendatin: Capture prject infrmatin. The electrnic prject ntebk is an easy way t share knwledge and exchange ideas, issues, slutins, futures, etc., abut a prject. Recmmendatin: Generate frmal design specificatins. Althugh the electrnic prject ntebk cntained the design, it is nt a substitute fr a frmal design specificatin. Layered Apprach t Object-riented Design Since the prduct wuld be bject-based, we used bject-riented design (OOD) techniques. Due t the inexperience f sme team members, the distinctin between abstractin levels was nt always clear. T allw the team t recgnize the different abstractin levels, we used different languages fr the tw levels f abstractin. At the prduct level, bject-riented terminlgy was used. At the prduct architecture level, a cnstrained layered mdel was used in which the cnstraints allwed a simple mapping int an bject-riented mdel. The fllwing cnstraints were applied t the varius layers in the mdel. 1. Each layer prvides ne and nly ne specific type f resurce. 2. Each layer prvides a set f services t manipulate that resurce. 3. The resurce and/r its services may use ther layers t prvide needed resurces and services. These rules allwed the team t distinguish between the design f the prduct and the data mdel f the bjects manipulated by bth the prduct and its bject-based peratins. Althugh this layered apprach t OOD was frmulated t make use f the team's backgrund, the resulting design was nt a pure OOD. Recmmendatin: Understand the purpse fr mdifying a prcess. Althugh the layered apprach t OOD attempts t bridge traditinal design methds t OOD methds, it shuld represent nly a phase in a planned transitin t OOD techniques. Detail-level Design Header Files During the detail-level design stage, we refined the varius layers required t implement the resurces and services t supprt the prduct features. This included determining the final

10 interface f each layer, defining the resurce cntrlled by the layer, and describing the functinality f the services prvided by each layer. T ptimize cnsistency and effrt, the detail-level design was represented as a C header file that prvides the services f a layer implemented in a C mdule. Furthermre, if a mdule represents an bject, then the header file cnsists f the visible peratins that can be perfrmed n the bject. The header files were placed under cnfiguratin cntrl while issues and reslutins cncerning a layer were recrded in the electrnic design ntebk. Since several features required the services f a specific layer (later implemented as a C mdule r cmpnent), we captured the relatinships in a feature/cmpnent matrix. Table 2 gives the feature/cmpnent matrix fr the DEC TP WORKcenter prduct. The clumns in Table 2 indicate the varius prduct features, and the rws indicate the cmpnents f the prduct. An entry in the matrix indicates that the cmpnent implements r supprts part f the prduct feature. Table 2 Feature/Cmpnent Matrix Cmp- Features nents D D D D

11 Ntes: 1 : Base Level 1 1+ : Base Levels 1 and 2 2 : Base Level 2 2+ : Base Levels 2 and 3 3 : Base Level 3 D : Deferred A DRI was assigned t each header file t crdinate the needs f the varius features n that layer. The cmpnent DRI met with several FBWG DRIs t ascertain the needs f each feature and present a satisfactry interface. On the ther hand, each FBWG DRI needed t crdinate with several cmpnent DRIs t prvide the capability fr the assciated feature. Recmmendatin: Share infrmatin acrss develpment phases. The use f header files as part f the detail-level design prvided (1) a centralized lcatin fr all interface infrmatin abut a mdule, (2) n redundancy f interface infrmatin, and (3) an up-t-date interface in the crrespnding cde. Design Reviews The entire team reviewed the high-level design fr cnsistency acrss the varius prduct features and fr integrity f the dependencies between features. Due t time cnstraints and the amunt f design infrmatin, this review was inefficient and was nt frmally cmpleted. Marathn high-level design review did nt wrk since it was t intense and t lng. We cncluded that the review prcess must be streamlined. The detail-level design was represented as C header files. Cnsequently, they were targets fr cde inspectin. Recmmendatin: Review the design in manageable pieces. Divide the high-level design int mdules s that its review is manageable. CODE INSPECTIONS Althugh inspectins were used fr the requirements dcument and the data mdel design, mst f the inspectins ccurred during the DEC TP WORKcenter cding phase. The technique was mdified t deal with time cnstraints and the amunt f cding, and t gain the acceptance f the team n the usefulness f inspectins. Basically, we defined a frmal inspectin and a semifrmal inspectin.

12 The frmal inspectins fllw the guidelines as described by Fagan.[7,8] The semifrmal inspectins had the fllwing restrictins: 1. Only tw engineers participated in the inspectin. 2. The mderatr was als the reader. 3. The authr was als the recrder. The fllwing criteria were established t decide which type f inspectin wuld be perfrmed. 1. Cmplex cde was frmally inspected. 2. Critical cde was frmally inspected. 3. Remaining cde was infrmally inspected. The cmplexity f the mdule was determined by cmputing the McCabe cyclmatic cmplexity f the mdule.[9,10] The threshld fr cmplex cde was initially set at 7 and wuld be peridically adjusted based n feedback n the effectiveness f the inspectins. Nte that the literature has usually determined 10 t be this threshld. At 7, apprximately 17 percent f the cde was cnsidered cmplex. This may be attributed t either the tendency f mdules t represent bjects in the design r the use f the X Windw System and Mtif as the graphical user interface. The prject leader determined the critical cde accrding t the nature f the cde r intermdule dependencies in the system. This infrmatin was available frm the detail-level design. One example is DEC TP WORKcenter parsers, where the flw f cntrl is based n pattern triggers rather than n sequential executin f statements. Cnsequently, the DEC TP WORKcenter parsers were deemed t be cmplex. All remaining cde was inspected using semifrmal techniques. T discurage the engineers frm artificially cnstraining their cde t be nncmplex, the prject leader culd randmly chse cde fr frmal inspectins (this was never needed). As anther refinement t the inspectin prcess, we reduced and adapted the set f cdes used t characterize a defect accrding t the type f dcument being inspected. This technique allwed us t accelerate the inspectin and cntinue t capture the infrmatin f interest. In anther attempt t refine the inspectin prcess, the recrder defined the defect cdes. This accelerated the semifrmal inspectins but slwed the frmal inspectins. Recmmendatin: Understand the purpse fr mdifying a prcess

13 (revisited). Under schedule r resurce cnstraints, cnsciusly decide hw t frmally relax the inspectin prcess and understand the cnsequences. Recmmendatin: Chse tls t supprt the prcess. Given unbiased criteria t select the level f inspectin, chse the apprpriate tls t supprt the decisin prcess. SCHEDULING Prject scheduling played an imprtant rle in managing the prject. Scheduling tls assciated with persnal cmputers (such as prgram evaluatin and review technique [PERT], critical path methd [CPM], precedence netwrk, and resurce leveling capabilities) were used t manage the schedule. Tasks were classified as either prcess-related r prduct-feature-related. The prcess-related tasks cvered activities such as Digital's Phase Review Prcess r custmer interactins. The prduct-feature-related tasks were activities directly related t the design, implementatin, and testing f prduct features. One distinctin f the DEC TP WORKcenter prduct is that mst f the prduct-feature-related schedule was determined frm the feature/cmpnent matrix (see Table 2). When a specific feature was planned t be added int the prduct, the cmpnents supprting that feature were als scheduled t be added. The entries in the matrix in Table 2 indicate in which cde base level the cmpnent implements r supprts the prduct feature. The engineer(s) assigned t a task submitted an estimate f the time needed t accmplish the task t the prject management. If the estimates were cnsidered unreasnable based n past engineering experiences, an in-depth analysis was perfrmed t understand the discrepancy. These discrepancies were due t either a misunderstanding by the prject management f the cmplexity f the task r an inefficient slutin plan by the engineer t build upn existing cmpnents r prcesses. Recmmendatin: Share infrmatin acrss develpment phases (revisited). Use requirements analysis and design infrmatin t define the schedule. Recmmendatin: Get team supprt fr the schedule. Fr any schedule, btain cmmitment frm the team. Efficiency Factr We als calculated an efficiency factr t accunt fr activities that wuld lwer the efficiency f engineers in perfrming their

14 tasks. These activities included peridic mail reading, attending nn-prject-related meetings, sick time, jury duty, and cde inspectins. We revised all wrk estimates t reflect the engineer's efficiency factr. Initially, the efficiency factr fr mst f the engineers was calculated t be 60 percent. Althugh the efficiency factr was intended t achieve the mst realistic schedule pssible, it was the cause f several prblems: The efficiency-related activities were cunted twice if the engineer's estimates included these activities. There is an assumptin that the efficiency-related activities are spread unifrmly ver all tasks. This is true fr repetitive activities that ccurred within the reslutin f the tasks being estimated, but ther efficiency-related activities ccurred rarely (e.g., sick time) r were assciated with a specific phase f the prject (e.g., cde inspectins). As a result, the schedules needed t be refined and adjusted frequently. Recmmendatin: Understand the factrs that impact the schedule. The efficiency factr attempts t capture thse separate activities that were nt wrthwhile but impact the efficiency f ther activities. Unplanned Tasks During the initial phase f the prject, the prject management recgnized that schedule predictability was highly influenced by unplanned tasks. T better understand the nature f unplanned tasks, the prject management participated in a Sftware Metrics In Actin (SMIA) curse ffered by the SETC. The SMIA curse was applied t ur prblem f unplanned tasks ver the next phase f the prject. T ur surprise, we cncluded that, n matter hw well ne plans, ne always has an additinal 20 t 25 percent f unplanned tasks. This included new tasks, existing tasks that tk lnger, and existing tasks that were cmpleted. Recmmendatin: Understand the impact f unplanned activities. N matter hw well ne plans, ne always has an additinal 20 t 25 percent f unplanned tasks. This includes new tasks, existing tasks that tk lnger, and existing tasks that were cmpleted. Milestnes The difficulties f estimating tasks and the existence f unplanned tasks wuld smetimes render the schedule invalid.

15 Milestnes within the prject schedule allwed the team t meet the assciated deadlines. Milestnes als caused tw events that affected the prject: Unplanned tasks were priritized against planned tasks, causing readjustment f milestnes based n the priritizatin criteria. Engineers became mre efficient, causing the efficiency rating t be revised and allwing sme f the unplanned tasks t be included withut impacting the schedule. Recmmendatin: Define milestnes. The team wrks best when well-defined milestnes fr gals are established. Feature "Hit List" Tward the end f the design phase, we determined that the planned date fr cmpletin culd nt be met unless we reduced the functinality f the prduct. We created a feature "hit list" in the electrnic prject ntebk in which we listed the candidates fr eliminatin frm the prduct. The feature hit list was used in a Pugh prcess t determine, in a structured manner and with grup cnsensus, the features t be eliminated in rder t meet the prjected market date.[11] Sme f the features that we eliminated thrugh ur hit-list technique riginated in the QFD prcess. During field test training, custmer feedback indicated that sme f the eliminated features were needed fr a viable prduct. This event caused us t reevaluate and readjust the prjected market date in rder t include the missing features. Thus, we reaffirmed the validity f the results supprting ur custmer satisfactin gal. Furthermre, the readjustment f the prjected market date had high management visibility, but the utilizatin f the custmer satisfactin prcesses permitted us t adequately dcument the ratinale fr and justificatin f the readjustment. Recmmendatin: Manage and adapt the change prcess. When making a change that is visible t the custmer and/r management, ne needs (1) a frmal prcess fr defining the change, (2) cnsensus amng the team, (3) traceability t facts supprting the riginal decisin and its change, (4) impact analysis f change, and (5) agreement frm custmer and/r management. FINAL PHASE In the final stages f the DEC TP WORKcenter prduct develpment, we cnducted field tests at custmer sites, identified defects,

16 and determined the final changes t be made t the prduct. Field Test Advcacy Prgram During field test, we tk a practive apprach in ur relatinship with the custmer field test sites. Under ur Field Test Advcacy Prgram, an engineer is assigned t mnitr the prgress and t reslve any issues r prblems at the custmer's field test site. The engineer mnitrs the custmer's sftware prblem reprts (SPRs) in the field test SPR database t understand (r be aware f) any patterns in SPRs. In ne example, a custmer raised a series f feature suggestins that were all attempts t use the DEC TP WORKcenter envirnment fr an unsupprted bject type. Althugh the suggested features wuld be useful, they wuld nt be as imprtant if the main feature was prvided. Mnitring custmer SPRs prvided us with an understanding f hw the custmer was testing and assured the custmer that the engineering team understd the custmer's cncerns. Recmmendatin: Adpt useful prcesses. Adpt prcesses in which the benefits utweigh the csts, but understand the time frame f bth. Tracking Defects and Mnitring Fixes As the prduct was being develped, all (internal and external) prblems were tracked using a prblem tracking tl. Every prblem was entered int the prblem database and given a unique identifier. This allwed the engineer t assciate a fix with the crrespnding prblem identifier. Furthermre, the prblem tracking tl allwed us t mnitr the defect identificatin and fix rate n the prject. Figure 1 shws bth the number f prblems entered ver time as well as the prblems fixed ver time.[12] Interesting pints in the graph are the slpes, plateaus, change in slpe, and vertical distance between the tw lines. The tracking tl als allwed us t verify that the pririty f the fixes was cnsistent t the severity f the prblem. Figure 2 shws the same graph fr the tw highest severity classes and indicates that the prblems with the highest severity classes were mnitred clsely and fixed immediately. Tracking the prblems wrked well t identify issues during the DEC TP WORKcenter prduct develpment. Mre analysis, hwever, was needed t understand trends as sn as pssible. Recmmendatin: Adpt prcesses t cllect valuable metrics.

17 Understand the ratinale fr adpting a metric and set up a prcess that achieves the gal f the metric. MUST-DO Lists As we apprached majr cde freeze dates, we priritized the defects t be fixed and cmpared them t ur MUST-DO criteria. Usually the criteria cnsisted f the fllwing. The defect was a pririty 1 r 2. The defect impeded testing effrts f critical functinality. The defect represented a regressin frm a previus stable versin f the prduct. The defects were added t the MUST-DO list if they met the criteria. This list indicated backlgs f defects that needed t be reslved prir t declaring a cde freeze. Figures 3 and 4 shw MUST-DO cunt patterns prir t reaching cde freeze. The slid line (ttal) indicates the utstanding MUST-DO items ver time. Recmmendatin: Define valuable metrics (r fcus n imprtant issues). The MUST-DO list helps priritize the tasks that require fcus during a specific activity and prvide well-defined gals fr the team. Prduct Stability Once the prduct had reached feature freeze, a change cntrl bard was put in place t guarantee the stability f the prduct and t avid any majr regressin that wuld impact the schedule. The bard apprved the inclusin f any defect fix after (1) review r inspectin f the cde mdificatins, and (2) adequate testing. Furthermre, we mnitred the defect discvery rate t determine if it was stable enugh t warrant a cde freeze.[12] In this case, we measured a running ttal f the number f MUST-DO items added ver the last five days. Figures 3 and 4 shw this metric. The brken line (five-day cumulative) indicates the five-day running ttal and measures if the changes are stabilizing. Recmmendatin: One can always imprve. It is never t late t set up a change cntrl bard t reduce the intrductin f new prblems and regressins.

18 CONCLUSIONS The DEC TP WORKcenter bject-based develpment envirnment (versin 1) was develped ver apprximately 24 mnths. During this time, we were presented with a variety f situatins that culd have impacted ur prject gals. This paper presents several f the prcesses that the team adpted t meet the prject gals. Table 3 summarizes the recmmendatins based n ur experiences n adpting prcesses t supprt ur gals. In retrspect, we see that the prject functined smthly when all f the fllwing cnditins were met. Everyne understd what develpment phase was in prgress. We identified a set f prcesses t gvern each phase. We adapted the prcess t suit the prject team. We adapted the prcess t the realities f the prject schedule. All the team members understd and accepted the prcess. We fllwed the prcess cnscientiusly. In shrt, the entire experience f the DEC TP WORKcenter prject can be summed up as: Sftware develpment prcesses shuld be as simple as pssible. The team shuld frmally adapt the prcesses t its wn needs. The team shuld understand the cnsequences f mdifying the prcess. Althugh these rules f thumb d nt ensure a smth, prductive prject, the DEC TP WORKcenter team fund them t cntribute t a successful cnclusin. Our recmmendatins can be adpted by any prject team; hwever, the team wuld benefit by taking part in a similar prcess f identifying its gals and supprting them with apprpriate prcesses. Table 3 Recmmendatins Based n the DEC TP WORKcenter Develpment Prject 1. Reuse QFD data. 2. Dcument Cntextual Inquiry data.

19 3. Custmize requirements specificatin. 4. Restrict prttype usage. 5. Adapt the design prcess. 6. Capture prject infrmatin. 7. Generate frmal design specificatin. 8. Understand the purpse fr mdifying a prcess. 9. Share infrmatin acrss develpment phases. 10. Review design in manageable pieces. 11. Chse tls t supprt prcess. 12. Get team supprt fr the schedule. 13. Understand the factrs that impact the schedule. 14. Understand the impact f unplanned activities. 15. Define milestnes. 16. Manage and adapt the change prcess. 17. Adpt useful prcesses. 18. Adpt prcesses t cllect valuable metrics. 19. Define valuable metrics (r fcus n imprtant issues). 20. One can always imprve. ACKNOWLEDGMENTS The authrs wuld like t acknwledge the members f the DEC TP WORKcenter team, past and present, that helped define and adpt the varius prcesses presented in this paper. Als, the detailed cmments frm the many reviewers were very helpful. REFERENCES 1. T. Speer and M. Strm, "Digital's Transactin Prcessing Mnitrs," Digital Technical Jurnal, vl. 3, n. 1 (Winter 1991): J. Hauser and D. Clausing, "The Huse f Quality," Harvard Business Review, vl. 66, n. 3 (May-June 1988):

20 3. L. Chen, "Quality Functin Deplyment: An Applicatin Perspective frm Digital Equipment Crpratin," Natinal Prductivity Review, vl. 7, n. 3 (Summer 1988): K. Hltzblatt and S. Jnes, "Cntextual Inquiry: Principles and Practice," Technical Reprt DEC-TR 729 (Maynard, MA: Digital Equipment Crpratin, 1990). 5. D. Wixn, K. Hltzblatt, and S. Knx, "Cntextual Design: An Emergent View f System Design," Technical Reprt DEC-TR 686 (Maynard, MA: Digital Equipment Crpratin, 1990). 6. "Military Standard Defense System Sftware Develpment," Technical Reprt DD-STD-2167A (Washingtn, D.C.: U.S. Department f Defense, 1988). 7. M. Fagan, "Design and Cde Inspectins t Reduce Errrs in Prgram Develpment," IBM Systems Jurnal, vl. 15, n. 3 (1976): M. Fagan, "Advances in Sftware Inspectins," IEEE Transactins n Sftware Engineering, vl. SE-12, n. 7 (July 1986): T. McCabe, "A Sftware Cmplexity Measure," IEEE Transactins n Sftware Engineering, vl. SE-2, n. 6 (December 1976): T. McCabe and C. Butler, "Design Cmplexity Measurement and Testing," Cmmunicatins f the ACM, vl. 32, n. 12 (December 1989): S. Pugh, Ttal Design: Integrated Methds fr Successful Prduct Engineering (Reading, MA: Addisn-Wesley, 1991). 12. R. Grady, Practical Sftware Metrics fr Prject Management and Prcess Imprvement (Englewd Cliffs, NJ: Prentice-Hall, 1992). TRADEMARKS ACMS, DEC TP WORKcenter, and Digital are trademarks f Digital Equipment Crpratin. Mtif is a registered trademark f Open Sftware Fundatin, Inc. X Windw System is a trademark f the Massachusetts Institute f Technlgy. BIOGRAPHIES Ernest Guerrieri Ernest Guerrieri, a principal sftware engineer

21 in the Prductin Systems Grup, is the TP WORKcenter prject leader. He is an adjunct prfessr at Bstn University. Prir t jining Digital in 1990, he was emplyed by SfTech, Inc., where he was the chief designer and develper f reusable Ada prducts fr infrmatin systems develpment (RAPID) center library. He hlds a Ph.D. in sftware engineering frm Rensselaer Plytechnic Institute and an M.S.C.S. frm the University f Pisa. Ernest has published varius papers in sftware engineering. He is a member f ACM, IEEE Cmputer Sciety, and Sigma Xi. Bruce J. Taylr A principal sftware engineer, Bruce Taylr is the sftware architect f the TP WORKcenter prject. Prir t jining Digital in 1991, Bruce wrked in CASE tl develpment at Intermetrics, Inc. He designed the repsitry database fr the SLCSE sftware develpment envirnment and has published many papers n the use f database technlgy in the sftware develpment envirnment. He has a B.A. in English and an M.A. in cmputer science frm Duke University. His current research interests include repsitry supprt fr cmplete sftware life-cycle envirnments and sftware quality strategies. ============================================================================= Cpyright 1993 Digital Equipment Crpratin. Frwarding and cpying f this article is permitted fr persnal and educatinal purpses withut fee prvided that Digital Equipment Crpratin's cpyright is retained with the article and that the cntent is nt mdified. This article is nt t be distributed fr cmmercial advantage. Abstracting with credit f Digital Equipment Crpratin's authrship is permitted. All rights reserved. =============================================================================