Software ArchitectureArchitectural RequirementsQuality Attributes Vakgroep Informatietechnologie – IBCN
Software Architecture Definition   The Software Architecture of a program or      computing system is the structure or   s...
Dilbert on Software Requirements ...Vakgroep Informatietechnologie – Onderzoeksgroep IBCN   p. 3
Functional versus Non Functional Functional                Requirements:          FR’s capture the intended behavior of ...
Architecture and Functionality      Functionality          defines what the system has to do.          can be achieved ...
Use Cases & Scenario’s / UML Functional             Requirements are documented with:     Use cases:            define ...
Example : Use Case DiagramDepartment of Information Technology – Broadband Communication Networks (IBCN)   7
System Sequence DiagramsVakgroep Informatietechnologie – Onderzoeksgroep IBCN   p. 8
The origins of architecture complexity Functionality  needs to be mapped to  software structures in order to support the ...
Software Quality Attributes     Software Architecture and ...        Quality Attributes.        Quality Attribute Tacti...
Qualities in Software Architecture                                                          •   Capabilities              ...
ISO/IEC CD 25010 SQuaRE [1.] ISO/IEC CD 25010 Software engineering -- Software product Quality Requirements and Evaluation...
Quality Attributes in practice:EXAMPLE : SLA - Service Level Agreement   A service-level agreement (SLA) is a contract   ...
SLA terms (1/2)Guaranteed uptime         The expected availability of the Platform is 99.8%          or with periods of u...
SLA Terms (2/2)Performance      The target response time to any request should be       respected in 90% of all requests....
Business Qualities (1/2)   Time to Market:          Build or buy          Re-use existing elements from previous        ...
Business Qualities (2/2)Cost and Benefit:    The development budget must not be exceeded.    Different architectures wil...
The Quality state-of-mind   Quality is not the privilege of Architects:     it needs to be considered throughout the ent...
Quality Attribute Scenarios   Qualities are abstract and non-operational:           What does it mean for a system to be...
Quality Attribute ScenariosA   Quality Attribute Scenario describes:  SOURCE:                    who or what  STIMULUS:...
Example : Public Transport Signage                                      Availability QAS :SOURCE              who or what ...
Upcoming SlideShare
Loading in …5
×

Sa 004 quality_attributes

903 views

