Software architecture

SOFTWARE ENGINEERING
SWETA KUMARI BARNWAL 1
Module: III
III
Architectural Design: Architectural Design Decisions, System
Organization, Modular Decomposition Styles, Control Styles,
Reference Architectures. UML Model.
User Interface Design: Need of UI design, Design issues, The UI design
Process, User analysis, User Interface Prototyping, Interface Evaluation.
Project Management
Software Project Management, Management activities, Project
Planning, Risk Management.
Quality Management: Process and Product Quality, Quality
assurance and Standards, Quality Planning, Quality Control,
Software Measurement and Metrics.
SOFTWARE ARCHITECTURE
The design process for identifying the subsystems making up a system and the framework for
sub-system control and communication is architectural design.
The output of this design process is a description of the software architecture.
ARCHITECTURAL DESIGN
• An early stage of the system design process.
• Represents the link between specification and design processes.
• It involves identifying major system components and their communications.
The software needs the architectural design to represents the design of software. IEEE defines
architectural design as “the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of a
computer system.” The software that is built for computer-based systems can exhibit one of
these many architectural styles. Each style will describe a system category that consists of:
• A set of components (eg: a database, computational modules) that will perform a
function required by the system.
• The set of connectors will help in coordination, communication, and cooperation
between the components.
• Conditions that how components can be integrated to form the system.
• Semantic models that help the designer to understand the overall properties of the
system.
The use of architectural styles is to establish a structure for all the components of the system.
Taxonomy of Architectural styles:
1. Data centred architectures:
• A data store will reside at the centre of this architecture and is accessed frequently by
the other components that update, add, delete or modify the data present within the
store.
• The figure illustrates a typical data centred style. The client software accesses a central
repository. Variation of this approach are used to transform the repository into a

blackboard when data related to client or data of interest for the client change the
notifications to client software.
• This data-centred architecture will promote integrability. This means that the existing
components can be changed and new client components can be added to the
architecture without the permission or concern of other clients.
• Data can be passed among clients using blackboard mechanism.
2. Data flow architectures:
• This kind of architecture is used when input data to be transformed into output data
through a series of computational manipulative components.
• The figure represents pipe-and-filter architecture since it uses both pipe and filter and
it has a set of components called filters connected by pipes.
• Pipes are used to transmit data from one component to the next.
• Each filter will work independently and is designed to take data input of a certain
form and produces data output to the next filter of a specified form. The filters don’t
require any knowledge of the working of neighboring filters.
• If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of
sequential components to transform it.
3. Call and Return architectures: It is used to create a program that is easy to scale
and modify. Many sub-styles exist within this category. Two of them are explained
below.

• Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a
network.
• Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy. Main
program contains number of subprograms that can invoke other components.
4. Object Oriented architecture: The components of a system encapsulate data and the
operations that must be applied to manipulate the data. The coordination and
communication between the components are established via the message passing.
5. Layered architecture:
• A number of different layers are defined with each layer performing a well-defined
set of operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
• At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system interfacing
(communication and coordination with OS)
• Intermediate layers to utility services and application software functions.
ARCHITECTURE AND SYSTEM CHARACTERISTICS
Performance
• Localise critical operations and minimise communications.

Security
• Use a layered architecture with critical assets in the inner layers.
Safety
• Localise safety-critical features in a small number of subsystems.
Availability
• Include redundant components and mechanisms for fault tolerance.
Maintainability
• Use fine-grain, replaceable components.
SYSTEM STRUCTURING
Concerned with decomposing the system into interacting sub-systems.
The architectural design is normally expressed as a block diagram presenting an overview of
the system structure.
More specific models showing how sub-systems share data, are distributed and interface with
each other may also be developed.
Packing Robot Control System
ARCHITECTURAL DESIGN DECISIONS
There is no doubt how the architecture is important to shape the solution and define its
characteristics in the different architecture domains, and how this solution will be adaptable
and dynamic to absorb new business needs and handle different stakeholders’ concerns.
In most architecture development processes, different decisions are taken in the different
architecture domains. Architects may make different decisions, such as choosing a specific
component, in the conceptual architecture and follow a specific architecture pattern.
“In software engineering and software architecture design, architectural decisions (ADs)
are design decisions that address architecturally significant requirements; they are
perceived as hard to make and/or costly to change.”
A description of the set of architectural additions, subtractions and modifications to the
software architecture, the rationale, and the design rules, design constraints and additional
requirements that (partially) realize one or more requirements on a given architecture.

