Team Prcess Data Warehuse Gals and High-Level Requirements Backgrund TSP SM is used by teams wrking in a wide variety f prblem dmains (e.g. sftware, hardware, services). Since these activities are nt limited t sftware, the name Team Prcess Integrated and the acrnym TPI are used in these dcuments t describe the full range f TSP-inspired high-maturity prcesses, and t avid imprper use f Carnegie Melln service marks. Gals TPI teams use a variety f prject executin methdlgies (e.g. waterfall, Scrum, Agile, etc.) TPI teams cllect persnal, team, grup and rganizatin data spanning prjects, deliverables, phases, releases, rg changes, etc. Data is rich and fine-grained Up t nw, data analysis activities have mstly been cnfined t single team prjects. This represents a significant lst pprtunity This initiative will endeavr t create a chesive set f database and sftware cmpnents that any rganizatin can install and set up t create a private, lcal repsitry f TSP/TPI metrics This initiative will nt endeavr t install specific physical repsitries. In particular, this initiative will nt endeavr t create a glbal database f TSP/TPI metrics. This initiative will nly endeavr t create a set f reusable sftware cmpnents. It will be up t particular rganizatins t install these cmpnents n cmputers within their netwrk, fr the purpse f perfrming private analyses f their wn data. Maintain an pen architecture, embracing extensibility and custmizability Aggregate data frm different surces, including different TSP/TPI tls Analyze data frm many prjects acrss an rganizatin, fr example t: measure ROI f prcess imprvement activities measure histrical perfrmance fr use in planning activities Maintain histry f changes t data, and view trends acrss time Generate charts and reprts using third-party reprting tls Feed data int ther systems fr example t facilitate status reprting SM Team Sftware Prcess and TSP are service marks f Carnegie Melln University. Carnegie Melln University has neither cntributed t nr evaluated the cntents f this dcument. Cpyright 2012-2014 Tuma Slutins, LLC
Data Flw The warehuse shuld be capable f aggregating data frm multiple surces, t include: Multiple different TSP/TPI tls Other enterprise data surces, such as crprate directries r ALM systems In keeping with industry best practices, the data warehuse will nt be designed t prvide back-end transactinal strage fr TSP/TPI tls r ther surce systems. Thse tls/systems will still need their wn, independent transactinal data stres. Instead, ETL prcesses will Extract data frm surce systems, Transfrm the data as necessary, and Lad it int the data warehuse. T the extent pssible, the warehuse shuld anticipate/allw ETL prcesses that perate cntinuusly, lading data in near-real-time. Data in the warehuse is made available n a read-nly basis fr analysis and reprting purpses. External lgic shuld nt expect t be able t alter values in the warehuse and see thse changes prpagate back int the surce systems (e.g. the riginating TSP/TPI tls) Time Histry The warehuse shall retain a histry f changes t certain data, making it pssible t View the data as it appeared at sme histrical pint in time Determine the changes that have ccurred between tw pints in time View trends in the way data has changed ver time Query Gals At a minimum, the warehuse shuld include enugh data t perfrm all f the fllwing traditinal TSP analyses: Planned-vs-actual time by prcess phase Planned-vs-actual defects injected and remved by prcess phase Planned-vs-actual size Time/size estimating errr Planned-vs-actual Prductivity, defect density, review rate Planned-vs-actual Phase yield, prcess yield Planned-vs-actual AF/R, DRL, PQI, COQ These analyses shuld be pssible fr varius subsets f data, including: The entire rganizatin A single sub-rganizatin r grup f rganizatins A particular prject, subprject, r grup f prjects A particular subteam and/r iteratin within a prject A particular cmpnent r subcmpnent within a prject A particular milestne within a prject A set f data matching user-defined labels Cpyright 2012-2014 Tuma Slutins, LLC
Data Privacy When querying data, it shall be pssible t determine the number f individuals, teams, prjects, and rganizatins whse data cntributed t a particular reprt. The warehuse will NOT prvide facilities fr analyzing the data f a particular individual. (This restrictin is intentinal, t discurage imprper use f persnal metrics.) Reprting mechanisms shall include cnfigurable privacy threshlds. Fr example, a reprt culd censr itself if a particular drill-dwn wuld shw private data fr a single individual. These threshlds shuld be cnfigurable n a per-user basis, s caches culd ptentially see mre granular data than senir managers. Technical Requirements T the extent pssible, different cmpnents f the warehuse shuld be designed with prtability in mind. Fr example, database cmpnents shuld ideally supprt the use f a variety f different relatinal database platfrms, including zer-cst slutins whenever pssible. It shuld be pssible t backup/restre the data in the warehuse, t guard against data lss r crruptin. Scalability: The warehuse shuld be capable f supprting very large rganizatins, t include data cllected by tens f thusands f peple ver a span f many years The warehuse shuld nt be verly cmplex t set up fr small rganizatins with simple data analysis needs. Fr these small rganizatins, it shuld be pssible t setup and install a lcal data warehuse repsitry with minimal effrt and expense. Cpyright 2012-2014 Tuma Slutins, LLC
Cntent Requirements Organizatins The warehuse shuld be capable f capturing data frm mre than ne rganizatin Organizatins can be recrded in the warehuse as ne r mre hierarchical rg structures T the extent pssible, the warehuse architecture will nt place specific cnstraints n the definitin f an rganizatin: Organizatin culd map t varius management r reprting entities such as branches, divisins, grups, subsidiaries, cmpanies, r even entire distinct crpratins. This decisin wuld be the prergative f the persn wh manages a particular data warehuse repsitry. Fr example, smene creating a lcal repsitry fr analysis f crprate data might use rganizatins t represent the crprate reprting structure; while smene creating a warehuse repsitry t analyze data acrss the glbal TSP cmmunity might use rganizatins t represent distinct crpratins. The rg structure hierarchy can be arbitrarily deep, and can be ragged (deeper in sme branches f the tree than thers). The warehuse will nt assume that a particular individual belngs t a single rganizatin, r that a particular prject team is made up f individuals frm a single rganizatin. Imprted data can be tagged with the riginating rganizatin It shall be pssible t analyze data fr a particular rganizatins and its sub-rganizatins, fr example t: Display aggregated CIO-level data fr an entire rganizatin, fr example as part f a business intelligence dashbard Drill dwn t see data fr a particular sub-rganizatin Enfrce security cnstraints, fr example t restrict a particular user s view f a reprt t the data frm a single rganizatin Prjects The warehuse shall stre data frm many different prjects Teams A given prject may span any number f iteratins A particular prject / iteratin may invlve individuals frm multiple teams and multiple rganizatins Prject wrk is perfrmed by teams f individuals Teams can have subteams (e.g. hardware team, sftware team, QA) Teams and subteams can include members frm mre than ne rganizatin. Cpyright 2012-2014 Tuma Slutins, LLC
Prcesses The warehuse shuld nt presume a specific hard-cded prcess, but shuld be amenable t the analysis f data frm teams using: Different prblem/business dmains (e.g. sftware develpment, hardware design, prductin supprt, dcumentatin, training, services) Different prject lifecycles (e.g. agile / Scrum / rapid-iterative / waterfall) Different prcesses, phases and wrkflws Different wrk prducts and size metrics The warehuse shuld be capable f capturing the prcesses that varius teams are using, and tagging imprted data with the apprpriate prcess metadata. A mechanism shuld be prvided t map phase types frm ne prcess t anther, s that: Teams can manage and analyze their data using custmized/tailred prcesses This data can still be mapped t an rganizatinal standard prcess fr analysis and reprting purpses Taxnmies Organizatins may want t grup data int arbitrary categries and analyze the data by categry. Fr example, an rganizatin might want t: Perfrm separate analyses f data frm new develpment prjects vs. legacy maintenance prjects Analyze data separately fr web develpment, rich client applicatin develpment, r embedded sftware Analyze the differences between teams that are new t TSP and teams that have been using TSP fr many years Analyze the return n investment btained by putting individuals thrugh a PSP SM Advanced curse Perfrm an analysis that excludes data cllected by teams r individuals that are knwn t be willfully ignring the prcess T supprt these needs, the warehuse will allw the definitin f custm taxnmies. Each taxnmy will have: A name (Fr example: Team Maturity ) A fixed list f terms fr categrizing data (Fr example: Learning, Applying, Mastering Perfecting ) The warehuse shall allw taxnmy terms t be attached t rganizatins, prjects, teams, individuals, WBS cmpnents, r tasks. These attachments can be multivalued. Data queries and reprts shall supprt filtering r categrizing data by these taxnmies. SM PSP is a service mark f Carnegie Melln University. Cpyright 2012-2014 Tuma Slutins, LLC
Metadata Organizatins may have arbitrary types f custm metadata that they wuld like t recrd in the warehuse. Fr example, when a prject cmpnent is stred in the warehuse, they might want t anntate it with the unique ID f a defect frm a crprate defect tracker. These anntatins culd be imprtant t enable integratin f warehuse data with ther systems. T meet this need, the warehuse will include a facility t define metadata types Free-text metadata values can be attached t rganizatins, prjects, teams, WBS cmpnents, r tasks. These attachments can be multivalued. Wrk Breakdwn Structure The Warehuse shall include a descriptin f the hierarchical cmpnents and subcmpnents that make up each prject The warehuse shall include a list f the milestnes declared fr each prject including: The name f the milestne The cmmit date, if applicable The Warehuse shall include a list f the tasks present in each prject, including: The names f each task The cmpnent / subcmpnent t which the task belngs The prcess phase fr each task The milestne t which the task belngs Metrics Data The warehuse shall include planned and actual size data fr individual cmpnents The warehuse shall allw free-text ntes t be attached t any cmpnent r task The warehuse shall include raw time lg entries, t include: The cntributing rganizatin The assciated team prject, WBS cmpnent, and task The prcess phase Start and end timestamps fr the time lg entry The number f minutes f delta and interrupt time The warehuse shall include defect lg entries, t include: The cntributing rganizatin The assciated team prject, WBS cmpnent, and task The date and time f the defect lg entry The type f the defect (frm the defect type standard) The prcess phases where the defect was injected and remved The number f minutes f fix time The defect descriptin The warehuse shall include calculated earned value data fr WBS cmpnents and tasks, t include: Baseline planned time Baseline cmpletin date Cpyright 2012-2014 Tuma Slutins, LLC
Planned and actual time Planned cmpletin date Replanned cmpletin date Frecast cmpletin date Actual cmpletin date Percent cmplete Percent spent Cpyright 2012-2014 Tuma Slutins, LLC