Quality Attributes in Software Architecture

1. Quality Attributes in Software Architecture

2. Quality Attributes in Software Architecture Nov 2011 Gang Tao

3. Levels of Requirement Business Requirements Vision and Scope Documents User Requirements Use Cases Functional Requirements Quality Attributes Other Nonfunctional Requirements Software Requirements Specification Confidential

4. Quality Attributes Confidential

5. Responsiveness

6. Responsiveness • Responsiveness is defined as how quickly a system responds to user input. • Long delays can be a major cause of user frustration, or let the user believe the system is broken or that a command or input has been ignored. • Responsiveness is not same as performance. Confidential

7. Responsive Matters Confidential

8. Responsiveness • All Operations Must Be Responsive Click Me Under normal IO load, any operation must return to the user within 3 seconds. Confidential

9. A Case Study • getVersion() methods cause serious performance downgrade. Confidential

10. What causes the performance issue? • Complexity • Indirection • Repetitions • Bad Design • I/O • … … Confidential

11. Price of Optimization • Loss Readability • Increase Complexity • Hard to maintain and extend • Introduce conflict • … … Confidential

12. SAP Standard Reference Confidential

13. Scalability

14. Scalability • Scalability refers to a systems ability to handle increased adversity in its environment in a manner that is graceful and predictable. • Adversity comes in two dimensions: • Increased managed content • Decreased system resources Confidential

15. Scale Up VS Scale Out Confidential

16. Scalability Considerations • Increased Managed Content Must Scale Appropriately • Maintain Viability as System Resources Decrease • UI Data Presentation Scaling • Load Sharing Considerations Confidential

17. Usability

18. Usability Confidential

19. Usability • Usability is the customer’s ability to get work done with the system in an efficient and pleasing manner. • A usable system should build on skills a user already has and not require new or unique knowledge to use the system. • Each new function the user encounters should follow a similar pattern so that once a user has learned one function others are intuitive to learn. Confidential

20. Usability Notions • More efficient to use—takes less time to accomplish a particular task • Easier to learn—operation can be learned by observing the object • More satisfying to use Confidential

21. Usability Composition • Learnability • How easy is it for users to accomplish basic tasks the first time they encounter the design? • Efficiency • Once users have learned the design, how quickly can they perform tasks? • Memorability • When users return to the design after a period of not using it, how easily can they re establish proficiency? • Errors • How many errors do users make, how severe are these errors, and how easily can they recover from the errors? • Satisfaction • How pleasant is it to use the design? Confidential

22. Rule One – Don’t Make Me Think Confidential

23. Rule Two - Know Your Users Confidential

24. Rule Three – Be Consistent • Be Consistent • Things that look the same should act the same. • Things that look different should act different. Confidential

25. Usability VS. User Experiences • Free Discussion Confidential

26. Case Study & Samples Confidential

27. Some References of Usability • [1] 《Designing • [2] 《Usability • [3] 《The • [4] 《About • [5] 《Designing Web Interfaces》，中文版名为《Web界面设计》 • [6] 《Designing the Obvious》，中文版名为《一目了然——Web软件显性设计之路》 • [7] 《Communicating • [8] 《Don’t • [9] 《Designing • [10] 《UI • [11] 《The Interfaces》，中文版名为《Designing Interfaces中文版》 Engineering》，中文版名为《可用性工程》 Design of Everyday Things》，中文版名为《设计心理学》 Face 3》，中文版名为《交互设计精髓》 Design》，中文版名为《设计沟通十器》 Make Me Think》，中文版名为《点石成金：访客至上的网页设计秘笈》 From Both Sides of the Screen》，内外兼修的设计，尚未出版文版 Design for Programmers》，程序员之用户界面设计，尚未出版中文版 Inmates are Running the Asylum》，中文版名为《交互设计之路——让高科技产品回归人性》 Confidential

28. Security

29. Security • Security is defined as being protected against danger or loss Confidential

30. Security Model Authentication Authorization Audit Encryption Confidential

31. Refereneces • OWASP Top Ten • Seven Pernicious Kingdoms • Sans Top 25 • Common Weakness Enumerations Confidential

32. Accessibility

33. Accessibility • “accessibility“ refers to the possibility for everyone, including and especially people with disabilities, to access and use technology and information products. Confidential

34. Case Study : Choose the right color Confidential

35. Serviceability

