Quality Attributes Workshop – ppt video online download

Presentation on theme: “Quality Attributes Workshop”— Presentation transcript:

1
Quality Attributes Workshop
UNIT 2 Quality Attributes Workshop

2
Syllabus Quality Attribute Workshop Documenting Quality Attributes
Six Part Scenario Case Studies

3
Quality Attributes Common Quality Attributes ( 7 Types)
Design qualities Runtime qualities System qualities User qualities Non-runtime qualities Architecture qualities Business qualities

4
21 Quality Attributes in 7 types
Design Quality Attributes Conceptual Integrity: Maintainability: Reusability: Runtime qualities Interoperability: Manageability: Reliability: Scalability: Performance: Security: Availability System qualities Supportability: Testability User qualities Usability Non-runtime qualities Portability: Reusability: Integrability: Modifiability: Architecture qualities Supportability: Testability: Business qualities Cost and schedule: Marketability:

5
Why SW Quality Assessment is difficult ?
Software specifications are usually incomplete and often inconsistent There is no clear definition on: customer quality requirements efficiency, reliability, developer quality requirements maintainability, reusability, Some quality requirements are hard to specify in an unambiguous way directly measurable qualities (e.g., errors/KLOC) indirectly measurable qualities (e.g., usability) Quality is not just about reducing defects!

6
Quality Attribute Workshop (QAW)
These 21 quality attributes determines and measures the fitness and suitability of a SW product. ( in addition to functionality, tech and business viability) QAW is a facilitated method that engages system stakeholders early in the life cycle to discover the driving quality attributes of a software-intensive system. QAW facilitates questions and concerns elicited from various stakeholders associated with the system

7

QAW Benefits Opportunities for communication among the architecture team and the other stakeholders. Scenario and test case generation can be done before the architecture is in place. The test cases provide a mechanism for analyzing the conflicts / consequences of architectural decisions. The results of the analysis provide a mechanism for improving the architecture before presenting it to stakeholders. The process gives the sponsor or other significant stakeholders early insight into the capabilities of the architecture team, and builds confidence in the architecture team’s understanding of the challenges involved with developing the system.

8
QAW benefits… Update the architectural vision
Refine system and SW requirements Guide development of prototype Exercise simulations Understand and clarify architectural drivers Describe operation of a system Influence the order the architecture is developed

9

What is QAW ? It’s a facilitated early invention method used to generate , prioritize and refine attribute scenarios before architecture is made QAW elicites and documents quality attributes Refined scenarios lead to sequence and state diagrams.

10
QAW Focus System-centric Stakeholder focused Scenario based
Used before the software architecture has been created

11
QAW Process 2. Business/Programmatic Presentation
External team facilitates meeting Stakeholders ( Business, Technology, Functionality, Quality ) Architects QAW Steps 1. Introductions and QAW Presentation 2. Business/Programmatic Presentation 3. Architecture Plan Presentation 4. Identification of Architectural Drivers 5. Scenario Brainstorming 6. Scenario Consolidation 7. Scenario Prioritization 8. Scenario Refinement

12
Step 1. Introductions and QAW Presentation
QAW facilitators ( external team) introduce themselves to the stakeholders. Stakeholders introduce themselves and briefly describe their background and relationship to the system. QAW facilitators describe the motivation for the QAW and explain each step of the method

13
Step 2. Business Presentation
A representative from the system stakeholder community ( Business consultant for investor) presents the system’s business and/or programmatic drivers. Business goals and objectives Business / programmatic context for the system High-level functional requirements High-level constraints High-level quality attribute requirements Plan for development Facilitators capture information that may shed light on the quality attribute drivers.

14
Step 3. Architecture Plan Presentation
The system architect presents the architecture development plans including Key business/programmatic requirements Key technical requirements and constraints that will drive architectural decisions, such as mandated operating systems, hardware, middleware, and so forth other external systems with which the system must interact existing context diagrams, high-level system diagrams, and descriptions

15
Step 4. Identification of Architectural Drivers
The QAW facilitators identify the architectural drivers that are key to realizing quality attribute goals by hearing the previous 2 steps. Ask for clarifications, additions, and/or deletions from the stakeholders to reach a consensus on the list of architectural drivers The final list of architectural drivers helps focus the stakeholders during scenario brainstorming ( next step)

16
Step 5. Scenario Brainstorming
Stakeholders ( Department / business area managers) generate real-world scenarios for the system. Scenarios comprise a related stimulus, an environmental condition, and a response. stimulus response Facilitators ensure that at least one scenario addresses each of the architectural drivers identified in Step 4. Environment

17
Step 6. Scenario Consolidation
Scenarios that are similar in content are deleted keeping only one Done by facilitator with the consent of all

18
Step 7. Scenario Prioritization
Voting process is taken up scenario by scenario to prioritise scenarios Voting done by Stakeholders Prioritization consensus arrived at by Facilitators

