Software Architecture june 2019

Q1)A) What is Software Requirement Specification - [SRS] and qualities of

SRS?
The production of the requirements stage of the software development process
is Software Requirements Specifications (SRS) (also called a requirements
document). This report lays a foundation for software engineering activities
and is constructing when entire requirements are elicited and analyzed. SRS is a
formal report, which acts as a representation of software that enables the
customers to review whether it (SRS) is according to their requirements. Also, it
comprises user requirements for a system as well as detailed specifications of
the system requirements.
Quality characteristics of a good Software Requirements Specification
(SRS) document include:
1. Complete: The SRS should include all the requirements for the software
system, including both functional and non-functional requirements.
2. Consistent: The SRS should be consistent in its use of terminology and
formatting, and should be free of contradictions.
3. Unambiguous: The SRS should be clear and specific, and should avoid
using vague or imprecise language.
4. Traceable: The SRS should be traceable to other documents and artifacts,
such as use cases and user stories, to ensure that all requirements are being
met.
5. Verifiable: The SRS should be verifiable, which means that the
requirements can be tested and validated to ensure that they are being met.
6. Modifiable: The SRS should be modifiable, so that it can be updated and
changed as the software development process progresses.
7. Prioritized: The SRS should prioritize requirements, so that the most
important requirements are addressed first.
8. Testable: The SRS should be written in a way that allows the requirements
to be tested and validated.
9. High-level and low-level: The SRS should provide both high-level
requirements (such as overall system objectives) and low-level
requirements (such as detailed functional requirements).
10.Relevant: The SRS should be relevant to the software system that is being
developed, and should not include unnecessary or irrelevant information.
11.Human-readable: The SRS should be written in a way that is easy for non-
technical stakeholders to understand and review.
12.Aligned with business goals: The SRS should be aligned with the overall
business goals and objectives of the organization, so that the software
system meets the needs of the business.
13.Agile methodologies: Agile methodologies, such as Scrum and Kanban,
provide an iterative approach to requirements capturing and validation,
 where requirements are captured and validated in small chunks of
functionality and feedback is gathered from the customer.
By keeping these quality characteristics in mind, developers and stakeholders
can ensure that the SRS document is clear, complete, and accurate, which in
turn can help to ensure that the final software system meets the needs of the
business and its users.

b) Explain water-fall software development life cycle?

The Waterfall Model was the first Process Model to be introduced. It is also
referred to as a linear-sequential life cycle model. It is very simple to
understand and use. In a waterfall model, each phase must be completed before
the next phase can begin and there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software
development.
The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process begins
only if the previous phase is complete. In this waterfall model, the phases do not
overlap.
Waterfall Model - Design
Waterfall approach was first SDLC Model to be used widely in Software
Engineering to ensure success of the project. In "The Waterfall" approach, the
whole process of software development is divided into separate phases. In this
Waterfall model, typically, the outcome of one phase acts as the input for the
next phase sequentially.
The following illustration is a representation of the different phases of the
Waterfall Model.

The sequential phases in Waterfall model are −

 Requirement Gathering and analysis − All possible requirements of the
system to be developed are captured in this phase and documented in a
requirement specification document.
  System Design − The requirement specifications from first phase are
studied in this phase and the system design is prepared. This system
design helps in specifying hardware and system requirements and helps in
defining the overall system architecture.
 Implementation − With inputs from the system design, the system is
first developed in small programs called units, which are integrated in the
next phase. Each unit is developed and tested for its functionality, which
is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementation
phase are integrated into a system after testing of each unit. Post
integration the entire system is tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing
is done; the product is deployed in the customer environment or released
into the market.
 Maintenance − There are some issues which come up in the client
environment. To fix those issues, patches are released. Also to enhance
the product some better versions are released. Maintenance is done to
deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases. The next phase is
started only after the defined set of goals are achieved for previous phase and it
is signed off, so the name "Waterfall Model". In this model, phases do not
overlap.
Waterfall Model - Application
Every software developed is different and requires a suitable SDLC approach to
be followed based on the internal and external factors. Some situations where
the use of Waterfall model is most appropriate are −
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the
product.
 The project is short.
