View
216
Download
2
Category
Tags:
Preview:
Citation preview
Lecture 7 Quality Attributes = Nonfunctional Req.
Lecture 7 Quality Attributes = Nonfunctional Req.
Topics Topics Quality Attributes
Readings:Readings:
January 29, 2008
CSCE 492 Software Engineering
– 2 – CSCE 492 Spring 2008
OverviewOverviewLast TimeLast Time
Documenting Software Architecture Rational Unified Process (RUP) - Kruchten
Today’s Lecture Today’s Lecture Quality Attributes = Nonfunctional requirements
References: References: Documenting Software Architectures: Views and Beyond, 2002,
Addison-Wesley, SEI series.
Next Time:Next Time: Quality Attributes = Nonfunctional requirements
– 3 – CSCE 492 Spring 2008
Creating An ArchitectureCreating An Architecture
““Beauty is in the eye of the beholder”Beauty is in the eye of the beholder” Booth Tarkington (1838–1918). The Magnificent
Ambersons. 1918.
So whose concept of “Quality” does the architect use?So whose concept of “Quality” does the architect use? His/her own? Customer? Can’t we all just agree? (paraphrasing Rodney King)
Can we move to a more objective less subjective def.?Can we move to a more objective less subjective def.? We will use quality attribute scenarios
– 4 – CSCE 492 Spring 2008
Understanding QualityUnderstanding Quality
The surest foundation of a manufacturing concern is The surest foundation of a manufacturing concern is quality. After that, and a long way after, comes cost.quality. After that, and a long way after, comes cost.
Andrew CarnegieAndrew Carnegie
Quality is never an accident; it is always the result of Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction high intention, sincere effort, intelligent direction and skillful execution…and skillful execution…
Will A. FosterWill A. Foster
– 5 – CSCE 492 Spring 2008
QualitiesQualitiesExamplesExamples
1.1. UsabilityUsability
2.2. ModifiabilityModifiability
3.3. PerformancePerformance
4.4. SecuritySecurity
5.5. AvailabilityAvailability
6.6. TestabilityTestability
7.7. On cost, on scheduleOn cost, on schedule
8.8. Cost and benefitCost and benefit
9.9. Integration with legacy systemsIntegration with legacy systems
10.10. Functionality? Functionality?
– 6 – CSCE 492 Spring 2008
Functionality vs QualityFunctionality vs Quality
Functionality and other quality attributes are Functionality and other quality attributes are orthogonal.orthogonal. Orthogonal ? At least independent? Note functionality does not imply anything about others!
What is functionality anyway?What is functionality anyway? The system works as intended.
If functionality was the only concern we could If functionality was the only concern we could implement as one large module in Cobol or even implement as one large module in Cobol or even assembly language.assembly language.
So functionality is a prime goal, but it should not be the So functionality is a prime goal, but it should not be the only goal.only goal.
– 7 – CSCE 492 Spring 2008
Architecture and Quality AttributesArchitecture and Quality Attributes
Achieving quality attributes must be considered thru:Achieving quality attributes must be considered thru: Design Implementation, and Deployment
No attribute is entirely dependent on design or other No attribute is entirely dependent on design or other phases.phases.
Satisfactory inclusion of quality attributes means you Satisfactory inclusion of quality attributes means you must get the big picture ( architecture) and the must get the big picture ( architecture) and the details (implementation) right!details (implementation) right!
– 8 – CSCE 492 Spring 2008
Usability: Arch. Vs Non-Arch AspectsUsability: Arch. Vs Non-Arch Aspects
Non-architectural aspects of usability:Non-architectural aspects of usability: Making the user-interface clear and easy to use Should we use radio button or check box? What font? All a crucial to end-user usabilty, but they are not
architectural
Examples of architectural aspects of usabilityExamples of architectural aspects of usability Whether the system provides an “undo’ capability to the
user? Can we – reuse data previously entered? These are architectural because they are going to require
the cooperation of several elements.
– 9 – CSCE 492 Spring 2008
Modifiability: Arch. Vs Non-Arch AspectsModifiability: Arch. Vs Non-Arch Aspects
Architectural aspects of Modifiability:Architectural aspects of Modifiability: How functionality is partitioned
Non-architectural aspects of Modifiability :Non-architectural aspects of Modifiability : Coding techniques used within a module
Note: in spite of having the perfect decomposition, the Note: in spite of having the perfect decomposition, the implementation may be not be maintainable.implementation may be not be maintainable.
You must be concerned about modifiability at all levels, You must be concerned about modifiability at all levels, all the time.all the time.
– 10 – CSCE 492 Spring 2008
Performance: Arch. Vs Non-Arch AspectsPerformance: Arch. Vs Non-Arch Aspects
The performance of a systems depends on both The performance of a systems depends on both architectural and non-architecture aspects.architectural and non-architecture aspects.
Architectural aspects of Performance: Architectural aspects of Performance: Communication between components Partially on partitioning of functionality Allocation of resources
Non-architectural aspects of Performance: Non-architectural aspects of Performance: Choice of algorithms How these algorithms are coded
– 11 – CSCE 492 Spring 2008
Architectural Vs Non-ArchitecturalArchitectural Vs Non-Architectural
1.1. Architecture is critical to achieving quality Architecture is critical to achieving quality attributes.attributes.
2.2. Architecture alone cannot achieve these qualities.Architecture alone cannot achieve these qualities.
Quality attributes can never be achieved in isolation.Quality attributes can never be achieved in isolation.
The achievement of one attribute may negatively (or The achievement of one attribute may negatively (or perhaps positively) influence the achievement of perhaps positively) influence the achievement of another.another.
E.g., security and reliability, (or security and usability or E.g., security and reliability, (or security and usability or performance and modifiability) are often at cross–performance and modifiability) are often at cross–purposespurposes
– 12 – CSCE 492 Spring 2008
Types of Quality AttributesTypes of Quality Attributes
1.1. Qualities of the systemQualities of the system Availability Performance Security Testability Usability
2.2. Business qualitiesBusiness qualities Time-to-market Cost and benefit Projected lifetime
3.3. Overall architectural qualities.Overall architectural qualities. Conceptual integrity Correctness and completeness Constructability
– 13 – CSCE 492 Spring 2008
System Quality AttributesSystem Quality Attributes
Been a focus of the software industry since the 1970’sBeen a focus of the software industry since the 1970’s
Each attribute ( usability, performance, reliability) has Each attribute ( usability, performance, reliability) has its own focus group of researchers, conferences, its own focus group of researchers, conferences, journals, terminology etc.journals, terminology etc. Usability (SIGCHI) - http://www.upassoc.org/conf2003/ Performance (SIGMETRIC)
http://www.sigmetrics.org/conferences.html Reliability - http://www.issre2001.org/
Attributes are not “operational”. What does it mean to Attributes are not “operational”. What does it mean to say a system is modifiable, it needs to be say a system is modifiable, it needs to be measurable so we can make comparisons, measurable so we can make comparisons, judgments.judgments.
– 14 – CSCE 492 Spring 2008
Quality Attribute ScenariosQuality Attribute Scenarios
Quality Attribute Scenario is a quality-attribute-specific Quality Attribute Scenario is a quality-attribute-specific requirement.requirement.
There are 6 parts:There are 6 parts:
1.1. Source of stimulusSource of stimulus
2.2. Stimulus – a condition that needs to be consideredStimulus – a condition that needs to be considered
3.3. Environment - what are the conditions when the stimulus Environment - what are the conditions when the stimulus occurs?occurs?
4.4. Artifact – what elements of the system are stimulated.Artifact – what elements of the system are stimulated.
5.5. ResponseResponse
6.6. Response measure – when the response occurs it should be Response measure – when the response occurs it should be measurable so that the requirement can be tested.measurable so that the requirement can be tested.
Figure 4.1Figure 4.1
– 15 – CSCE 492 Spring 2008
Availability ScenariosAvailability Scenarios
Figure 4.2 General availability scenarioFigure 4.2 General availability scenario
Figure 4.3 Example availability scenarioFigure 4.3 Example availability scenario
– 16 – CSCE 492 Spring 2008
Modifiability ScenariosModifiability Scenarios
Same general format as for availability scenarios. (4.2)Same general format as for availability scenarios. (4.2)
Figure 4.4 Example Modifiability scenarioFigure 4.4 Example Modifiability scenario
““change the UI; make the background color blue.”change the UI; make the background color blue.”
Source: developerSource: developer
Stimulus: request for change (maybe email)Stimulus: request for change (maybe email)
Artifact: the code for the UIArtifact: the code for the UI
Environment: design timeEnvironment: design time
Response: modification with no side effects madeResponse: modification with no side effects made
Response measure: three hoursResponse measure: three hours
– 17 – CSCE 492 Spring 2008
Quality Attribute Scenario GenerationQuality Attribute Scenario Generation
Architect’s Goal: generate meaningful quality attribute Architect’s Goal: generate meaningful quality attribute requirements for the systemrequirements for the system
Quality-attribute-specific tables Quality-attribute-specific tables General scenarios General scenarios System specific scenariosSystem specific scenarios
– 18 – CSCE 492 Spring 2008
Availability Scenarios in PracticeAvailability Scenarios in Practice
Availability is concerned with system failure and Availability is concerned with system failure and duration of system failures.duration of system failures.
System failure means … when the system does not System failure means … when the system does not provide the service for which it was intended.provide the service for which it was intended.
Failure vs fault – Failure vs fault – A “system failure” is observable by the system’s user A system fault may cause a “system failure” or it might be
masked.
Measuring availability?Measuring availability?
– 19 – CSCE 492 Spring 2008
Measuring AvailabilityMeasuring Availability
Mean time to failure – Mean time to failure –
Mean time to repair –Mean time to repair –
Availability = MTF / (MTF + MTR)Availability = MTF / (MTF + MTR)
How do we figure in scheduled downtime?How do we figure in scheduled downtime?
– 20 – CSCE 492 Spring 2008
Availability General Scenario GenerationAvailability General Scenario Generation
Table 4.1Table 4.1
Scenario Scenario Portion Portion
Possible ValuesPossible Values
SourceSource Internal to system or external to systemInternal to system or external to system
StimulusStimulus Crash, timing, no response, incorrect response Crash, timing, no response, incorrect response
ArtifactArtifact System’s processors, communication System’s processors, communication channels, persistent storagechannels, persistent storage
EnvironmentEnvironment Normal operation; degraded (failsafe) mode Normal operation; degraded (failsafe) mode
ResponseResponse Log the failure, notify users/operatorsLog the failure, notify users/operators
RespMeasureRespMeasure Time interval when it must be available, Time interval when it must be available, availability%, unavailability time intervalavailability%, unavailability time interval
– 21 – CSCE 492 Spring 2008
Modifiability Scenarios in PracticeModifiability Scenarios in Practice
Modifiability is about the cost of change, both in time and money. Modifiability is about the cost of change, both in time and money. (Time is money. Who said this?)(Time is money. Who said this?)
Two major concerns:Two major concerns:
1.1. What can change the artifact?What can change the artifact? Changes top the function the system computes Changes to the environment in which it operates (portability) Qualities of the system
2.2. When is the change made and who makes it?When is the change made and who makes it? In the past developers changed the code. Changes made at several levels:
User changing a screen color to her liking Modifications to source code Modifications to compile-time switches During execution
– 22 – CSCE 492 Spring 2008
Modifiability General Scenario GenerationModifiability General Scenario Generation
Table 4.2Table 4.2
Scenario Scenario Portion Portion
Possible ValuesPossible Values
SourceSource End-user, developer, system-administratorEnd-user, developer, system-administrator
StimulusStimulus Add/delete/modify functionality or quality attr. Add/delete/modify functionality or quality attr.
ArtifactArtifact System user interface, platform, environmentSystem user interface, platform, environment
EnvironmentEnvironment At runtime, compile time, build time, design-At runtime, compile time, build time, design-time time
ResponseResponse Locate places in architecture for modifying, Locate places in architecture for modifying, modify, test modification, deploys modificationmodify, test modification, deploys modification
RespMeasureRespMeasure Cost in effort, money, time, extent affects other Cost in effort, money, time, extent affects other system functions or qualitiessystem functions or qualities
– 23 – CSCE 492 Spring 2008
Performance Scenarios in PracticePerformance Scenarios in Practice
Performance is about time.Performance is about time.
Events occur and the system must respond in a timely Events occur and the system must respond in a timely fashion.fashion.
Probabilistic distribution of arrival of events. Queue of Probabilistic distribution of arrival of events. Queue of events, queue lengths …events, queue lengths …
Response time can be measured by:Response time can be measured by: Latency = Throughput = Deadlines in processing Jitter of response = variability of latency Number of events not processed (system overwhelmed) Amount of data loss when system is overwhelmed
– 24 – CSCE 492 Spring 2008
Performance General Scenario GenerationPerformance General Scenario Generation
Table 4.3Table 4.3
Scenario Scenario Portion Portion
Possible ValuesPossible Values
SourceSource A number of sources both external and internalA number of sources both external and internal
StimulusStimulus Periodic events, sporadic events, stochastic Periodic events, sporadic events, stochastic eventsevents
ArtifactArtifact System, or possibly a componentSystem, or possibly a component
EnvironmentEnvironment Normal mode; overload mode Normal mode; overload mode
ResponseResponse Process stimuli; change level of serviceProcess stimuli; change level of service
RespMeasureRespMeasure Latency, deadline, throughput, jitter, miss rate, Latency, deadline, throughput, jitter, miss rate, data lossdata loss
– 25 – CSCE 492 Spring 2008
Security Scenarios in PracticeSecurity Scenarios in Practice
Security is the ability of the system to prevent or resist Security is the ability of the system to prevent or resist unauthorized access while providing access to unauthorized access while providing access to legitimate users.legitimate users.
Attack – is an attempt to breach securityAttack – is an attempt to breach security Unauthorized login Sniffing data on communication channel Unauthorized access/modification of data Denial of services attacks – crash the system
– 26 – CSCE 492 Spring 2008
Aspects of System SecurityAspects of System Security
Security can be characterized by providing:Security can be characterized by providing: Nonrepudiation – a transaction cannot be denied Confidentiality – data or services are protected from
unauthorized access Integrity - data or services are delivered as intended Assurance – (authentication) the parties to the transaction
are who they say they are Availability - the system will be available for legitimate use;
no DOS. Auditing – the system tracks activities at several levels
sufficient to reconstruct them
– 27 – CSCE 492 Spring 2008
Security General Scenario GenerationSecurity General Scenario Generation
Table 4.4Table 4.4
Scenario Scenario Portion Portion
Possible ValuesPossible Values
SourceSource User/system who is legitimate/imposter/unknown User/system who is legitimate/imposter/unknown with full/limited accesswith full/limited access
StimulusStimulus Attempt to display/modify data; access services Attempt to display/modify data; access services
ArtifactArtifact System services, dataSystem services, data
EnvironmentEnvironment Normal operation; degraded (failsafe) mode Normal operation; degraded (failsafe) mode
ResponseResponse Authenticate user; hide identity of user; Authenticate user; hide identity of user; grant/block access …grant/block access …
RespMeasureRespMeasure Time /effort/resources to circumvent security Time /effort/resources to circumvent security measures with probability of successmeasures with probability of success
– 28 – CSCE 492 Spring 2008
Testability Scenarios in PracticeTestability Scenarios in Practice
Software testability refers to the ease with which the Software testability refers to the ease with which the software can be made to demonstrate its faults or software can be made to demonstrate its faults or lack thereof.lack thereof.
40% of the cost of developing systems is taken up by 40% of the cost of developing systems is taken up by testing (CSCE 747)testing (CSCE 747)
If the architect can reduce this cost through design If the architect can reduce this cost through design then the payoff is substantial.then the payoff is substantial.
Measures?Measures? Probability that a fault will be revealed by test suite (or test)
To be testable the system must control inputs and by To be testable the system must control inputs and by able to observe outputsable to observe outputs
Test harness – test suites; regression suitesTest harness – test suites; regression suites
– 29 – CSCE 492 Spring 2008
Testability General Scenario GenerationTestability General Scenario Generation
Table 4.5Table 4.5
Scenario Scenario Portion Portion
Possible ValuesPossible Values
SourceSource Unit developer, increment integrator, system Unit developer, increment integrator, system verifier, client acceptance tester, system userverifier, client acceptance tester, system user
StimulusStimulus Analysis, architecture, design, class, subsystem Analysis, architecture, design, class, subsystem integration, system deliveredintegration, system delivered
ArtifactArtifact Piece of design, piece of code, complete systemPiece of design, piece of code, complete system
EnvironmentEnvironment At design time, at development time, at compile At design time, at development time, at compile time, at deployment timetime, at deployment time
ResponseResponse Provide access to state data values, observes Provide access to state data values, observes results, comparesresults, compares
RespMeasureRespMeasure Coverage; prob of failure, time to perform tests, Coverage; prob of failure, time to perform tests, length of time to prepare test environmentlength of time to prepare test environment
– 30 – CSCE 492 Spring 2008
Usability Scenarios in PracticeUsability Scenarios in Practice
Usability is how easy is it for the user to accomplish Usability is how easy is it for the user to accomplish tasks and what support the system provides for the tasks and what support the system provides for the user to accomplish this.user to accomplish this.
Dimensions:Dimensions: Learning system features Using the system efficiently Minimizing the impact of errors Adapting the system to the user’s needs Increasing confidence and satisfaction
Usability Mea Culpa – p 92Usability Mea Culpa – p 92
– 31 – CSCE 492 Spring 2008
Testability General Scenario GenerationTestability General Scenario Generation
Table 4.6Table 4.6
Scenario Scenario Portion Portion
Possible ValuesPossible Values
SourceSource End userEnd user
StimulusStimulus Wants to: learn system, use system, recover from Wants to: learn system, use system, recover from errors, adapt system, feel comfortableerrors, adapt system, feel comfortable
ArtifactArtifact SystemSystem
EnvironmentEnvironment At runtime, or configure time, install-timeAt runtime, or configure time, install-time
ResponseResponse
RespMeasureRespMeasure Task time, number of errors, number of tasks Task time, number of errors, number of tasks accomplished, user satisfaction, gain of user accomplished, user satisfaction, gain of user knowledge, amount of time. data lost knowledge, amount of time. data lost
– 32 – CSCE 492 Spring 2008
Usability Scenarios in Practice: ResponsesUsability Scenarios in Practice: Responses
System responses to stimuli:System responses to stimuli:
To learn systemTo learn system Help system is context sensitive Interface familiar, consistent
To use system efficientlyTo use system efficiently Reuse of command or data already entered Navigation support, comprehensive searching
To recover from errorsTo recover from errors Undo, cancel, recover from system failures forgotten passwords
To adapt system: customize the system to user likingTo adapt system: customize the system to user liking
To feel comfortableTo feel comfortable
– 33 – CSCE 492 Spring 2008
Quality Attribute StimuliQuality Attribute Stimuli
AttributeAttribute StimulusStimulus
AvailabilityAvailability Unexpected event, nonoccurrence of expected Unexpected event, nonoccurrence of expected eventevent
ModifiabilityModifiability Request to add/delete/modify functionality, Request to add/delete/modify functionality, platform, quality-attribute or capacityplatform, quality-attribute or capacity
PerformancePerformance Periodic, stochastic or sporadicPeriodic, stochastic or sporadic
SecuritySecurity Attempt to access/display/modify information or Attempt to access/display/modify information or resources; reduce availability of systemresources; reduce availability of system
TestabilityTestability Completion of phase of system developmentCompletion of phase of system development
UsabilityUsability User wants to: learn, use, minimize impact or User wants to: learn, use, minimize impact or errors, adapt the system, feel comfortableerrors, adapt the system, feel comfortable
– 34 – CSCE 492 Spring 2008
Business QualitiesBusiness Qualities
Time to marketTime to market
Cost and benefitCost and benefit
Projected lifetime of systemProjected lifetime of system
Targeted marketTargeted market
Rollout scheduleRollout schedule
Integration with legacy systemsIntegration with legacy systems
– 35 – CSCE 492 Spring 2008
Architectural QualitiesArchitectural Qualities
Conceptual integrity – do similar things in similar waysConceptual integrity – do similar things in similar ways
“I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.” Brooks Mythical Man-Month 1975
Correctness and completenessCorrectness and completeness
BuildabilityBuildability
– 36 – CSCE 492 Spring 2008
ReferencesReferences
1. ACM Digital Library http://www.acm.org/ You You have access to this from any USC (129.252.x.y) IP have access to this from any USC (129.252.x.y) IP address. Google “ACM digital library”address. Google “ACM digital library”
Recommended