If architecture is the set of design decisions, then documenting the set of design decisions is
required as a way to document the architecture. In the tabular form shown below, may be the
most used attributes to document the architecture decision, while you can add or remove
some complexity as well.
Attributes Details
ID A unique identifier for each decision
Subject Area Area of concern, for example, data integrity
Decision Statement
Here we write as a statement indicating what the decision is e.g.
“Using cloud IaaS”.
Status Decision status, Not Decided or Decided
Problem Statement A short description of the problem.
Assumptions What are the assumptions in the context of the problem?
Constraints What are the constraints in the context of the problem?
Motivation Why this decision is important?
Alternatives A list of alternatives or options we have.
Argument / Decision
criteria
On which basis, you selected this option or alternative, it mainly
includes the criteria of selection, such as ease of implementation,
resources availability, expandability …etc.
Decision The decision we decided to have
Justification Why this decision was made and we selected it.
Implications What are the implications we might have after having this decision?
Derived requirements A list of requirements that are generated by this decision.
Owner/Major
Contributors The major contributors and owners who took this decision
SYSTEM ORGANIZATION
It reflects the basic strategy that is used to structure a system. There are three organizational
styles that are widely used:
• A shared data repository style;
• A shared services and servers style;
• An abstract machine or layered style.
The repository (data repository) model
Sub-systems must exchange data. This may be done in two ways:
• Shared data is held in a central database or repository and may be accessed by all sub-
systems;
• Each sub-system maintains its own database and passes data explicitly to other sub-systems.
Note: When large amounts of data are to be shared, the repository model of sharing is most
commonly used.
Advantages
• Efficient way to share large amounts of data;

• Sub-systems need not be concerned with how data is produced Centralised management e.g.
backup, security, etc.
• Sharing model is published as the repository schema.
Disadvantages
• Sub-systems must agree on a repository data model. Inevitably a compromise;
• Data evolution is difficult and expensive;
• No scope for specific management policies;
Client-Server (Services And Servers) Model
Distributed system model which shows how data and processing is distributed across a range
of components.
􀁺 Set of stand-alone servers which provide specific services such as printing, data
management, etc.
􀁺 Set of clients which call on these services.
􀁺 Network which allows clients to access servers.
Advantages
• Distribution of data is straightforward;
• Makes effective use of networked systems. May require cheaper hardware;
• Easy to add new servers or upgrade existing servers.
Disadvantages
• Data interchange may be inefficient;
• Redundant management in each server;
Abstract Machine (Layered) Model
Used to model the interfacing of sub-systems.
􀁺 Organises the system into a set of layers (or abstract machines) each of which provide a set
of services.
􀁺 Supports the incremental development of subsystems in different layers. When a layer
interface changes, only the adjacent layer is affected.

MODULAR DECOMPOSITION
Another structural level where sub-systems are decomposed into modules.
Two modular decomposition models covered:
• An Object Model where the system is decomposed into interacting object;
• A Pipeline or Data-Flow Model where the system is decomposed into functional modules
which transform inputs to outputs.
If possible, decisions about concurrency should be delayed until modules are implemented.
➢ OBJECT MODELS
Structure the system into a set of loosely coupled objects with well-defined interfaces.
Object-oriented decomposition is concerned with identifying object classes, their attributes
and operations.
When implemented, objects are created from these classes and some control model used to
coordinate object operations.
Advantages:
Objects are loosely coupled so their implementation can be modified without affecting other
objects.
The objects may reflect real-world entities.
OO implementation languages are widely used.
➢ FUNCTION-ORIENTED PIPELINING
• Functional transformations process their inputs to produce outputs.
• May be referred to as a pipe and filter model (as in UNIX shell).
Configuration Management System
Object Management System
Operating System
Database System

• Variants of this approach are very common. When transformations are sequential, this
is a batch sequential model which is extensively used in data processing systems.
• Not really suitable for interactive systems.
Advantages:
• Supports transformation reuse.
• Intuitive organisation for stakeholder communication.
• Easy to add new transformations.
• Relatively simple to implement as either a concurrent or sequential system.
• However, requires a common format for data transfer along the pipeline and difficult
to support event-based interaction.
CONTROL STYLES
It is concerned with the control flow between subsystems.
Centralised control: One sub-system has overall responsibility for control and starts and
stops other sub-systems.
Event-based control: Each sub-system can respond to externally generated events from
other sub-systems or the system’s environment.
CENTRALISED CONTROL
A control sub-system takes responsibility for managing the execution of other sub-systems.
Call-return model
• Top-down subroutine model where control starts at the top of a subroutine hierarchy and
moves downwards. Applicable to sequential systems.
Manager model
• Applicable to concurrent systems. One system component controls the stopping, starting
and coordination of other system processes.

