CSCE 492 Software Engineering Lecture 7 Quality Attributes

CSCE 492 Software Engineering Lecture 7 Quality Attributes = Nonfunctional Req. Topics n Quality Attributes Readings: January 29, 2008

Overview Last Time n Documenting Software Architecture n Rational Unified Process (RUP) - Kruchten Today’s Lecture n Quality Attributes = Nonfunctional requirements References: n Documenting Software Architectures: Views and Beyond, 2002, Addison-Wesley, SEI series. Next Time: n – 2– Quality Attributes = Nonfunctional requirements CSCE 492 Spring 2008

Creating An Architecture “Beauty is in the eye of the beholder” n Booth Tarkington (1838– 1918). The Magnificent Ambersons. 1918. So whose concept of “Quality” does the architect use? n n n His/her own? Customer? Can’t we all just agree? (paraphrasing Rodney King) Can we move to a more objective less subjective def. ? n – 3– We will use quality attribute scenarios CSCE 492 Spring 2008

Understanding Quality The surest foundation of a manufacturing concern is quality. After that, and a long way after, comes cost. Andrew Carnegie Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution… Will A. Foster – 4– CSCE 492 Spring 2008

Qualities Examples 1. Usability 2. Modifiability 3. Performance 4. Security 5. Availability 6. Testability 7. On cost, on schedule 8. Cost and benefit 9. Integration with legacy systems 10. Functionality? – 5– CSCE 492 Spring 2008

Functionality vs Quality Functionality and other quality attributes are orthogonal. n Orthogonal ? n At least independent? Note functionality does not imply anything about others! n What is functionality anyway? n The system works as intended. If functionality was the only concern we could implement as one large module in Cobol or even assembly language. So functionality is a prime goal, but it should not be the only goal. – 6– CSCE 492 Spring 2008

Architecture and Quality Attributes Achieving quality attributes must be considered thru: n Design n Implementation, and Deployment n No attribute is entirely dependent on design or other phases. Satisfactory inclusion of quality attributes means you must get the big picture ( architecture) and the details (implementation) right! – 7– CSCE 492 Spring 2008

Usability: Arch. Vs Non-Arch Aspects Non-architectural aspects of usability: n Making the user-interface clear and easy to use n Should we use radio button or check box? What font? All a crucial to end-user usabilty, but they are not architectural n n Examples of architectural aspects of usability n n n – 8– Whether the system provides an “undo’ capability to the user? Can we – reuse data previously entered? These architectural because they are going to require the cooperation of several elements. CSCE 492 Spring 2008

Modifiability: Arch. Vs Non-Arch Aspects Architectural aspects of Modifiability: n How functionality is partitioned Non-architectural aspects of Modifiability : n Coding techniques used within a module Note: in spite of having the perfect decomposition, the implementation may be not be maintainable. You must be concerned about modifiability at all levels, all the time. – 9– CSCE 492 Spring 2008

Performance: Arch. Vs Non-Arch Aspects The performance of a systems depends on both architectural and non-architecture aspects. Architectural aspects of Performance: n n n Communication between components Partially on partitioning of functionality Allocation of resources Non-architectural aspects of Performance: n n – 10 – Choice of algorithms How these algorithms are coded CSCE 492 Spring 2008

Architectural Vs Non-Architectural 1. Architecture is critical to achieving quality attributes. 2. Architecture alone cannot achieve these qualities. 3. Quality attributes can never be achieved in isolation. 4. The achievement of one attribute may negatively (or perhaps positively) influence the achievement of another. 5. E. g. , security and reliability, (or security and usability or performance and modifiability) are often at cross–purposes – 11 – CSCE 492 Spring 2008

Types of Quality Attributes 1. Qualities of the system n Availability Performance n Security n Testability Usability n n 2. Business qualities n n n Time-to-market Cost and benefit Projected lifetime 3. Overall architectural qualities. n n n – 12 – Conceptual integrity Correctness and completeness Constructability CSCE 492 Spring 2008

