SW Architecture | Quality Attributes

In the environment, the source throws the stimulus and hits the system in the artifact

IMPORTANT

• One stimulus per scenario
• One environment per scenario
• One artifact per scenario
• Multiple response measures are OK

• Modifiability is about the cost of change, both in time and money. Performance is about timeliness. Events occur and the system must respond in a timely fashion.
• Testability refers to the ease with which the software can be made to demonstrate its faults or lack thereof. To be testable the system must control inputs and be able to observe outputs
• Maintainability is the ease with which a product can be maintained in order to isolate and correct defects, prevent unexpected breakdowns, meet new requirements
• Usability is how easy it is for the user to accomplish tasks and what support the
• system provides for the user to accomplish this. 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
• Availability is concerned with system failure and duration of system failures. System failure means un-readiness for correct service, when the system does not provide the service for which it was intended
• Reliability: the ability of a system or component to function under stated conditions for a specified period of time (=continuity of correct service)
• Dependability: availability + reliability + maintainability Safety absence of catastrophic consequences on the users or the environment
• Security is the ability of the system to prevent or resist unauthorized access while providing access to legitimate users. An attack is an attempt to breach security

1. Availability Scenario
2. Modifiability Scenario
3. Performance Scenario
4. Security Scenario
5. Testability Scenario
6. Usability Scenario
7. Scalability Scenario
8. Portability Scenario

• “What’s the probability that the system works when I need it?”
• Concerns: mean time to failure
  • fault detection
  • repair time
  • fault masking
  • ..

availability =  mean time to failure / (mean time to failure + mean time to repair)

General Availability Scenario

Sample Availability Scenario

Source	Stimulus	Environment	Response	Measure
	Fault:		detect failure and do one or more of:
Internal to system	Crash	Normal operation	Prevent the failure	Time interval available
External to system	Omission	Startup	Log the failure	Availability %
	Timing	Shutdown	Notify users/operators	Detection time
	No response	Repair mode	Disable source of failure	Repair time
	Incorrect response	Degraded (failsafe) mode	Temporarily unavailable	Degraded mode time interval
		Overload protection	Continue (normal/degraded)	Unavailability time interval

• What can change?
  • platforms
  • environment
  • requirements:
    • performance
    • reliability
    • capacity
• When is the change made?

Reinstallation, plug-in, configuration, platform change.

General Modifiability Scenario

Sample Modifiability Scenario

Source	Stimulus	Environment	Response	Measure
	Add/delete/modify:			costs
End user	Functionality	Runtime	Make modification	Cost in effort
Developer	Quality attribute	Compile time	Test modification	Cost in money
System administrator	Capacity or technology	Build time	Deploy modification	Cost in time
		Initiation time		Cost in number, size, complexity of affected artifacts
		Design time		Extent affects other system functions or qualities
				New defects introduced

• Timing in the system
• Response time

General Modifiability Scenario

Sample Modifiability Scenario

Source	Stimulus	Environment	Response	Measure
	arrival of
Internal to the system	Periodic events	Normal mode	Process events	Latency
External to the system	Sprodaic events	Overload mode	Change levels of service	Deadline
	Bursty events	Reduced capacity mode		Throughput
	Stochatics events	Emergency mode		Jitter
		Peak mode		Miss rate
				Data loss

General Security Scenario

Sample Security Scenario

Source	Stimulus	Environment	Response	Measure
Identified user or system	Attempt to display data	Normal mode	Process events	Latency
Unknown user or system	Attempt to delete data	Overlaod mode	Change level of service	Deadline
Hacker from outside the organization	Attempt to modify data	Reduced capacity mode	authenticates the user	Throughput
Hacker from inside the organization	Access system services	Emergency mode	hides identity of the user	Jitter
authorized – not authorized	Change system’s behavior	Peak mode	blocks access to data/services	Miss rate
access to – limited resources – vast resources	Reduce system availability	online – offline		Data loss
		connected – disconnected		effort to circumvent security
		firewall or open		probability of attack detection

• How easy will it be to test the system “40% of system cost use to be testing”
• How likely to find and eliminate errors

General Testability Scenario

Sample Testability Scenario

Source	Stimulus	Environment	Response	Measure
Unit tester	Execution of tests due to completion code increment	Design time	Execute test suite & capture results	Effort to find fault
System tester		Development time	Capture causes of fault	Effort to achieve coverage %
Integration tester		Compile time	Control & monitor state of the system	Probability to fault being revealed in next test
Acceptance tester		Integration time		Time to perform tests
End user		Deployment time		Efforts to detect faults
Automated testing tools		Runtime		Length of longest dependency chain
				Time to prepare test environment
				Reduction in risk exposure

• How to learn to use the system
• How to use the system efficiently
• Minimize the impact of user error
• System adaptability to user needs.
• User confidence

General Usability Scenario

Sample Usability Scenario

Source	Stimulus	Environment	Response	Measure
	wants to
End user (possibly special role)	Use the system efficiently	Runtime	Provide features needed	Task time
	Learn to use the system	Configuration time	Anticipate the user’s needs	Number of errors
	Minimize impact of errors		to support learning help system ..	Number of task accomplished
	Adapt the system		to support efficient use – aggregation of commands/data – reuse of entered data/command	User satisfaction
	Configure the system		to minimize impacts of errors -undo /cancel /recovery / recognition of user error ..	Gain of user knowledge
	User feels comfortable		to adapt system – customizability	Ratio of successful operation to total operations
			to feel comfortable – display system state	Amount of time/data lost when error occurs

• Time to market
• Cost and benefit
• Projected system lifetime
• Targeted market
• Rollout schedule
• Integration with legacy systems

• Conceptual integrity
• Correctness and completeness
• Buildability