EVENT-BASED SYSTEMS
Driven by externally generated events where the timing of the event is out with the control of
the sub-systems which process the event.
Two principal event-driven models:
• Broadcast models. An event is broadcast to all subsystems. Any sub-system which can
handle the event may do so;
Fig: Selective Broadcasting
• Effective in integrating sub-systems on different computers in a network.
• Sub-systems register an interest in specific events. When these occur, control is
transferred to the sub-system which can handle the event.
• Interrupt-driven models. Used in real-time systems where interrupts are detected by an
interrupt handler and passed to some other component for processing.
• Used in real-time systems where fast response to an event is essential.
• There are known interrupt types with a handler defined for each type.
• Each type is associated with a memory location and a hardware switch causes transfer
to its handler.
• Allows fast response but complex to program and difficult to validate.

• Interrupt Driven Control System
REFERENCE ARCHITECTURES
Architectural models may be specific to some application domain.
May be used as a basis for system implementation or to compare different systems.
OSI model is a layered model for communication systems.
Two types of domain-specific model:
• Generic Models which are abstractions from a number of real systems and which
encapsulate the principal characteristics of these systems.
• Reference models which are more abstract, idealised
model. Provide a means of information about that class of system and of comparing different
architectures.
Note: Generic models are usually bottom-up models; Reference models are top-down
models.
THE UNIFIED MODELING LANGUAGE
It is a general-purpose modelling language. The main aim of UML is to define a standard
way to visualize the way a system has been designed. It is quite similar to blueprints used
in other fields of engineering.

Several different notations for describing object-oriented designs were proposed in the 1980s
and 1990s.
The Unified Modeling Language is an integration of these notations.
It describes notations for a number of different models that may be produced during OO
analysis and design.
It is now a de facto standard for OO modelling.
Fig: Employee object class (UML)
It is not a programming language, it is rather a visual language. We use UML diagrams to
portray the behavior and structure of a system. UML helps software engineers,
businessmen and system architects with modelling, design and analysis. The Object
Management Group (OMG) adopted Unified Modelling Language as a standard in 1997. Its
been managed by OMG ever since. International Organization for Standardization (ISO)
published UML as an approved standard in 2005. UML has been revised over the years and
is reviewed periodically.
UML is linked with object oriented design and analysis. UML makes the use of elements
and forms associations between them to form diagrams. Diagrams in UML can be broadly
classified as:
1. Structural Diagrams – Capture static aspects or structure of a system.
Structural Diagrams include: Component Diagrams, Object Diagrams, Class
Diagrams and Deployment Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the system.
Behavior diagrams include: Use Case Diagrams, State Diagrams, Activity
Diagrams and Interaction Diagrams.

User Interface Design:
User interface is the front-end application view to which user interacts in order to use the
software. User can manipulate and control the software as well as hardware by means of user
interface. Today, user interface is found at almost every place where digital technology
exists, right from computers, mobile phones, cars, music players, airplanes, ships etc.
User interface is part of software and is designed such a way that it is expected to provide the
user insight of the software. UI provides fundamental platform for human-computer
interaction.
UI can be graphical, text-based, audio-video based, depending upon the underlying hardware
and software combination. UI can be hardware or software or a combination of both.
The software becomes more popular if its user interface is:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interfacing screens
UI is broadly divided into two categories:
• Command Line Interface
• Graphical User Interface
• Command Line Interface (CLI)
CLI has been a great tool of interaction with computers until the video display monitors came
into existence. CLI is first choice of many technical users and programmers. CLI is minimum
interface a software can provide to its users.