Waterfall Model - Advantages
The advantages of waterfall development are that it allows for
departmentalization and control. A schedule can be set with deadlines for each
stage of development and a product can proceed through the development
process model phases one by one.
Development moves from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation and maintenance. Each
phase of development proceeds in strict order.
Some of the major advantages of the Waterfall Model are as follows −
  Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well
understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.
Waterfall Model - Disadvantages
The disadvantage of waterfall development is that it does not allow much
reflection or revision. Once an application is in the testing stage, it is very
difficult to go back and change something that was not well-documented or
thought upon in the concept stage.
The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
Q-2) A)Explain any 8 stakeholders of architecture documentation, their
roles.

Definition. A stakeholder in the architecture of a system is an individual, team,

organization, or classes thereof, having an interest in the realization of the
system.
Most system development projects include representatives from most if not all
of these stakeholder groups, although their relative importance will obviously
vary from project to project. However, if you do not at least consider each class,
you will have problems in the future. You need to balance and prioritize the
needs of the different stakeholder groups, so that when conflicts occur, you can
make sound, well-reasoned decisions.
We classify stakeholders according to their roles and concerns as in the
following table.
Acquirers Oversee the procurement of the system or product
Assessors Oversee the system’s conformance to standards and legal
regulation
Communicators Explain the system to other stakeholders via its documentation
and training materials
Developers Construct and deploy the system from specifications (or lead the
teams that do this)
Maintainers Manage the evolution of the system once it is operational
Production Design, deploy, and manage the hardware and software
Engineers environments in which the system will be built, tested, and run
Suppliers Build and/or supply the hardware, software, or infrastructure on
which the system will run
Support Staff Provide support to users for the product or system when it is
running
System Run the system once it has been deployed
Administrators
Testers Test the system to ensure that it is suitable for use
Users Define the system’s functionality and ultimately make use of it
Architecture documentation in software development involves various
stakeholders who play crucial roles in defining, designing, implementing, and
maintaining the software system. Here are eight key stakeholders involved in
architecture documentation and their roles:
1. Software Architects:
o Role: Software architects are responsible for designing the overall
structure of the software system. They create the architectural
blueprint that outlines the high-level design decisions, such as
choosing the right technologies, defining the system's components
and their interactions, and ensuring that the architecture meets both
functional and non-functional requirements.
o In Architecture Documentation: Architects lead the creation and
maintenance of architecture documentation. They ensure that the
documentation accurately reflects the architectural decisions,
rationale behind them, and how they align with business goals.
2. Developers:
o Role: Developers are responsible for implementing the software
based on the architectural design. They write the code, integrate
components, and ensure that the system functions according to the
specified architecture.
o In Architecture Documentation: Developers use architecture
documentation to understand the system's structure, how
 components interact, and any coding standards or patterns to
follow. They also contribute feedback on the feasibility and clarity
of the documented architecture.
3. Project Managers:
o Role: Project managers oversee the planning, execution, and
monitoring of software development projects. They are responsible
for managing resources, schedules, and risks to ensure successful
project delivery.
o In Architecture Documentation: Project managers use
architecture documentation to track progress, manage
dependencies, allocate resources, and ensure that the project stays
on schedule and within budget. They also communicate the
project's architectural aspects to stakeholders and manage any
changes or risks related to the architecture.
4. Quality Assurance (QA) Engineers:
o Role: QA engineers are responsible for testing the software to
ensure it meets quality standards and performs as expected. They
create test cases, perform testing, identify defects, and work with
developers to resolve issues.
o In Architecture Documentation: QA engineers use architecture
documentation to understand the system's design and behavior,
which guides their test planning and execution. They verify that the
implemented system aligns with the documented architecture and
test against the specified requirements.
5. System Administrators:
o Role: System administrators manage and maintain the software
and its infrastructure after deployment. They handle installation,
configuration, monitoring, and maintenance tasks to ensure the
system's availability, performance, and security.
o In Architecture Documentation: System administrators use
architecture documentation to understand the system's deployment
architecture, hardware requirements, dependencies, and operational
procedures. This helps them effectively manage and support the
deployed system.
6. Business Analysts:
o Role: Business analysts bridge the gap between business
stakeholders and technical teams. They gather and analyze business
requirements, define project scope, and ensure that the software
solution meets business objectives.
o In Architecture Documentation: Business analysts use
architecture documentation to validate that the proposed
architecture aligns with business needs and requirements. They
communicate technical aspects of the architecture to business
 stakeholders and ensure that the solution addresses their functional