36. Serviceability • Serviceability refers to the ability to monitor systems, identify issues, perform root cause analysis, and provide maintenance in order to solve a problem and restore the system to a functioning state. Confidential

37. Serviceability • Diagnostic Infrastructure Should Not Be Intrusive • Issues that arise on a customer site that require engineering involvement should be able to be diagnosed without requiring that the affected system gets taken off line, new binaries get installed, or a debugger gets installed. Confidential

38. Serviceability • Solutions Must Support a Customer-Centric Service Model • Common issues are able to be root-caused and addressed by customers or entry level technical service representatives over the phone. • Meaningful log messages, alerts, and trouble-shooting trees all must be considered to be mandatory and complementary components for servicing a system. Confidential

39. Cost of Service Customer Self Service Web Remote Support, BBS/MSN Phone/Email Support On Site Support Confidential

40. Extensibility

41. Extensibility • With extensibility, the design and implementation takes into consideration future growth. Confidential

42. Extensibility Considerations • Design and Implement With Scale in Mind • Producers of Interfaces Must Support the Ability to Minimize the Amount of Data Returned to a Client • Clients Should Minimize Data Traffic and Network Requests • Business Logic Must Be Centralized • Revision Compatibility Focus Confidential

43. Distributability

44. Distributability • Distributability is defined as the ability to manage a group of systems as one unit and to perform management from any location in the network. • Decide whether a component will run in process, in a separate process on the same machine, or on a remote machine. Confidential

45. Layers and Tiers • Layers are a means of logical separation, and are an architectural pattern to separate concerns • Tiers are the physical separation of an application. Confidential

46. Distributed Architecture • Web Service • CORBA Confidential

47. Maintainability

48. Maintainability • Maintainability means the ease with which a system can be modified in order to correct defects, meet new functionality, make maintenance easier, or cope with a changing environment. Confidential

49. Maintainability Tips • Adhere to Coding Standards • Avoid duplication • Story Telling with your code • Keep your code simple Confidential

50. Portability

51. Portability • Portability is defined as the ability to reuse features and utility source code, across multiple Operating systems. • By having an OS abstraction layer that implements platform specific utilities, such as locks and shared memory. • Can also be achieved by compiling different segments of code, depending on the platform the software is to be run on. Confidential

52. Reliability

53. Reliability (Availability) • Reliability is defined as the ability of a system, to function correctly, under any reasonable circumstance. • Reasonable can include adverse situations, in which unexpected (but supported) usage occurs. • For Storage systems, this includes putting extreme I/O load on the system, but expecting the system to be manageable. Confidential

54. Availability MTBF – Mean Time Between Failure MTTR – Mean Time to Recovery Availability= MTBF/(MTBF+MTTR) Confidential

55. Reliability Consideration • All errors must be handled in a graceful manner • The Storage System must be manageable, without external dependencies. • There should be NO single point of failure Confidential

56. Testability

57. Testability • Software testability is the degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context. Confidential

58. Testability of Software Components • Controllability: The degree to which it is possible to control the state of the component under test (CUT) as required for testing. • Observability: The degree to which it is possible to observe (intermediate and final) test results. • Isolateability: The degree to which the component under test (CUT) can be tested in isolation. • Separation of concerns: The degree to which the component under test has a single, well defined responsibility. • Understandability: The degree to which the component under test is documented or self-explaining. • Automatability: The degree to which it is possible to automate testing of the component under test. • Heterogeneity: The degree to which the use of diverse technologies requires to use diverse test methods and tools in paralle Confidential

59. Testability of Requirements • consistent • complete • unambiguous • quantitative • verifiable in practice Confidential

60. Compatibility

61. Compatibility • Backward • Forward Confidential

62. Summary

63. Quality Attributes Relationship Matrix Negative Impact Responsive ness No Impact Positive Impact Usability Extensibility Security Reliability Responsive ness Usability Extensibility Security Reliability Confidential

64. Quality Model • McCall/GE Quality Model • ISO 9126 Confidential

65. Business Qualities • Time to Market • Cost and Benefit • Project Lifetime • Target Market • Rollout schedule • Integration with Legacy System Confidential

66. Symptoms of Bad Architecture • Rigidity • the system is hard to change because every change forces many other changes. • Fragility • changes cause the system to break in conceptually unrelated places. • Immobility • it’s hard to disentangle the system into reusable components. • Viscosity • doing things correctly is harder than doing things incorrectly. • Opacity • the code is hard to read and understand. It does not express its intent well. Confidential