CLI provides a command prompt, the place where the user types the command and feeds to
the system. The user needs to remember the syntax of command and its use. Earlier CLI were
not programmed to handle the user errors effectively.
A command is a text-based reference to set of instructions, which are expected to be executed
by the system. There are methods like macros, scripts that make it easy for the user to
operate.
CLI uses less amount of computer resource as compared to GUI.
Design issues such as response time, command and action structure, error handling, and
help facilities are considered as the design model is refined. This phase serves as the
foundation for the implementation phase.
User Interface Design Process:
The analysis and design process of a user interface is iterative and can be represented by a
spiral model. The analysis and design process of user interface consists of four framework
activities.
1. User, task, environmental analysis, and modeling: Initially, the focus is based
on the profile of users who will interact with the system, i.e. understanding, skill
and knowledge, type of user, etc, based on the user’s profile users are made into
categories. From each category requirements are gathered. Based on the
requirements developer understand how to develop the interface. Once all the
requirements are gathered a detailed analysis is conducted. In the analysis part,
the tasks that the user performs to establish the goals of the system are

identified, described and elaborated. The analysis of the user environment
focuses on the physical work environment. Among the questions to be asked are:
• Where will the interface be located physically?
• Will the user be sitting, standing, or performing other tasks unrelated
to the interface?
• Does the interface hardware accommodate space, light, or noise
constraints?
• Are there special human factors considerations driven by
environmental factors?
2. Interface Design: The goal of this phase is to define the set of interface objects
and actions i.e. Control mechanisms that enable the user to perform desired
tasks. Indicate how these control mechanisms affect the system. Specify the
action sequence of tasks and subtasks, also called a user scenario. Indicate the
state of the system when the user performs a particular task. Always follow the
three golden rules stated by Theo Mandel. Design issues such as response time,
command and action structure, error handling, and help facilities are considered
as the design model is refined. This phase serves as the foundation for the
implementation phase.
3. Interface construction and implementation: The implementation activity
begins with the creation of prototype (model) that enables usage scenarios to be
evaluated. As iterative design process continues a User Interface toolkit that
allows the creation of windows, menus, device interaction, error messages,
commands, and many other elements of an interactive environment can be used
for completing the construction of an interface.
4. Interface Validation: This phase focuses on testing the interface. The interface
should be in such a way that it should be able to perform tasks correctly and it
should be able to handle a variety of tasks. It should achieve all the user’s
requirements. It should be easy to use and easy to learn. Users should accept the
interface as a useful one in their work.
USER ANALYSIS
User analysis is the process by which engineers, developers, and designers track how users
engage and interact with their software, product, or application in an attempt to improve their
product, bring more users in, improve user engagement with their product, and the general
success of their application.
To make sure you focus on the right metrics and know how to use the information you gather
properly, you must first understand why user analysis is so important, and what you stand to
gain from tracking user behaviors. Here are the main reasons:
• Understand how users engage with your product: Learn the features that are
most popular, how and why the product is used the way it is, and what your users
want from it
• Develop user profiles based on user actions and attributes: Establishing
distinct personas will help you understand how different groups of users interact
with your solution, which can help you design a more appealing product for each
group

• Gather quantifiable data on your users—This allows you to identify, detect,
and eventually predict trends and behavior by users
• Product design and development: Making the right decisions based on
informed metrics tracking and a detailed customer roadmap will improve
decision making as it relates to design changes, new/updated features, and
onboarding strategy
• Analyze and apply information: Product design and development updates
affect user experience, retention, churn, and conversion, so using your data to
inform this decision making is key to your success
USER INTERFACE (UI) PROTOTYPING
User interface (UI) prototyping is an iterative development technique in which users are
actively involved in the mocking-up of the UI for a system. UI prototypes have several
purposes:
• As an analysis artifact that enables you to explore the problem space with your
stakeholders.
• As a design artifact that enables you to explore the solution space of your system.
• A basis from which to explore the usability of your system.
• A vehicle for you to communicate the possible UI design(s) of your system.
• A potential foundation from which to continue developing the system (if you intend to
throw the prototype away and start over from scratch then you don't need to invest the
time writing quality code for your prototype).
USER INTERFACE EVALUATION
Validating the design is essential to the success of any application. The goal of user interface
evaluations is to make products and services more usable, easy to learn and intuitive for the
user. Learners create an evaluation strategy and validate user interfaces using evaluation
techniques and usability testing.
SOFTWARE PROJECT MANAGEMENT
It is a proper way of planning and leading software projects. It is a part of project
management in which software projects are planned, implemented, monitored and
controlled. It is a non-physical product. Software development is a new stream in business
and there is very little experience in building software products. Most of the software
products are made to fit client’s requirements. The most important is that the basic
technology changes and advances so frequently and rapidly that experience of one product
may not be applied to the other one. Such type of business and environmental constraints
increase risk in software development hence it is essential to manage software projects
efficiently.
It is necessary for an organization to deliver quality product, keeping the cost within
client’s budget constrain and deliver the project as per scheduled. Hence in order, software
project management is necessary to incorporate user requirements along with budget and
time constraints.
Software Project Management consists of several different type of managements:

