1 / 36

Lecture 7 Quality Attributes = Nonfunctional Req.

Lecture 7 Quality Attributes = Nonfunctional Req. CSCE 492 Software Engineering. Topics Quality Attributes Readings:. January 29, 2008. Overview. Last Time Documenting Software Architecture Rational Unified Process (RUP) - Kruchten Today’s Lecture

Anita
Download Presentation

Lecture 7 Quality Attributes = Nonfunctional Req.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

  3. Creating An Architecture • “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? • His/her own? • Customer? • Can’t we all just agree? (paraphrasing Rodney King) • Can we move to a more objective less subjective def.? • We will use quality attribute scenarios

  4. 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

  5. Qualities • Examples • Usability • Modifiability • Performance • Security • Availability • Testability • On cost, on schedule • Cost and benefit • Integration with legacy systems • Functionality?

  6. Functionality vs Quality • Functionality and other quality attributes are orthogonal. • Orthogonal ? • At least independent? • Note functionality does not imply anything about others! • What is functionality anyway? • 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.

  7. Architecture and Quality Attributes • Achieving quality attributes must be considered thru: • Design • Implementation, and • Deployment • 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!

  8. Usability: Arch. Vs Non-Arch Aspects • 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 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. Modifiability: Arch. Vs Non-Arch Aspects • Architectural aspects of Modifiability: • How functionality is partitioned • Non-architectural aspects of Modifiability : • 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.

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

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

  12. Types of Quality Attributes • Qualities of the system • Availability • Performance • Security • Testability • Usability • Business qualities • Time-to-market • Cost and benefit • Projected lifetime • Overall architectural qualities. • Conceptual integrity • Correctness and completeness • Constructability

  13. 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. • 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 say a system is modifiable, it needs to be measurable so we can make comparisons, judgments.

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

  15. Availability Scenarios • Figure 4.2 General availability scenario • Figure 4.3 Example availability scenario

  16. 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.” • Source: developer • Stimulus: request for change (maybe email) • Artifact: the code for the UI • Environment: design time • Response: modification with no side effects made • Response measure: three hours

  17. Quality Attribute Scenario Generation • Architect’s Goal: generate meaningful quality attribute requirements for the system • Quality-attribute-specific tables  General scenarios  System specific scenarios

  18. 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 – • 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?

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

  20. Availability General Scenario Generation • Table 4.1

  21. 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: • 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 • 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. Modifiability General Scenario Generation • Table 4.2

  23. 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: • 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. Performance General Scenario Generation • Table 4.3

  25. 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 • Unauthorized login • Sniffing data on communication channel • Unauthorized access/modification of data • Denial of services attacks – crash the system

  26. Aspects of System Security • 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. Security General Scenario Generation • Table 4.4

  28. 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 then the payoff is substantial. • Measures? • 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

  29. Testability General Scenario Generation • Table 4.5

  30. 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: • 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

  31. Testability General Scenario Generation • Table 4.6

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

  33. Quality Attribute Stimuli

  34. Business Qualities • Time to market • Cost and benefit • Projected lifetime of system • Targeted market • Rollout schedule • Integration with legacy systems

  35. Architectural Qualities • Conceptual 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 completeness • Buildability

  36. References • ACM Digital Libraryhttp://www.acm.org/You have access to this from any USC (129.252.x.y) IP address. Google “ACM digital library”

More Related