and non-functional requirements.
7. End Users:
o Role: End users are the individuals who interact with and use the
software system to perform their tasks or achieve specific goals.
Their satisfaction and usability of the system are critical for its
success.
o In Architecture Documentation: End users may not directly
contribute to architecture documentation creation, but their needs
and feedback influence architectural decisions. Understanding user
requirements and usability considerations is essential for designing
an architecture that meets their expectations and enhances user
experience.
8. Technical Writers:
o Role: Technical writers create and maintain documentation that
describes the software system, its features, functionality,
installation procedures, and usage guidelines. They ensure that
documentation is clear, comprehensive, and accessible to its
intended audience.
o In Architecture Documentation: Technical writers collaborate
with architects and developers to document the software
architecture in a way that is understandable and usable for all
stakeholders. They organize and present information in architecture
documents to facilitate knowledge sharing and support ongoing
maintenance and enhancement efforts.
Each stakeholder in architecture documentation plays a vital role in ensuring
that the software system is well-designed, implemented, and maintained
throughout its lifecycle, meeting both technical requirements and business goals
effectively
1. Q2)B) what is the role of software architecture?
The role of software architecture is crucial in the development and maintenance
of software systems. Here are some key roles and responsibilities of software
architecture:
1. Structuring the System: Software architecture defines the high-level
structure of a software system, including its components or modules, their
relationships, and how they interact with each other. It provides a
blueprint that guides both the development and the evolution of the
system over time.
2. Quality Assurance: Architecture plays a significant role in ensuring that
the software system meets its quality attributes or non-functional
requirements (NFRs) such as performance, reliability, scalability,
security, and usability. By defining these attributes early in the design
 phase, architecture sets the foundation for achieving them throughout the
development lifecycle.
3. Facilitating Communication: Software architecture serves as a common
language or framework for communication among stakeholders,
including developers, project managers, customers, and other participants
in the software development process. It helps stakeholders understand the
structure and behavior of the system, making it easier to discuss and
make decisions about its design and implementation.
4. Guiding Development Teams: Architecture guides development teams
by providing guidelines, patterns, and best practices for implementing the
system. It helps developers make informed decisions about technologies,
frameworks, and design patterns that align with the overall architecture,
ensuring consistency and coherence in the system's implementation.
5. Managing Complexity: Modern software systems are often complex,
involving numerous components, interactions, and dependencies.
Architecture helps manage this complexity by breaking down the system
into manageable pieces, identifying key abstractions, and defining clear
interfaces and boundaries between components.
6. Supporting Evolution and Maintenance: Software systems evolve over
time due to changing requirements, technologies, and business needs. A
well-defined architecture supports the system's evolution by providing
flexibility, extensibility, and maintainability. It allows for incremental
changes and updates without compromising the integrity and stability of
the system.
7. Risk Management: Architecture helps identify and mitigate technical
risks early in the development process. By addressing potential
challenges related to performance bottlenecks, security vulnerabilities,
scalability issues, etc., architecture enables proactive risk management
and ensures the delivery of a reliable and robust software system.
In essence, software architecture is essential for ensuring that software systems
are not only functional but also scalable, maintainable, secure, and aligned with
business goals. It serves as a foundation for both the initial development and the
long-term success of software projects.