System Quality Attributes Been a focus of the software industry since the 1970’s Each attribute ( usability, performance, reliability) has its own focus group of researchers, conferences, journals, terminology etc. n n n Usability (SIGCHI) - http: //www. upassoc. org/conf 2003/ Performance (SIGMETRIC) http: //www. sigmetrics. org/conferences. html Reliability - http: //www. issre 2001. org/ Attributes are not “operational”. What does it mean to say a system is modifiable, it needs to be measurable so we can make comparisons, judgments. – 13 – CSCE 492 Spring 2008

Quality Attribute Scenarios Quality Attribute Scenario is a quality-attribute-specific requirement. There are 6 parts: 1. Source of stimulus 2. Stimulus – a condition that needs to be considered 3. Environment - what are the conditions when the stimulus occurs? 4. Artifact – what elements of the system are stimulated. 5. Response 6. Response measure – when the response occurs it should be measurable so that the requirement can be tested. 7. Figure 4. 1 – 14 – CSCE 492 Spring 2008

Availability Scenarios Figure 4. 2 General availability scenario Figure 4. 3 Example availability scenario – 15 – CSCE 492 Spring 2008

Modifiability Scenarios Same general format as for availability scenarios. (4. 2) Figure 4. 4 Example Modifiability scenario “change the UI; make the background color blue. ” l Source: developer l Stimulus: request for change (maybe email) l Artifact: the code for the UI l Environment: design time l Response: modification with no side effects made l Response measure: three hours – 16 – CSCE 492 Spring 2008

Quality Attribute Scenario Generation Architect’s Goal: generate meaningful quality attribute requirements for the system Quality-attribute-specific tables General scenarios System specific scenarios – 17 – CSCE 492 Spring 2008

Availability Scenarios in Practice Availability is concerned with system failure and duration of system failures. System failure means … when the system does not provide the service for which it was intended. Failure vs fault – n n 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? – 18 – CSCE 492 Spring 2008

Measuring Availability Mean time to failure – Mean time to repair – Availability = MTF / (MTF + MTR) How do we figure in scheduled downtime? – 19 – CSCE 492 Spring 2008

Availability General Scenario Generation Table 4. 1 Scenario Portion Source Possible Values Stimulus Crash, timing, no response, incorrect response Internal to system or external to system Artifact System’s processors, communication channels, persistent storage Environment Normal operation; degraded (failsafe) mode Response Log the failure, notify users/operators Resp. Measure Time interval when it must be available, availability%, unavailability time interval – 20 – CSCE 492 Spring 2008

Modifiability Scenarios in Practice Modifiability is about the cost of change, both in time and money. (Time is money. Who said this? ) Two major concerns: 1. What can change the artifact? n n n Changes top the function the system computes Changes to the environment in which it operates (portability) Qualities of the system 2. When is the change made and who makes it? n n In the past developers changed the code. Changes made at several levels: User changing a screen color to her liking l Modifications to source code l Modifications to compile-time switches l During execution l – 21 – CSCE 492 Spring 2008

Modifiability General Scenario Generation Table 4. 2 Scenario Portion Source Possible Values Stimulus Add/delete/modify functionality or quality attr. Artifact System user interface, platform, environment End-user, developer, system-administrator Environment At runtime, compile time, build time, designtime Response Locate places in architecture for modifying, modify, test modification, deploys modification Resp. Measure Cost in effort, money, time, extent affects other system functions or qualities – 22 – CSCE 492 Spring 2008

Performance Scenarios in Practice Performance is about time. Events occur and the system must respond in a timely fashion. Probabilistic distribution of arrival of events. Queue of events, queue lengths … Response time can be measured by: n n n – 23 – 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 CSCE 492 Spring 2008

Performance General Scenario Generation Table 4. 3 Scenario Portion Source Possible Values Stimulus Periodic events, sporadic events, stochastic events System, or possibly a component Artifact A number of sources both external and internal Environment Normal mode; overload mode Response Process stimuli; change level of service Resp. Measure Latency, deadline, throughput, jitter, miss rate, data loss – 24 – CSCE 492 Spring 2008

