Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Анализ атрибутов качества

453 vues

Publié le

Доклад Юрия Гайдучка на Analyst Days-7. 13-14 октября 2017. Минск

Publié dans : Formation
  • Login to see the comments

  • Soyez le premier à aimer ceci

Анализ атрибутов качества

  1. 1. Quality Attributes Analysis Yuriy Gaiduchok, Oct 2017 REPLACE IMAGE Quality Attributes Analysis Yuriy Gaiduchok, Oct 2017
  2. 2. Hello! I’m Yuriy Head of Business Analysis @ Ciklum Best BA 2017 by IT Awards Ukraine 14 years in IT: 12 in Product Management and Business Analysis
  3. 3. “This was not in specification” “We never thought it would matter” “No one ever told about it” “It is too late to change the architecture” 3
  4. 4. Assumptions 4 Explicit Implicit
  5. 5. Structure of Business Solutions Business Rules Business Processes Organizational Structure Business Locations Market Events Data Sources Applications Technical Infrastructure Business Solution vs. Project Scope 5
  6. 6. Are they really non-functional? 6 IIBA BABOK
  7. 7. 7 Quality Attributes & Non-Functional Requirements A description of a property or characteristic that a software system must exhibit or a constraint that it must respect, other than an observable system behavior. Karl Wiegers IIBA BABOK Non-functional requirements augment the functional requirements of a solution, identify constraints on those requirements, or describe quality attributes a solution must exhibit.
  8. 8. Quality Attributes Categories (Partial List) 8 Access Control Accessibility Accuracy Adaptability Adjustability Affordability Agility Augmentability Autonomy Availability Capacity Cohesiveness Compatibility Completeness Conciseness Confidentiality Configurability Connectivity Consistency Controllability Correctness Coupling Customizability Decomposability Dependability Development Cost Develop Time Distributivity Efficiency Elasticity Extensibility Fault Tolerance Feasibility Flexibility Independence Integrity Interoperability Intuitiveness Learnability Maintainability Maintenance Time Maturity Measurability Mobility Modifiability Modularity Performance Portability Precision Predictability Productivity Recoverability Reliability Replaceability Replicability Responsiveness Retirement Cost Reusability Robustness Safety Scalability Security Sensitivity Simplicity Stability Supportability Survivability Testability Throughput Trainability Uniformity Usability Verifiability Versatility
  9. 9. Quality Attributes Categories Selection 9 Ciklum Primary Availability Compatibility & Portability Performance & Efficiency Scalability Security & Audit Testability (Automation) Usability & Accessibility Secondary Customizability Data Latency Interoperability Multitenancy Reliability & Recoverability Verifiability Throughput
  10. 10. Incomplete list No common ontology Context-specific Challenges
  11. 11. How can you determine which quality attribute requirements are important before a system is built?
  12. 12. 12
  13. 13. 13 Who is responsible?
  14. 14. Approaches for Quality Attributes 14 Interviews Document Analysis Observation Survey or Questionnaire Acceptance and Evaluation Criteria Root Cause Analysis Interface Analysis & Data Flow Diagrams Risk Analysis and Management Quality Attribute Scenarios & Workshop Metrics and KPIs Use Cases (Alternative and Exception Flows) Technical User Stories
  15. 15. 15 Technical User Stories As DevOps, I want the system to use existing clients database rather than create a new one, so that we don't have to maintain additional database. As a user, I want the website to be available 99.9% of the time I try to access it, so that I would not get frustrated and find another website. Who? How? Why?
  16. 16. 2000 Questions 16 Operation How well is it safeguarded against unauthorized access? (Access Security) How easy is it to learn and operate the system? (Usability) Revision How easy is it to modify to work in different environments? (Flexibility) How easy is it to show it performs its functions? (Verifiability) Transition How easy is it to interface with another system? (Interoperability) How easy is it to convert for use in another system? (Reusability) Roxanne Miller
  17. 17. Carnegie Mellon University 17 — facilitated method to generate and prioritize quality attribute scenarios before the software architecture is completed. — focused on system-level concerns and specifically the software role in the system. — keenly dependent on the participation of system stakeholders. Quality Attribute Workshop
  18. 18. QAW 18 Step 1. QAW Presentation and Introductions Step 2. Business/Mission Presentation Step 3. Architectural Plan Presentation Step 4. Identification of Architectural Drivers Step 5. Scenario Brainstorming Step 6. Scenario Consolidation Step 7: Scenario Prioritization Step 8: Scenario Refinement Quality Attribute Workshop by Software engineering Institute of Carnegie Mellon University
  19. 19. QAW 19 Advantages • Determine the right qualities before system is developed — crucial for success and stakeholders' satisfaction. Saves money and avoids future rework. • Structured and efficient setting for communicating with your stakeholders, supports analysis and testing. • Generally leads to the identification of conflicting assumptions about system requirements. Disadvantages • Gathering multiple stakeholders and conducting QAW sessions requires appropriate planning and availability. Quality Attribute Workshop
  20. 20. Scenarios (QAS) 20 Quality Attribute Scenario — unambiguous and testable requirement for one or more Solution Quality Attributes such as Performance, Usability, Maintainability and others. by Software engineering Institute of Carnegie Mellon University
  21. 21. QAS (scenario) consists of 6 parts 21 1. Stimulus – A condition that affects the system. 2. Source of the stimulus – The entity that generated the stimulus. 3. Environment – The condition under which the stimulus occurred. 4. Artifact stimulated – The artifact stimulated by the stimulus. 5. Response – The activity that results because of the stimulus. 6. Response measure – The measure for system’s response evaluation. by Software engineering Institute of Carnegie Mellon University
  22. 22. Quality Attribute Scenario (QAS) Example 22 External smoke detector2 sends an alarm event1 under peak load3. The building management system4 receives the event and raises an alarm5 within 0.5 seconds6 1) Stimulus 2) Source 3) Environment 4) Artifact 5) Response 6) Response Measure
  23. 23. QAS for One Modifiability Case 23 A product manager2 request the system accommodate devices supporting the next version1 of the ECNET standard3. The system4 can accommodate5 these devices within 1 person month of effort6 with no changes to the software architecture6. 1) Stimulus 2) Source 3) Environment 4) Artifact 5) Response 6) Response Measure
  24. 24. QAS for One Security Case 24 A unauthorized individual from an external site gains access to the system and tries to modify consumer data. The system detects the malicious behavior, maintains an audit trail of the unauthorized individual’s actions, notifies system administration, and shuts down the system within 15 seconds.
  25. 25. QAS for One Security Case 25 A unauthorized individual from an external site2 gains access to the system1 during normal operation3 and tries to modify consumer data1. The system4 detects the malicious behavior5, maintains an audit trail5 of the unauthorized individual’s actions, notifies system administration5, and shuts down the system5 within 15 seconds6. 1) Stimulus 2) Source 3) Environment 4) Artifact 5) Response 6) Response Measure
  26. 26. QAS for One Availability Case 26 “An unanticipated external message is received by a process during normal operation. The process informs the operator of the receipt of the message and continues to operate with no downtime.” Source: External to System Stimulus: Unanticipated message Environment: Normal Operation Response: Inform Operator, Continue to Operate Response Measure: No Downtime Artifact: Process
  27. 27. QAS for General Availability 27 Source: Internal or External: people, hardware, software, physical Stimulus: Fault: omission, crash, incorrect timing, incorrect response Environment: Normal operation, startup, shutdown, degraded operation, overloaded Response: Prevent failure, Detect fault, Disable event source. Response Measure: Time or % system must be available, Time to detect fault, Repair time Artifact: Processors, comm. channels, storage
  28. 28. Ignore? 28 Revenue Client satisfaction Employee satisfaction NPS Reputation
  29. 29. 29 Functional Attribute Quality Attribute (Non-Functional)
  30. 30. Tradeoffs 30
  31. 31. 31 Functional Attribute Quality Attribute (Non-Functional)
  32. 32. 32 How Uber Launched
  33. 33. 2017? Quality Market! 33
  34. 34. Questions?
  35. 35. Yuriy Gaiduchok https://linkedin.com/in/uasdlc Connect two worlds!