Q-3)A)Where do we find quality attribute in software architecture

documentation

Quality attributes are a key part of software architecture documentation and are
typically documented in the following sections:
Non-Functional Requirements
Quality attributes are a type of non-functional requirement that specify how the
system should behave, rather than what it should do. They are documented
alongside functional requirements to provide a complete picture of the system's
expected behavior.
Quality Attribute Scenarios
Quality attribute scenarios are used to specify the quality attributes in more
detail. They describe a stimulus, the environment the stimulus occurs in, the
artifact stimulated, the response, and the response measure. For example, a
reliability scenario could be: "Upon failure of a single server, the system should
transparently fail over to a backup server with no more than 1 minute of
downtime."
Views and Perspectives
Quality attributes are considered when designing the various views of the
architecture, such as the logical view, process view, development view, and
physical view. Specific quality attributes may drive decisions in each view. For
example, the physical view may be influenced by performance and availability
attributes.
Architectural Decisions
The architectural decisions made during the design process are driven by the
need to satisfy the quality attributes. Documenting the rationale behind key
decisions helps explain how the architecture supports the quality attributes.
Architectural Patterns and Tactics
Specific architectural patterns and tactics are chosen to address quality
attributes. For example, using a load balancer is a tactic to address
performance and scalability. Documenting the patterns and tactics used
helps show how quality attributes are being achieved.In summary, quality
attributes are a critical part of software architecture documentation and
should be specified alongside functional requirements, elaborated through
quality attribute scenarios, considered in each architectural view, used to
drive architectural decisions, and realized through the choice of patterns
and tactics. Documenting them thoroughly helps ensure the architecture
meets the stakeholders' needs.
Q3) B)What are views in documentation? Define module view and
connector view
In software architecture documentation, "views" refer to different perspectives
or representations of the architecture that focus on specific aspects or concerns
of the system. Each view provides stakeholders with a structured way to
understand and analyze different facets of the architecture without
overwhelming them with unnecessary detail. Two common types of views are
the module view and the connector view:
1. Module View:
o Definition: The module view focuses on the decomposition of the
system into modules or components and their relationships.
 o Purpose: It provides a structural perspective, showing how the
system is organized into manageable units (modules) and how
these modules interact with each other.
o Contents: Typically includes diagrams such as component
diagrams, package diagrams, or module dependency diagrams.
These diagrams illustrate the modules or components of the system
and their dependencies, interfaces, and interactions.
2. Connector View:
o Definition: The connector view emphasizes the interactions and
communication paths between modules or components within the
system.
o Purpose: It helps stakeholders understand how data flows, how
components communicate, and how different parts of the system
collaborate to achieve functionality.
o Contents: Connector views often include diagrams like
communication diagrams, sequence diagrams, or deployment
diagrams. These diagrams highlight the connectors
(communication channels, protocols, interfaces) between modules
and show the flow of control or data between them.
Key Points to Remember:
 Abstraction and Focus: Both module and connector views abstract away
unnecessary details, focusing on specific aspects relevant to different
stakeholders.
 Complementary Views: Together, these views provide a comprehensive
understanding of the architecture, addressing both the structural (module
view) and behavioral (connector view) aspects of the system.
 Documentation Clarity: Using these views ensures that the
documentation is structured and organized, making it easier for
stakeholders to grasp and discuss different aspects of the architecture
effectively.
4)A) In architecture documentation, Explain pipe and filters.
Pipe and Filter Architecture
The Pipe and Filter architecture is a software design pattern that organizes
processing tasks into sequential stages, or "pipes," where each stage filters and
transforms data step-by-step. This modular approach allows components
(filters) to work independently, enhancing scalability and reusability.Key
Components
 Pumps: Data sources that push data into the system to start the flow through the
pipeline
 Filters: Independent components that perform specific processing tasks like
