Quality attribute scenarios
Download as DOCX, PDF•2 likes•1,872 views
This document discusses scenarios for evaluating business and architectural quality attributes in software systems. For business qualities like time-to-market and cost/benefits, it provides example scenarios that describe the stimulus, artifacts, environment, system response, and how to measure the response. For architectural qualities like conceptual integrity, correctness/completeness, and buildability, it notes that these attributes are more difficult to capture in scenarios since they depend on multiple phases of development and involve complex relationships between components, teams, and available tools.
Quality attribute scenarios
- 1. Forming Quality attribute scenarios for Business and architectural qualities Scenarios for Business Quality Attributes: Time to Market: Portion of scenario Possible values source Organization Stimulus Competitive pressure, lack of development team Artifacts Deployment Environment During Development of product Response Time to market is reduced by using prebuilt elements Response Measure Product came into market at announced date or time Cost and Benefits: Portion of scenario Possible values source Organization Stimulus Budget exceeded to pre-calculation Artifacts Project success Environment During Feasibility study Response Project not exceed the define budget Response Measure Project complete within the define budget
- 2. Projected lifetime of the system: Portion of scenario Possible values source End user, organization and developers Stimulus Wants modifiability, scalability, and portability Artifacts System Environment At run time or configure time Response Modifiability not affect the reaming system, system must run on different environment, Locate place in architecture for modification Response Measure Cost, time ,effort ,not affect the other attributes Targeted market: Portion of scenario Possible values source Organization Stimulus Wants Platform independent , functionality ,product line Artifacts system Environment During coding Response Response Measure
- 3. Rollout schedule: It is difficult to capture this attribute through scenario because intentionally organization never wants the rollout schedule. The first priority of organization to build a complete product in the define time but they rollout because due to lack of resources or technical problems. Also we have not information about environment and reaming portion of scenario. Integration with legacy systems: Portion of scenario Possible values source Developer Stimulus Wants integrity Artifacts System Environment During architectural designing Response substantial architectural implications Response Measure Easy for user , within the time, cost Scenarios for Architecture Quality Attributes: Conceptual integrity: It isdifficulttocapture thisattribute throughscenariobecause ourvisionthatunifiesthe design of the systemat all levels.The architecture shoulddosimilarthingsinsimilarways.Notconformationabout the source,stimulus,response andresponsemeasure. Correctness and completeness: It is difficult to capture this attribute through scenario because correctness and completeness not only depend upon architecture it’s also depend upon other phase of product life cycles. Correctness and completeness are about requirements and runtime resources we run there things through hole cycle not only architecture phase.
- 4. Build ability: It also a difficult to cover through senior due to these reasons: Buildablity allows the system to be completed by the available team in a timely manner and to be open to certain changes as development progresses. It refers to the ease of constructing a desired system and is achieved architecturally by paying careful attention to the decomposition into modules, judiciously assigning of those modules to development teams, and limiting the dependencies between the modules (and hence the teams). The goal is to maximize the parallelism that can occur in development. Because build ability is usually measured in terms of cost and time, there is a relationship between it and various cost models. However, build ability is more complex than what is usually covered in cost models. A system is created from certain materials, and these materials are created using a variety of tools. For example, a user interface may be constructed from items in a user interface toolbox (called widgets or controls), and these widgets may be manipulated by a user interface builder. The widgets are the materials and the builder is the tool, so one element of build ability is the match between the materials that are to be used in the system and the tools that are available to manipulate them. Another aspect of build ability is knowledge about the problem to be solved. The rationale behind this aspect is to speed time to market and not force potential suppliers to invest in the understanding and engineering of a new concept. A design that casts a solution in terms of well-understood concepts is thus more buildable than one that introduces new concepts.