Published on

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
903
On SlideShare
0
From Embeds
0
Number of Embeds
349
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • While there are numerous similar definitions of software architecture, at the core of all of them is the notion that the architecture describes its gross structure using one or more views. The structure in a view illuminates a set of top level design decisions, including such as how the system is composed of interacting parts, the main ways of interaction and communication and the propoerties of the parts. Software architecture typically plays a key role as a bridge between requirements and design and by providing an absrtact description of the system it gives the designer a tool to assess certain system requirements and suggest methods for construction and implementation
  • Performance Software performance used to be handled as an afterthought. Architecture provides a tools to reason about performance. Technology churn example: Migrate from a relational database system to an object oriented system.
  • Sa 004 quality_attributes

    1. 1. Software ArchitectureArchitectural RequirementsQuality Attributes Vakgroep Informatietechnologie – IBCN
    2. 2. Software Architecture Definition The Software Architecture of a program or computing system is the structure or structures of the system, which comprises software elements, the external visible properties of those elements and the relationships among them. SoftwareRequirements Design ArchitectureVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
    3. 3. Dilbert on Software Requirements ...Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
    4. 4. Functional versus Non Functional Functional Requirements:  FR’s capture the intended behavior of the system and describe what the systems should do. This behavior may be expressed as services, tasks or functions the system is required to perform. Non Functional Requirements:  NFR’s are not directly concerned with a specific function delivered by the system. They typically come from the ABC (Architecture Business Cycle) and cover o.a. business, organisational, legal and quality requirements.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4
    5. 5. Architecture and Functionality  Functionality  defines what the system has to do.  can be achieved through any number of structures.  is often the ONLY consideration at the start of a project and leads to redesign, project cancelation,…  to slow  hard to maintainThe mapping of the system’s functionality onto software structures is critical for the support of quality . Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
    6. 6. Use Cases & Scenario’s / UML Functional Requirements are documented with:  Use cases:  define a goal-oriented set of interactions between external actors and the system under consideration.  Are graphically summarized in a UML use case diagram.  They are documented using a use case template.  Scenario’s:  A (black box or system ) scenario is an instance of a use case, and represents a single path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation.  Scenario’s are documented with UML sequence diagrams Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
    7. 7. Example : Use Case DiagramDepartment of Information Technology – Broadband Communication Networks (IBCN) 7
    8. 8. System Sequence DiagramsVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8
    9. 9. The origins of architecture complexity Functionality needs to be mapped to software structures in order to support the quality This mapping requires the collaboration, communication, synchronisation of these software elements in order to provide the functionality. Example: cachingVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9
    10. 10. Software Quality Attributes  Software Architecture and ...  Quality Attributes.  Quality Attribute Tactics.  Architecture PatternsQuality is ‘value as perceived by the customer’. Over and above the definition of customer features, quality attributes clarify which items are most important to the customers perception of the products quality and performance. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10
    11. 11. Qualities in Software Architecture • Capabilities Functionality • Functions • Services • Behaviour Software System Architectural Architecture Qualities Qualities • Conceptual Integrity • Modifiability • Correctness • Performance • Completeness • Testability • Buildability • Availability Business • Security • Cost Qualities • Usability • Margins • Scalability • Time-to-market • Interoperability • Target market • Portability • System lifetimeVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11
    12. 12. ISO/IEC CD 25010 SQuaRE [1.] ISO/IEC CD 25010 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE), 2009Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12
    13. 13. Quality Attributes in practice:EXAMPLE : SLA - Service Level Agreement  A service-level agreement (SLA) is a contract between a service provider and a customer that specifies, usually in measurable terms, what services provider will furnish.  SLA’s may specify :  What percentage of the time services will be available  The number of users that can be served simultaneously  Specific performance benchmarks to which actual performance will be periodically compared.  Help desk response time  Usage statistics that will be provided. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
    14. 14. SLA terms (1/2)Guaranteed uptime  The expected availability of the Platform is 99.8% or with periods of unavailability of maximum 2 (two) hours per month.Recovery  In case of system failure, the application and all data shall be restored within 4 hours after problem fixation.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14
    15. 15. SLA Terms (2/2)Performance  The target response time to any request should be respected in 90% of all requests.  New page download time inferior to 3 secondsCapacity  The installation will be planned for a maximum of 20.000 requests per day.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15
    16. 16. Business Qualities (1/2) Time to Market:  Build or buy  Re-use existing elements from previous projects  COTS/OSS :Time to market is often reduced by using prebuilt elements such as commercial off-the-shelf or open source components.  Deploy a subset : The ability to insert or deploy a subset of the system depends on the decomposition of the system into elements. (roll-out schedule)Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16
    17. 17. Business Qualities (2/2)Cost and Benefit: The development budget must not be exceeded. Different architectures will yield different development costs.  Architectures based on new technology are more expensive  Flexible architecture cost more to build but will be less costly to maintain and modifySystem Lifetime: If the system is intended to have a long lifetime, modifiability, scalability, and portability become important. ( = more revenue)  Building in the additional infrastructure (such as a layer to support portability) will usually compromise time to market. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17
    18. 18. The Quality state-of-mind Quality is not the privilege of Architects: it needs to be considered throughout the entire lifecycle (design, implementation, deployment) But: Architecture is critical to the realisation of many qualities. And Architecture cannot achieve quality by itself. Qualities can never be achieved in isolation.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18
    19. 19. Quality Attribute Scenarios Qualities are abstract and non-operational:  What does it mean for a system to be modifiable ? Quality attribute requirements are captured with quality attribute scenarios.  Generic scenarios (system independent) need to be translated into specific scenariosVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
    20. 20. Quality Attribute ScenariosA Quality Attribute Scenario describes:  SOURCE: who or what  STIMULUS: does something  ARTIFACT: to the system or part of it  ENVIRONMENT: under certain conditions  RESPONES: how the system reacts  MEASURE: how you can measure this Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20
    21. 21. Example : Public Transport Signage Availability QAS :SOURCE who or what A random eventSTIMULUS does something ... causes a failureARTIFACT to the system or part of it ... to the communication systemENVIRONMENT under certain conditions ...during normal operationsRESPONSE how the system reacts All displays must start showing scheduled arrival times for all busesMEASURE how you can measure this ... Within 30 seconds of failure detection Q: What is the architectural impact of this requirement ? Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21

    ×