transforming, validating, or aggregating data before passing it to the next filter
 Pipes: Channels that connect filters and transport data from one to the next
 Sinks: Endpoints where the final processed data is collected
Characteristics
 Modularity: Each filter is a standalone component that performs a specific
task, allowing for easy understanding, development, and maintenance
 Reusability: Filters can be reused across different systems or within the same
system, reducing duplication
 Composability: Filters can be composed in various sequences to create
complex processing pipelines
 Scalability: Supports parallel processing by running multiple instances of filters
to handle larger data volumes
 Maintainability: Isolating functions into separate filters simplifies debugging
and updating
Design Principles
 Separation of Concerns: Each filter focuses on a single task, simplifying
development, testing, and maintenance
 Loose Coupling: Filters interact only through pipes, minimizing dependencies
and enabling flexibility
 Single Responsibility: Filters have one reason to change, promoting modular
design
Benefits
 Flexibility: Filters can be added, removed, or rearranged with minimal impact
on the overall system
 Scalability: Parallel pipelines can be used to increase throughput and handle
larger data volumes
 Maintainability: Changes to one filter do not affect others, making updates and
bug fixes easier to manage
Examples
 Unix shell commands: cat input.txt | grep "text" | sort > output.txt
 Java IO libraries: Use the Decorator pattern to compose filters
 C++ Ranges: Directly support the Pipe and Filter pattern in C++20
The Pipe and Filter architecture is well-suited for data processing tasks,
compilers, and applications requiring structured and sequential data
transformation. Its modular design promotes flexibility, reusability, and
maintainability, making it a popular choice for many software systems.
Q4)B) Explain what is MODEL-VIEW-CONTROLLER (MVC)
The Model-View-Controller (MVC) is an architectural pattern that separates
an application into three main logical components: the model, the view, and the
controller. Each of these components are built to handle specific development
aspects of an application. MVC is one of the most frequently used industry-
standard web development framework to create scalable and extensible projects.
MVC Components
Following are the components of MVC −
 Model
The Model component corresponds to all the data-related logic that the user
works with. This can represent either the data that is being transferred between
the View and Controller components or any other business logic-related data.
For example, a Customer object will retrieve the customer information from the
database, manipulate it and update it data back to the database or use it to render
data.
View
The View component is used for all the UI logic of the application. For
example, the Customer view will include all the UI components such as text
boxes, dropdowns, etc. that the final user interacts with.
Controller
Controllers act as an interface between Model and View components to process
all the business logic and incoming requests, manipulate data using the Model
component and interact with the Views to render the final output. For example,
the Customer controller will handle all the interactions and inputs from the
Customer View and update the database using the Customer Model. The same
controller will be used to view the Customer data.
Benefits of MVC
 Separation of Concerns: By dividing the application into distinct components,
MVC promotes organized code and reduces complexity, making it easier to
manage and modify.
 Modularity: Each component can be developed, tested, and maintained
independently, facilitating parallel development by different team members.
 Reusability: Components can be reused across different applications or
projects, enhancing efficiency and reducing redundancy in code.
 Scalability: The architecture supports the development of complex applications,
allowing for easier scaling and integration of new features over time.
Conclusion
MVC is a powerful design pattern that streamlines the development process by
clearly defining the roles of different components within an application. Its
structured approach not only enhances maintainability and scalability but also
 supports collaborative development, making it a popular choice among
developers for building modern web applications

Q5)A)Explain different steps involved in implementation of pipe & filter

architecture.
Implementing a Pipe and Filter architecture involves several systematic steps
that ensure the architecture is efficient, maintainable, and scalable. Here are the
key steps involved in the implementation:
Steps for Implementation
1. Define the System Requirements:
 Identify the overall goals and requirements of the system. Understand the data
flow and processing needs to determine how to break down the tasks into filters.
2. Identify Data Sources and Sinks:
 Determine the data sources (where data originates) and the sinks (where
processed data is sent). This will help define the boundaries of the system and
the flow of data through the architecture.
3. Design Filters:
 Single Responsibility Principle: Each filter should perform one specific task