19
Step 8. Scenario Refinement
The top scenarios are further refined. The number of scenarios refined depends on the time available. Typically the top five scenarios are refined. QAW facilitators refine ( detail /elaborate) scenario and document : business/mission goals affected by the scenario description of relevant quality attributes list of questions with respect to the scenarios that stakeholders would like to pose any issues that may arise during the scenario refinement

20

QAW Conceptual Flow

21
Documenting Quality Attributes
Why Document ? Eliminate flaws Reduce the time spent on a specific task Decrease costs Decrease resources associated with any task Improve efficiency Improve overall quality Increase customer and employee satisfaction New employee knowledge acquisition

22
Content of documentation
Introduction Purpose: – The purpose of the document ( quality attributes) Scope: Scope of the document ( limited to quality of software , dev process not business process) Definition, acronyms and abbreviations Reference Functional Requirements Describe the functional requirements of the system for those requirements that are expressed in the natural language, style or the otherwise not included in the use-case model. Usability ( user quality attribute) State the requirements that affect usability. Reliability ( run time QA) State the requirements for reliability Performance ( runtime QA) State the performance characteristics of the system , expressed quantitatively where possible and related to use cases where applicable Supportability ( system QA) State the requirements that enhance system supportability or maintainability.

23
Content of documentation…
Design Constraints State the design or development constraints imposed on the system or development process Document Requirements State the requirements for user and / or administrator documentation Purchased Components List the purchased components used with the system, licensing or usage restrictions and compatibility/ interoperability requirements Interfaces Define the interfaces that must be supported by the application. User Interfaces Hardware Interfaces Software Interfaces Communication Interfaces Licensing and Security Requirements Describe the licensing and usage enforcement requirements or other restriction for usage.

24

SIX Part Scenario A quality attribute scenario is a quality-attribute-specific requirement. It consists of six parts. Source of stimulus – the entity that generated the stimulus Stimulus – a condition that needs to be considered when it arrives at a system Environment – the particular conditions in which the stimulus occurs

25
SIX Part Scenario (Cont’d)
The six parts of a quality attribute scenario (cont’d). Artifact – the system or the pieces of it that are stimulated Response – the activity undertaken after the arrival of the stimulus Response measure – when the response is occurs, it should be measurable in some fashion so that the requirement can be tested.

26

SIX Part Scenario…

27
SIX Quality Attributes
Availability Modifiability Performance Security Testability Usability +++ We have to analyse each quality attribute for six scenarios

28
General vs. Concrete Quality Attribute Scenarios
A general scenario is system independent and can, potentially, pertain to any system. A concrete scenario is specific to the particular system under consideration. Concrete scenarios are needed to make the quality requirements operational.

29

Case study 1 An unexpected external message flashed in the system during normal operation of a process The process informs the operator of the message System continues to operate with no downtime Analyse 6 part scenario for system availability

30
General Scenario for Availability

31
Sample Concrete Availability Scenario