1. Conflict Management:
Conflict management is the process to restrict the negative features of conflict
while increasing the positive features of conflict. The goal of conflict
management is to improve learning and group results including efficacy or
performance in an organizational setting. Properly managed conflict can enhance
group results.
2. Risk Management:
Risk management is the analysis and identification of risks that is followed by
synchronized and economical implementation of resources to minimize, operate
and control the possibility or effect of unfortunate events or to maximize the
realization of opportunities.
3. Requirement Management:
It is the process of analyzing, prioritizing, tracing and documenting on
requirements and then supervising change and communicating to pertinent
stakeholders. It is a continuous process during a project.
4. Change Management:
Change management is a systematic approach for dealing with the transition or
transformation of an organization’s goals, processes or technologies. The
purpose of change management is to execute strategies for effecting change,
controlling change and helping people to adapt to change.
5. Software Configuration Management:
Software configuration management is the process of controlling and tracing
changes in the software, part of the larger cross-disciplinary field of
configuration management. Software configuration management include
revision control and the inauguration of baselines.
6. Release Management:
Release Management is the task of planning, controlling and scheduling the
build in deploying releases. Release management ensures that organization
delivers new and enhanced services required by the customer, while protecting
the integrity of existing services.
Aspects of Software Project Management:

Advantages of Software Project Management:
• It helps in planning of software development.
• Implementation of software development is made easy.
• Monitoring and controlling are aspects of software project management.
• It overall manages to save time and cost for software development.
PROJECT PLANNING
Once a project is found to be possible, computer code project managers undertake project
designing. Project designing is undertaken and completed even before any development
activity starts. Project designing consists of subsequent essential activities:
Estimating the subsequent attributes of the project:
• Project size:
What’s going to be downside quality in terms of the trouble and time needed to
develop the product?
• Cost:
What proportion is it reaching to value to develop the project?
• Duration:
However long is it reaching to want complete development?
• Effort:
What proportion effort would be required?
The effectiveness of the following designing activities relies on the accuracy of those
estimations.

• planning force and alternative resources
• workers organization and staffing plans
• Risk identification, analysis, and abatement designing
• Miscellaneous arranges like quality assurance plan, configuration, management
arrange, etc.
RISK MANAGEMENT
"Tomorrow problems are today's risk." Hence, a clear definition of a "risk" is a problem that
could cause some loss or threaten the progress of the project, but which has not happened yet.
These potential issues might harm cost, schedule or technical success of the project and the
quality of our software device, or project team morale. Risk Management is the system of
identifying addressing and eliminating these problems before they can damage the project.
We need to differentiate risks, as potential issues, from the current problems of the project.
Different methods are required to address these two kinds of issues.
For example, staff storage, because we have not been able to select people with the right
technical skills is a current problem, but the threat of our technical persons being hired away
by the competition is a risk.
Any software project can be concerned with a large variety of risks. In order to be adept to
systematically identify the significant risks which might affect a software project, it is
essential to classify risks into different classes. The project manager can then check which
risks from each class are relevant to the project.
There are three main classifications of risks which can affect a software project:
➢ Project Risks:
Project risks concern various sorts of monetary funds, schedules, personnel,
resource, and customer-related issues. a vital project risk is schedule slippage. Since
computer code is intangible, it’s terribly tough to observe and manage a computer
code project. it’s terribly tough to manage one thing that can not be seen. For any
producing project, like producing cars, the project manager will see the merchandise
taking form.
For example, see that the engine is fitted, at the moment the area of the door unit
fitted, the automotive is obtaining painted, etc. so he will simply assess the
progress of the work and manage it. The physical property of the merchandise
being developed is a vital reason why several computer codes come to suffer
from the danger of schedule slippage.
➢ Technical Risks:
Technical risks concern potential style, implementation, interfacing, testing, and
maintenance issues. Technical risks conjointly embody ambiguous specifications,
incomplete specification, dynamic specification, technical uncertainty, and technical
degeneration. Most technical risks occur thanks to the event team’s lean information
concerning the project.