(e.g., transformation, validation, or aggregation).
 Define Interfaces: Establish clear input and output interfaces for each filter to
ensure smooth data flow between them.
 Encapsulation: Keep the internal workings of each filter hidden, exposing only
the necessary interfaces for interaction.
4. Establish Pipes:
 Design pipes that connect the filters, ensuring they can transport data
efficiently. Pipes should have a clear input and output, maintaining the integrity
of the data as it flows from one filter to the next.
5. Implement Data Flow Control:
 Decide on the data flow control mechanism (push, pull, or a combination). This
will dictate how data is passed between filters and how they will synchronize
their operations.
6. Error Handling Mechanisms:
 Implement robust error handling strategies within each filter. Ensure that filters
can log errors and that the pipeline can handle errors gracefully, such as by
skipping problematic data or using fallback mechanisms.
7. Testing and Validation:
 Conduct unit testing for each filter to ensure they perform their intended
functions correctly. Validate the entire pipeline to confirm that data flows
correctly from source to sink.
8. Optimize Performance:
 Monitor the performance of the system and optimize as needed. This may
involve adjusting the number of filters, their configurations, or the way data is
processed to reduce latency and improve throughput.
9. Documentation:
 Document the architecture, including the purpose of each filter, the data formats
used, and the overall data flow. This will aid future maintenance and
enhancements.
10.Iterate and Enhance:
 After deployment, continuously monitor the system for performance and
scalability. Be prepared to add, remove, or modify filters as requirements
evolve, ensuring the architecture remains flexible and adaptable.
By following these steps, developers can effectively implement a Pipe and
Filter architecture that is modular, scalable, and easy to maintain, allowing for
efficient data processing across various applications

Q5)B) What is difference between software architecture and software

design
Difference between Software Design and Software Architecture
Aspect Software Design Software Architecture

Software architecture is
Software design is about designing about the complete
individual modules/components. architecture of the overall
Scope system.

Software architecture
Software design defines the
defines the fundamental
detailed properties.
Properties properties.

In general, it refers to the process In general, it refers to the

of creating a specification of process of creating the
software artifacts that will help high-level structure of a
Process developers implement the software. software system.

It helps to define the high

It helps to implement the software. level infrastructure of the
Purpose software.

Software architecture
Software design avoids uncertainty.
Uncertainty manages uncertainty.
 Aspect Software Design Software Architecture

Software architecture is
Software design is more about on
more about the design of
individual module/component.
Focus entire system.

It is a plan which
It is considered as one initial phase
constrains software design
of Software Development Cycle
Phase in to avoid known mistakes
(SSDLC) and it gives detailed idea
Software and it achieves one
to developers to implement
Development organizations business and
consistent software.
Cycle technology strategy.

Some of software
Some of software design patterns
architecture patterns are
are creational, structural and
microservice, server less
behavioral.
Patterns and event driven.

In one word the level of

In one word the level of software
software architecture is
design is implementation.
Level structure.

Question How we are building is software What we are building is

Addressed design. software architecture.

Q6)A) What are different software architecture quality attribute

requirements
Software architecture quality attributes are critical non-functional requirements
that define how well a software system performs its intended functions. Here
are some key quality attributes commonly considered in software architecture:
1. Usability:
 Refers to how easy and intuitive it is for users to interact with the system. It
encompasses learnability, efficiency, and user satisfaction.
2. Reliability:
 The ability of the system to consistently perform its intended functions over
time without failure. This includes aspects like fault tolerance and
recoverability.
3. Availability:
 The proportion of time the system is operational and accessible when required.
It is often expressed as a percentage of uptime.
4. Portability:
 The ease with which software can be transferred from one environment to
another, including different hardware and software platforms.
5. Testability:
 The degree to which a system or its components can be effectively tested to