32
Table ( Document) for General Availability Scenario
Portion of Scenario Possible Values Source Internal to the system; external to the system Stimulus Fault; omission, crash, timing, response Artifact System’s processors, communication channels, persistent storage processes Environment Normal operation; degraded mode (i.e., fewer features, a fall-back solution. Response System should detect event and do one or more of the following: record it notify appropriate parties, including the user and other systems disable sources of events that cause fault or failure be unavailable for a pre-specified interval continue to operate in normal or degraded mode Response Measure Time interval when the system must be available; availability time; time interval in which system can be in degraded mode; repair time

33

Case study 2 Developer wishes to change the UI interface using source code It will affect/ change the earlier UI design Modification effected in 3 hours No side effects on the system Analyse 6 part scenario for modifiability

34
Sample Modifiability Scenario

35
Table ( Document) for General Modifiability Scenario
Portion of Scenario Possible Values Source End user, developer, system administrator Stimulus Wishes to add/delete/modify/vary functionality, quality attribute, capacity Artifact System user interface, platform, environment; system that inter-operates with target system Environment At runtime, compile time, build time, design time Response Locates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modification Response Measure Cost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes

36

Case study 3 Users initiate 1000 transactions per minute stochastically under normal operations in a system Transactions are processed with an average latency of 2 seconds Analyse scenario for performance

37
Sample Performance Scenario

38
Table ( Document) for Performance Scenario
Portion of Scenario Possible Values Source One of a number of independent sources, possibly from within system Stimulus Periodic events arrive; sporadic events arrive; stochastic events arrive Artifact System Environment Normal mode; overload mode Response Processes stimuli; changes level of service Response Measure Latency, deadline, throughput, jitter, miss rate, data loss

39

Case study 4 Correctly identified individual tries to modify system data from external site during normal operations System maintains an audit trail Correct data restored in one day Analyse 6 part scenario scenario for security

40
Sample Security Scenario

41
Table ( Document) for Security Scenario
Portion of Scenario Possible Values Source User/system who is legitimate/imposter/unknown with full/limited access Stimulus 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; encrypt data; detect excessive demand… Response Measure Time /effort/resources to circumvent security measures with probability of success

42

Case study 5 A unit tester performs a unit test on a completed system component that provides an interface for controlling the behaviour and observing the output In 3 hours 85% path coverage is achieved Analyse 6 part scenario scenario for testability

43
Sample Testability Scenario

44
Table ( Document) for Testability Scenario
Portion of Scenario Possible Values Source Unit developer, increment integrator, system verifier, client acceptance tester, system user Stimulus Analysis, architecture, design, class, subsystem integration completed; system delivered Artifact Piece of design, piece of code, complete application Environment At design time, at development time, at compile time, at deployment time Response Provides access to state values; provides computed values; prepares test environment Response Measure % coverage; prob. of failure; time to perform tests; length of time to prepare test environment

45
Case study 6 An user wants to minimise the impact of an error
He cancels the process operation at run time Cancellation happens within 1 sec. Analyse scenario for usability

46
Sample Usability Scenario

47
Table ( Document) for Usability Scenario
Portion of Scenario Possible Values Source End user Stimulus Wants to learn system features; use system efficiently; minimize impact of errors; adapt system; feel comfortable Artifact System Environment At runtime or configuration time Response System provides one or more of the following responses: to support “learn system features” to support “use system efficiently” to “minimize impact of errors” to “adapt system” to “feel comfortable” Response Measure Task time, number of errors, number of problems solved, user satisfaction, gain of user knowledge, ration of successful operations to total operations; amount of time/data lost

48
Centralised Invoice approval system
CASE STUDY 7 QAW process Centralised Invoice approval system

49
Business Presentation by Stakeholder ( Customer)
Customer presents Business environment Invoice documents that are received from business units worldwide are centralized in one geographical location: Chennai Chennai is responsible for Labeling invoices Scanning invoices Posting the invoices to SAP Invoice verification is performed by business executives in Chennai Every invoice must get a unique identification Every invoice must be stored electronically in a central repository Every invoice must be submitted to a verification process (review and approval) Posters must make use of the electronic version of the invoice Reviewers and approvers must make use of the electronic version of the invoice Major stakeholders and users • Stakeholders Procurement Finance Legal • Users Scanner Poster Reviewer Approver

50
Business Presentation by Stakeholder ( Customer)…
Constraints Business – The lead time from invoice reception to invoice approval is less than one week Time to market • Very fast User demands • Easy to use • Fast Standards • SAP • Documentum Cost • To be as minimum as possible

51
Technical Presentation – Arch.Drivers ( System Architect)…
COTS • SAP Integration requirements with SAP – Documentation Hardware requirements • Run on current hardware and network infrastructure Load Chennai – Avg document upload and download: 1 doc every 9 sec each All over India – Avg document download: 1 doc every 3 sec

52
Technical Presentation ( System Architect)…
Client Server • Sap client – Sap server Multistep process integration Posting tool spawns acrobat viewer Verification tool spawns acrobat viewer Data consistency integration eConnector creates invoice objects in SAP based on documents

53
QA Constraints ( Falicitator)
Usability E-documents can easily be read when displayed on screen Availability Very High availability during Chennai business hours High availability 24/7 for other business workers Performance Throughput Infrastructure must allow to process at least 400 invoices per hour Every 9 sec a request for a document upload is submitted; there will be a download every 3 sec! UI responsiveness average 5 s worse case 10 s

54
Scenario ( Stake holders – Users)
Scenario presentation Brainstorming Consolidation Prioritization Refinement Documentation as per standard format ( as seen before) Circulation

55

Question Bank – 2 marks What are the 7 common SW quality attributes types ? List the Design Quality Attributes. List the Runtime Quality Attributes. List the System Quality Attributes. List the User Quality Attributes. List the non runtime Quality Attributes. List the architecture Quality Attributes. List the Business Quality Attributes. Why SW Quality Assessment is difficult ? Define QAW

56

Question Bank – 2 marks Why QAWs are important to architectural design ? List the benefits of QAW. What are the QAW focus areas ? List the QAW process steps. Why quality attributes must be documented ? Define – Functional Requirements What do you understand by ‘Usability’ What do you understand by ‘ Reliability’ What do you understand by ‘ Supportability’ Draw the six part scenario diagram .

57
Question Bank – 16 marks Explain in detail the need and process of QAW
Explain in detail the way QA are documented What is six part scenario ? Explain six part scenario for any one QA with appropriate example. ( general) 4 to 9 . QA (particular) Availability Modifiability Performance Security Testability Usability

58

End of Unit 2