➢ Business Risks:
This type of risk embodies the risks of building a superb product that nobody needs,
losing monetary funds or personal commitments, etc.
Other risk categories
1. 1. Known risks: Those risks that can be uncovered after careful assessment of the
project program, the business and technical environment in which the plan is being
developed, and more reliable data sources (e.g., unrealistic delivery date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to
identify in advance.
SOFTWARE QUALITY MANAGEMENT
It ensures that the required level of quality is achieved by submitting improvements to the
product development process. SQA aims to develop a culture within the team and it is seen
as everyone's responsibility.
Software Quality management should be independent of project management to ensure
independence of cost and schedule adherences. It directly affects the process quality and
indirectly affects the product quality.
• Quality means that a product satisfies the demands of its specifications
• It also means achieving a high level of customer satisfaction with the product
• In software systems this is difficult
– customer quality requirements (e.g. efficiency or reliability) often conflict
with developer quality requirements (e.g. maintainability or reusability)
– software specifications are often incomplete, inconsistent, or ambiguous
Activities of SQM:
• Quality Assurance - QA aims at developing Organizational procedures and
standards for quality at Organizational level.
• Quality Planning - Select applicable procedures and standards for a particular
project and modify as required to develop a quality plan.
• Quality Control - Ensure that best practices and standards are followed by the
software development team to produce quality products.
PROCESS AND PRODUCT QUALITY
Product:
In the context of software engineering, Product includes any software manufactured based
on the customer’s request. This can be a problem solving software or computer based
system. It can also be said that this is the result of a project.

Process:
Process is a set of sequence steps that have to be followed to create a project. The main
purpose of a process is to improve the quality of the project. The process serves as a
template that can be used through the creation of its examples and is used to direct the
project.
The main difference between a process and a product is that the process is a set of steps that
guide the project to achieve a convenient product. while on the other hand, the product is
the result of a project that is manufactured by a wide variety of people.
product quality means we concentrate always final quality but in case of process quality we set
the process parameter.
QUALITY STANDARDS
• Should involve practitioners in their development
• Engineers must understand the rationale behind each standard
• Standards must be reviewed and revised regularly to avoid obsolescence and
credibility problems with practitioners
• Detailed standards need tool support to eliminate the “too much clerical work”
excuse for not following the standards
QUALITY PLANNING
Every project delivers something at the end of the project execution. When it comes to the
project initiation, the project management and the client collaboratively define the objectives
and the deliveries of the project together with the completion timelines.
During the project execution, there are a number of project deliveries made. All these
deliveries should adhere to certain quality standards (industry standards) as well as specific
client requirements.
Therefore, each of these deliveries should be validated and verified before delivering to the
client. For that, there should be a quality assurance function, which runs from start to the end
of the project.
When it comes to the quality, not only the quality of the deliveries that matter the most. The
processes or activities that produce deliverables should also adhere to certain quality
guidelines as well.
Project Quality Plan Elements
Depending on the nature of the industry and the nature of the project, the components or the
areas addressed by a quality plan may vary. However, there are some components that can
be found in any type of quality plan.
Let's have a look at the most essential attributes of a project quality plan.
Responsibility of Management
This describes how the management is responsible for achieving the project quality. Since
management is the controlling and monitoring function for the project, project quality is
mainly a management responsibility.

Document Management and Control
Documents are the main method of communication in project management. Documents are
used for communication between the team members, project management, senior
management and the client.
Therefore, the project quality plan should describe a way to manage and control the
documents used in the project. Usually, there can be a common documentation repository
with controlled access in order to store and retrieve the documents.
Requirements Scope
The correct requirements to be implemented are listed here. This is an abstraction of the
requirements sign-off document. Having requirements noted in the project quality plan helps
the quality assurance team to correctly validate them.
This way, quality assurance function knows what exactly to test and what exactly to leave
out from the scope. Testing the requirements that are not in the scope may be a waste for the
service provider.
Design Control
This specifies the controls and procedures used for the design phase of the project. Usually,
there should be design reviews in order to analyse the correctness of the proposed technical
design. For fruitful design reviews, senior designers or the architects of the respective
domain should get involved. Once the designs are reviewed and agreed, they are signed-off
with the client.
With the time, the client may come up with changes to the requirements or new
requirements. In such cases, design may be changed. Every time the design changes, the
changes should be reviewed and signed-off.
Development Control and Rigor
Once the construction of the project starts, all the processes, procedures and activities should
be closely monitored and measured. By this type of control, the project management can
make sure that the project is progressing in the correct path.
Testing and Quality Assurance
This component of the project quality plan takes precedence over other components. This is
the element, which describes the main quality assurance functions of the project. This
section should clearly identify the quality objectives for the project and the approach to
achieve them.
Risks & Mitigation
This section identifies the project quality risks. Then, the project management team should
come up with appropriate mitigation plans in order to address each quality risk.
Quality Audits
For every project, regardless of its size or the nature, there should be periodic quality audits
to measure the adherence to the quality standards. These audits can be done by an internal
team or an external team.
Sometimes, the client may employ external audit teams to measure the compliance to
standards and procedures of the project processes and activities.

Defect Management
During testing and quality assurance, defects are usually caught. This is quite common when
it comes to software development projects. The project quality plan should have guidelines
and instructions on how to manage the defects.
Training Requirements
Every project team requires some kind of training before the project commences. For this, a
skill gap analysis is done to identify the training requirements at the project initiation phase.
The project quality plan should indicate these training requirements and necessary steps to
get the staff trained.
Conclusion
Project quality plan is one of the mandatory documents for any type of project.
As long as a project has defined objectives and deliverables, there should be a project
quality plan to measure the delivery and process quality.
QUALITY CONTROL
It is a set of methods used by organizations to achieve quality parameters or quality goals
and continually improve the organization's ability to ensure that a software product will meet
quality goals.
Quality Control Process:
The three class parameters that control software quality are:
• Products
• Processes
• Resources
The total quality control process consists of:
• Plan - It is the stage where the Quality control processes are planned

• Do - Use a defined parameter to develop the quality
• Check - Stage to verify if the quality of the parameters are met
• Act - Take corrective action if needed and repeat the work
Quality Control characteristics:
• Process adopted to deliver a quality product to the clients at best cost.
• Goal is to learn from other organizations so that quality would be better each time.
• To avoid making errors by proper planning and execution with correct review
process.
SOFTWARE MEASUREMENT AND METRICS
A measurement is a manifestation of the size, quantity, amount or dimension of a particular
attributes of a product or process. Software measurement is a titrate impute of a
characteristic of a software product or the software process. It is an authority within
software engineering. Software measurement process is defined and governed by ISO
Standard.
Need of Software Measurement:
Software is measured to:
1. Create the quality of the current product or process.
2. Anticipate future qualities of the product or process.
3. Enhance the quality of a product or process.
4. Regulate the state of the project in relation to budget and schedule.
Classification of Software Measurement: This is of two types.
1. Direct Measurement:
In direct measurement the product, process or thing is measured directly using
standard scale.
2. Indirect Measurement:
In indirect measurement the quantity or quality to be measured is measured
using related parameter i.e. by use of reference.
Metrics:
A metrics is a measurement of the level that any impute belongs to a system product or
process.
There are 4 functions related to software metrics:
1. Planning
2. Organizing
3. Controlling
4. Improving
Characteristics of software Metrics:

1. Quantitative:
Metrics must possess quantitative nature. It means metrics can be expressed in
values.
2. Understandable:
Metric computation should be easily understood, the method of computing
metric should be clearly defined.
3. Applicability:
Metrics should be applicable in the initial phases of development of the
software.
4. Repeatable:
The metric values should be same when measured repeatedly and consistent in
nature.
5. Economical:
Computation of metric should be economical.
6. Language Independent:
Metrics should not depend on any programming language.
Classification of Software Metrics: This is of 2 types.
1. Product Metrics:
Product metrics are used to evaluate the state of the product, tracing risks and
undercovering prospective problem areas. The ability of team to control quality
is evaluated.
2. Process Metrics:
Process metrics pay particular attention on enhancing the long-term process of
the team or organisation.
3. Project Metrics:
Project matrix describes the project characteristic and execution process.
• Number of software developer
• Staffing pattern over the life cycle of software
• Cost and schedule
• Productivity

Software architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software architecture

Similar to Software architecture (20)

More from Sweta Kumari Barnwal

More from Sweta Kumari Barnwal (20)

Recently uploaded

Recently uploaded (20)

Software architecture