Security Scenarios in Practice Security is the ability of the system to prevent or resist unauthorized access while providing access to legitimate users. Attack – is an attempt to breach security n Unauthorized login Sniffing data on communication channel Unauthorized access/modification of data n Denial of services attacks – crash the system n n – 25 – CSCE 492 Spring 2008

Aspects of System Security can be characterized by providing: n Nonrepudiation – a transaction cannot be denied n 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 n n – 26 – CSCE 492 Spring 2008

Security General Scenario Generation Table 4. 4 Scenario Portion Source Possible Values Stimulus User/system who is legitimate/imposter/unknown with full/limited access Attempt to display/modify data; access services Artifact System services, data Environment Normal operation; degraded (failsafe) mode Response Authenticate user; hide identity of user; grant/block access … Resp. Measure Time /effort/resources to circumvent security measures with probability of success – 27 – CSCE 492 Spring 2008

Testability Scenarios in Practice Software testability refers to the ease with which the software can be made to demonstrate its faults or lack thereof. 40% of the cost of developing systems is taken up by testing (CSCE 747) If the architect can reduce this cost through design the payoff is substantial. Measures? n Probability that a fault will be revealed by test suite (or test) To be testable the system must control inputs and by able to observe outputs Test harness – test suites; regression suites – 28 – CSCE 492 Spring 2008

Testability General Scenario Generation Table 4. 5 Scenario Portion Source Stimulus Artifact Possible Values Unit developer, increment integrator, system verifier, client acceptance tester, system user Analysis, architecture, design, class, subsystem integration, system delivered Piece of design, piece of code, complete system Environment At design time, at development time, at compile time, at deployment time Response Provide access to state data values, observes results, compares Resp. Measure Coverage; prob of failure, time to perform tests, length of time to prepare test environment – 29 – CSCE 492 Spring 2008

Usability Scenarios in Practice Usability is how easy is it for the user to accomplish tasks and what support the system provides for the user to accomplish this. Dimensions: n n n 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 92 – 30 – CSCE 492 Spring 2008

Testability General Scenario Generation Table 4. 6 Scenario Portion Source Possible Values Stimulus Artifact Wants to: learn system, use system, recover from errors, adapt system, feel comfortable System Environment At runtime, or configure time, install-time End user Response Resp. Measure Task time, number of errors, number of tasks accomplished, user satisfaction, gain of user knowledge, amount of time. data lost – 31 – CSCE 492 Spring 2008

Usability Scenarios in Practice: Responses System responses to stimuli: To learn system n n Help system is context sensitive Interface familiar, consistent To use system efficiently n n Reuse of command or data already entered Navigation support, comprehensive searching To recover from errors n n Undo, cancel, recover from system failures forgotten passwords To adapt system: customize the system to user liking To feel comfortable – 32 – CSCE 492 Spring 2008

Quality Attribute Stimuli Attribute Stimulus Availability Unexpected event, nonoccurrence of expected event Modifiability Request to add/delete/modify functionality, platform, quality-attribute or capacity Performance Periodic, stochastic or sporadic Security Testability Usability – 33 – Attempt to access/display/modify information or resources; reduce availability of system Completion of phase of system development User wants to: learn, use, minimize impact or errors, adapt the system, feel comfortable CSCE 492 Spring 2008

Business Qualities Time to market Cost and benefit Projected lifetime of system Targeted market Rollout schedule Integration with legacy systems – 34 – CSCE 492 Spring 2008

Architectural Qualities Conceptual integrity – do similar things in similar ways n “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 completeness Buildability – 35 – CSCE 492 Spring 2008

References 1. ACM Digital Library http: //www. acm. org/ You have access to this from any USC (129. 252. x. y) IP address. Google “ACM digital library” – 36 – CSCE 492 Spring 2008