ensure they meet specified requirements.
6. Scalability:
 The ability of the system to handle increased loads or to be enlarged without
performance degradation. This can be vertical (adding resources to a single
node) or horizontal (adding more nodes).
7. Flexibility:
 The capacity of the system to adapt to changes in requirements or environments
without extensive rework.
8. Reusability:
 The extent to which components or systems can be reused in different
applications or contexts with minimal modification.
9. Maintainability:
 The ease with which a system can be modified to correct faults, improve
performance, or adapt to a changed environment.
10.Supportability:
 The ability of the system to be supported and maintained, including
documentation and ease of troubleshooting.
11.Interoperability:
 The capability of the system to work with other systems or components,
facilitating data exchange and communication.
12.Performance:
 Refers to the responsiveness of the system, including how quickly it processes
requests and the resource consumption during operation.
13.Security:
 The ability of the system to protect against unauthorized access and ensure data
integrity and confidentiality.
These quality attributes are often interrelated, and trade-offs may be necessary
during the architecture design process to balance competing requirements
effectively. Prioritizing these attributes based on project needs is essential for
creating a robust and effective software architecture
Q6)B) Explain different steps used in architecture Tradeoff Analysis
Method (ATAM) for evaluating software architecture
The Architecture Tradeoff Analysis Method (ATAM) is a structured approach
used to evaluate software architectures, focusing on quality attributes and their
trade-offs. Here are the different steps involved in the ATAM process:
 Steps in the ATAM Process
1. Present ATAM:
 Introduce the ATAM process to stakeholders, explaining its purpose, benefits,
and how it will be conducted. This step ensures that all participants understand
the methodology and objectives.
2. Present Business Drivers:
 Gather and discuss the business drivers for the system, including functionality,
goals, constraints, and desired non-functional properties. This helps to align the
architectural evaluation with the organization's strategic objectives.
3. Present Architecture:
 The architect presents a high-level overview of the architecture, including key
components and their interactions. This presentation should provide an
appropriate level of detail to facilitate understanding and analysis.
4. Identify Architectural Approaches:
 Discuss various architectural approaches that could be applied to the system.
This step involves evaluating different strategies and their implications on the
overall architecture.
5. Generate Quality Attribute Utility Tree:
 Create a utility tree that maps the core business and technical requirements to
relevant quality attributes. This tree helps in defining scenarios that reflect the
desired qualities of the architecture.
6. Analyze Architectural Approaches:
 Evaluate each architectural approach against the defined scenarios, rating them
based on their ability to meet quality attribute requirements. This analysis helps
identify strengths and weaknesses in the proposed architectures.
7. Brainstorm and Prioritize Scenarios:
 Engage the broader stakeholder group to present and expand upon the current
scenarios. Prioritize these scenarios based on their relevance and impact on the
architecture.
8. Re-analyze Architectural Approaches:
 Conduct a second analysis of the architectural approaches using the insights
gained from the brainstorming session. This step refines the evaluation based on
a more comprehensive understanding of stakeholder concerns.
9. Present Results:
 Summarize and present the findings of the evaluation to stakeholders. This
includes documenting identified risks, non-risks, sensitivity points, and trade-
offs, along with recommendations for addressing them.
Phases of ATAM
The ATAM process is divided into phases:
 Phase 0: Preparation: Involves planning, stakeholder recruitment, and team
formation.
 Phase 1: Evaluation (Steps 1-6): Focuses on presenting the ATAM, business
drivers, architecture, identifying approaches, generating the utility tree, and
analyzing approaches.
 Phase 2: Evaluation (Steps 7-9): Involves brainstorming scenarios, re-
analyzing architectural approaches, and presenting results.
 Phase 3: Follow-up: Includes generating reports and discussing potential
improvements based on the evaluation outcomes.
By following these steps, ATAM helps organizations make informed
architectural decisions that align with their business goals and quality attribute
requirements, ultimately mitigating risks early in the software development
lifecycle