Research--gct Paper Pres

Goal Centric Traceability “Goal-Centric Traceability: Using Virtual Plumblines to Maintain Critical Systemic Qualities” IEEE Transaction on Software Engineering. Sep/Oct 2008 Jane ClelandHuang, Will Marrero, Brian Berenbach

What is GCT? 

The plumline −





Simple yet accurately mesures compliance with goal of having a vertical wall

Goal Centric Traceability is much like this. Mesures longterm complience with quality goals −

The “ilities” or Non functional requirements

From wikipedia.org Plumbob

What is GCT continued 

Different attributes represented are: − − − − −



Preformance Reliablity Safty Security Usibility

Challanging to implement and maintain correctly over short and long term in large software systems

Quality Assessment Models  





Stakeholder Goals Proactavly elicitated Tools explicitly used to measure and evaluate complience with requirements Refered to the Quality Assessment Models in GCT These often created and used in Early Stages and then not reused durring latter revisions and maintinence

Problems with this 



This can lead to change induced system failure Examples: − − −



Therac 25 New York City Subway Accident 1970 Japan Telecoomunications Switch

Also leads to un-necessary rework... $$$

Case Study 

“Ice Breaker System” Robertson and Robertson’s Mastering the

Requirement Process Charlotte and Greeley Co, Peel Ontario Receives series of inputs from a series of weather stations and forecasts freezing conditions to schedule salt dispersal

Phases of GCT—Creation

Quality Assessment Methods  Evaluate

critical quality goals  Types of models Executable models… i.e. preformance

modeling, fully automated Manually evaluated models… i.e. checklists for process steps or coding features Runtime monitors … ensure that goals related to safe/secure operation maintained at runtime

QAM cont. Test cases ○ Critical for evaluating impact of a change if goal is refined to the functional level. ○ I.e. security goal to limit access to authorized users can break down to functional level: users, roles, login, authentication

Ice Breaker—QAM

Software Maintenance Stage

Summery/Overview  The

devil is in the details… too restrictive and it is too expensive/hard to maintain, too permissive of change and it is also a waste of money  Must weigh criticality/cost benefit level, if the system is critical then is benificial  Must keep maintained and keep using

Good points of paper  Good

overview paper covering multiple sub methods and current applications of the methods in the real world  Good multi domain coverage… paper covered “de-iceing” problem I covered and a Nuclear Power plant trainer/simulator

Flaws  Process

is an added cost and time to

keep up  Introductory paper, glosses over some of the issues  Case studies could cover more of a time span… show were developers able to “stick to” the process