CHP1

ARCHITECTURAL DESIGN

● Architectural design is concerned with understanding how a system should

be organized and designing the overall structure of that system.
● In the model of software development process architectural design is the
first stage in the software design process. Application systems are
intended to meet a business or organizational need. All businesses have
much in common-they need to hire people, issue invoices, keep accounts,
and so on.
● Businesses operating in the same sector use common sector specific
applications. Application architectures encapsulate the principal
characteristics of a class of systems.
● For example, in real-time systems, there might be generic architectural
models of different system types, such as data collection systems or
monitoring systems. Although instances of these systems differ in detail,
the common architectural structure can be reused when developing new
systems of the same type.
● The application architect may be re-implemented when developing new
systems but, for many business systems, application reuse is possible
without re implementation.

Architectural Design
The architecture of a system describes its major components, their relationships
structures, and how they interact with each other.
Architectural design is also called high-level design.
Software architecture and design includes several related factors such as
Business strategy, quality attributes, human dynamics, design, and IT
environment.
The architectural design defines the relationship between major structural
elements of the software, the “design patterns” that can be used to achieve the
requirements that have been defined for the system, and the constraints that
affect the way in which architectural design patterns can be applied.

The architectural design representation—the framework of a computer-based

system—can be derived from the system specification, the analysis model, and
the interaction of subsystems defined within the analysis model.

The interface design describes how the software communicates within itself,
with systems that interoperate with it, and with humans who use it. An interface
implies a flow of information (e.g., data and/or control) and a specific type of
behavior. Therefore, data and control flow diagrams provide much of the
information required for interface design.

The component-level design transforms structural elements of the software

architecture into a procedural description of software components. Information
obtained from the PSPEC, CSPEC, and STD serve as the basis for component
design.
Architectural design decisions

● Architectural design is a creative process where you design a system

organization that will satisfy the functional and non-functional requirements
of a system.
● Because it is a creative process, the activities within the process depend
on the type of system being developed, the background and experience of
the system architect, and the specific requirements for the system.
● It is therefore useful to think of architectural design as a series of decisions
to be made rather than a sequence of activities.
● During the architectural design process, system architects have to make a
number of structural decisions that profoundly affect the system and its
development process.
● Based on their knowledge and experience, they have to consider the
following fundamental questions about the system:
1. Is there a generic application architecture that can act as a template for
the system that is being designed?
2. How will the system be distributed across a number of cores or
processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into
subcomponents?
6. What strategy will be used to control the operation of the components in
the system?
7. What architectural organization is best for delivering the non-functional
requirements of the system?
8. How will the architectural design be evaluated?
9. How should the architecture of the system be documented?

Because of the close relationship between non-functional requirements

and software architecture, the architectural style and structure that you
choose for a system should depend on the non-functional system
requirements:
SYSTEM PROPERTIES focused in Architectural Design Process
The various attributes of architecture are as follows:
1. Performance: If performance is a critical requirement, the architecture should
be designed to localize critical operations within a small number of components,
with these components all deployed on the same computer rather than
distributed across the network. This may mean using a few relatively large
components rather than small, finegrain components, which reduces the number
of component communications. You may also consider run-time system
organizations that allow the system to be replicated and executed on different
processors.
2. Security: If security is a critical requirement, a layered structure for the
architecture should be used, with the most critical assets protected in the
innermost layers, with a high level of security validation applied to these layers.
3. Safety: If safety is a critical requirement, the architecture should be designed
so that safety related operations are all located in either a single component or in
a small number of components. This reduces the costs and problems of safety
validation and makes it possible to provide related protection systems that can
safely shut down the system in the event of failure.
4. Availability: If availability is a critical requirement, the architecture should be
designed to include redundant components so that it is possible to replace and
update components without stopping the system. I describe two fault-tolerant
system architectures for high-availability systems.
5. Maintainability: If maintainability is a critical requirement, the system
architecture should be designed using fine-grain, self-contained components that
may readily be changed.
System Organization/Explain system organization models in detail
It is about the basic strategy of structuring a system.
Three organizational models or styles are used to structure a system:

1. Repository model
2. Client server model
3. Abstract Model

1. Repository Model

● This shared data repository style is used when a large amount of

data is to be shared. It represents the exchange of data among the
various components.
● This can be done in two ways:
○ 1. Shared data is put in a central database or repository and
○ 2. Is available to be accessed by all components
● Each component has its own database and messages explicitly to
other components.
 Advantages
1. It is perfect way to share large amounts of data
2. Components need not be concerned with how data is managed
at centralized level i.e, the components need not worry about issues
like backup and security of data, etc.

Disadvantages
1. Components must compromise on a repository data model.
2 Data evolution using such a model is difficult and expensive
3. No specific management policies
4. Difficult to distribute the data efficiently

2. Client-Server Model
● It is a shared services and servers style
● It represents how data and processing is distributed across the
various components.
● It involves a set of independent servers that provide specific services
such as printing data management,etc.
● It also involves a set of clients which call on these services.
● It also involves a network through which clients can access the
servers.
 Advantages
1. Client-Server model allows straightforward distribution of data.
2. It allows effective use of networked systems and thus requires
comparably cheaper hardware than the repository model.
3. Easy to add new servers and modify existing servers.

Disadvantages
1. No involvement of shared data model and so data interchange
among components may be inefficient.
2. It leads to redundant ie. duplication or functions in each server.
3. No facility for central registration of name and services. Thus, it is
hard to locate which servers and services are available.

3. Abstract Model
● It is used to represent a layered style.
● Used to model the communication among the subsystems.
● Organizes the system into a set of abstract layers and each layer
provides a set of services.
● Allows incremental development of components at different layers.
Thus, if a layer interface change only the adjacent layer is affected
and not all other layers.
Modular Decomposition Styles

● It represents various styles of decomposing subsystems into

modules.
● A sub-system is a stand-alone system whose operations are
independent of the services provided by other subsystems.
● A module is a system component that provides services to other
components and is itself dependent on the services provided by
other components it is not normally considered as a separate system
● Modular Decomposition is a structural level where sub-systems
are decomposed into modules.
The most common decomposition models are:
1.An object model: The system is decomposed into loosely coupled
objects with an interacting interface. This model identifies object
classes, their attributes (properties) and functions.
2. A pipeline or data-flow model: The system is decomposed into
functional modules which process and transform their inputs to
produce outputs.

❖ Advantages
1. Supports the reuse of input-output processing.
2. Allows natural stakeholder communication.
2. Allows adding new input-output transformations easily.
4. Simple to implement compared to object model.
❖ Drawback
It is difficult to support event-based interaction through a pipeline model.
Control Styles

● It is about the control flow between various sub systems

● The two most common control styles available are:


1. Centralized control
● Any ONE component has overall responsibility to control the starts
and stops of other components of the system.
● This controlling subsystem has the responsibility of managing the
execution of other sub-systems.
● Two common centralized control models are:
● Physical Layer − It defines the electrical, mechanical and procedural and

functional specifications required for activating, maintaining and

deactivating the physical links between the systems.

● Data Link Layer − It is concerned with error free and reliable

communication between various machines in the network.

● Network Layer − It manages the delivery of individual data packets from

source to destination.

● Transport Layer −It is responsible for delivery of the entire message from

the source host to destination host.

● Session Layer − It defines how to start, control and end the conversations

between applications. It also enables easy and efficient data transfer.

● Presentation Layer − It translates between the multiple data forms using

encryption and compression of data. It includes data forms like Jpeg,

mpeg, ascii,html,etc

● Application Layer − It provides high-level APIs (application program

interface) such as spreadsheet programs, word processing programs to

the users.
 CHP 2
USER INTERFACE DESIGN

User Interface Design

● Good programming technology alone is not enough to achieve
user's acceptance of software products. It also needs a good user
interface else it fails in the market.
● While programming technology focuses on the functions of the
software, user interface focuses on the usability specialists.
● When User Interface Design is applied to software, it is also known
as Human-Computer Interaction (HCI).
● User Interface Design refers to the products where a user interacts
with controls or displays of the product
● Few examples where UI is required are Military aircraft, vehicles,
audio equipment, and computer peripherals.
● UI becomes efficient only after performing Usability Testing. This is
done to test what works and what does not work as expected. Only
after making the repairs, the product is said to have an optimized
interface

Need of UI Design/What is the need of User-interface design?

● ‘ How the user feels’ when working with the product is the key to
acceptance. And that's why, the User Interface Design is necessary
in the design process.
● A good User Interface Design can make a product to be accepted or
rejected in the market
● If end-users feel it is difficult to learn and use then even an excellent
product could fail.
● Good User Interface Design is which makes a product easy to
understand and use and thus ultimately sts in greater user
acceptance.
● A good user interface is logical and consistent and helps users to
recover from errors.
Interface Design Issues/Brief the issues that should be considered
while Designing the user-interface
● There are few issues that are to be considered while designing a
good user interface.
● These issues should be taken care of so that they do not cause any
technical problems.
The design issues include:
1. Response time
● This is the mean time between request and response of the software
with desired output.
● Response time can be measured in length and Variability
● If the response time is too long then the user becomes
frustrated.Variability means deviation from the average response
time.
● Low variability is preferred even if the response time is leng.
For example, 1 second response to a request is preferable to a
response that varies from 0.5-2.5 seconds.
2. Help facilities
● The end user requires help in two cases:
1. When he reeds some information and he is not able to find it
2. if the end user is in trouble.
● Both of these requirements must be considered in the help system
design and must be available all the time to the user.
● Generally, the HELP is presented using a help menu or a special
function key
3. Error handling
● Error message design is very much important. Poor error messages
may result in rejecting the product rather than accepting it.
● The error message should describe the problem in words that are
understood by a user, it should provide error correcting advice, and
the most important is that the wordings in the message should never
blame the user.
4. Menu and command labeling
● In menu labeling, a user makes the selection by clicking with a
mouse, using cursor keys or by typing the name of the selection.
● In command labeling, user types commands to give instructions to
the system such as UNIX.
 ● Menu labeling is included in window oriented interfaces which is
most commonly used in these days as it is easier to understand.
● But it involves some issues like: does every menu has a
corresponding command associated with it are menu labels
self-explanatory and are submenus consistent with their mast
menus.
5. Application accessibility
● It states whether the application is simple to interact with or not.
● It is about whether the system is usable without continual help and is
it fault tolerant and does the user know where he is in the system at
all times.
● Special guidelines are given to the users interacting with any type of
application may it be through visual, hearing, speech or mobility.
6. Internationalization
● The application should be usable by any type of end users located in
different locales and speaking different languages.
● Often the interfaces are developed in one particular language and
then they are incapable to work in other countries.
● The challenge for interface designers is to design the application that
is globalized rather than localization that limits the software to work
only in a specific market.
UI Design Process/Explain the UI design process in detail.
The UI design process is an iterative process represented by a spiral
model.

The UI design process is categorized into 4 major activities:

1. Interface Analysis i.e. User, task and environmental analysis
Interface analysis means evaluating the UI design with end users in-order
to:
○ Understand the end-users who will interact with the system through
the UI.
○ Confirm the tasks that end-users will perform to do their work.
○ Understand the content that should be displayed on the interface.
○ Understand the hardware and software environment on which these
tasks will be implemented.

● The user analysis activity refers to the skill level and business needs
of the end users who will interact with the system.
● The requirements of each user category are gathered with an
attempt to understand the system perception from the point of view
of each category of the users.
● Once the requirements are gathered, the task analysis is conducted.
Here, the tasks that will be performed by the user to accomplish his
work are identified and described.
● The environment analysis focuses on the questions like where will
the interface be located physically and will the user perform other
tasks unrelated to the Interface.
2. Interface Design
● This phase defines a set of interface objects and actions that allow a user
to perform all the tasks that are defined in the user requirement analysis
phase.
● It is an attempt to confirm that the designed tasks meet every usability goal
defined in the user requirements
3. Implementation
● This activity normally involves prototyping and then the actual
implementation
● The output of the prototyping is used for implementation
4. Interface Validation
This focuses on:
● The ability of Ul to implement every user task correctly
● The degree to which the UI is easy to use and learn.
● User's acceptance about the interface as an efficient tool in their work.

User Analysis
● It is all about understanding the users and how they will use the system
● This information can be gathered through various source:
1. User Interviews
● Members of the software developing team meet the end users; motivate
them to tell about their needs and work culture in a consistent manner.
● This is more generally achieved by conducting one-to one meetings or
group meetings
2. Sales team input
● Members of the sales team meet the end users on a regular basis to
gather information and help the software development team.
3. Marketing team input
● Market analysis identifies how various market segments use the software
in different ways
4. Support staff input
● They talk with the users on regular basis to identify what works and what
doesn't, what users like and what they don't like, what features are easy to
use and what are difficult to understand
● Following is a list of questions that are asked during the above defined
meetings so as to better understand the users of the system:
1. Are end users trained professionals, technicians or clerks?
 2. What level of basic education does the average and user have?
3. Are the users capable of learning from manuals or do they need
classroom training?
4. Are the user expert typists or feel it is hard to use the keyboard?
5. What is the age range of the users?

User Interface Prototyping

● Prototyping is all about modeling the system before the actual
implementation.
● Prototyping helps the UI designers to cross check with user expected
functions and get user's feedback whether the system model is appropriate
or not.
● Ul prototype is first evaluated and then used for implementation. Only if
the prototype passes the user acceptance in the evaluation round then
only, it is used as a base for actual implementation.
● After designing a prototype, the resulting model is evaluated for quality.
There are 4 different steps of models that are designed when a user
interface is to be prototyped:
1 User Model:
● It is the profile of all end users who will be using the system.
● In order to build a good interface it is necessary to have data about the
age, sex, physical capabilities, education level, cultural background and
prosperity of the system users.
● We can categorize the users of the system based upon the interface
knowledge they are having:
○ Novices: They don't have any syntactic knowledge(It refers to the
rules and regulations for writing any statement in a programming
language like C/C++.It does not have to do anything with the
meaning of the statement.) of how the system interface is, have little
semantic design knowledge about the interface.
○ Knowledgeable and intermittent(stopping for a short time and then starting
again several times) users: They have enough semantic knowledge(It
refers to the meaning associated with the statement in a
programming language) of the system but low syntactic knowledge
as much necessary to use the interface.
 ○ Knowledgeable and frequent users: They have good semantic as
well as good syntactic knowledge of the system and this makes such
users to often look for shortcuts and abbreviated modes of
Interaction.
2. Design Model:
It is the design realization of the user model. This model should confirm to all the
user expectations specified in the requirement analysis phase.
3. System perception model (Mental model)
It represents the user's mental view about how the interface looks and works. It is
about the view of the system that users carry in their mind.
4.System image model (Implementation Model):
● It represents the look and feel of the system combined with supporting
information (like manuals and help files) that describe the system's
interface syntax and semantics.
● Users feel satisfied about the interface only when the system perception
and system image models are coincident.
● And this coincidence is achieved only when the design model is developed
to accommodate the information described in the user model
● The successful designing of all these models is based upon the key
elements- know the user and know the tasks

Interface Evaluation/What is the need of Ul evaluation and explain the

steps involved in Ul evaluation
● Once the user interface prototype is created through the above defined
modeling steps, the next step is evaluation of the prototype model.
● Evaluation is done to find whether the model meets the user requirements
or not.
Need of Evaluation
● Some evaluation of UI design is carried out to judge its suitability.
● Full scale evaluation is very costly and impractical for most systems
● An interface is actually evaluated against its usability attributes.

Usability Attributes
● Learnability is how long it takes for a new user to cope with the system
● Operating speed is how fast the system gives response to the user's
request.
● Robustness is how efficient the system is in tolerating the user errors
 ● Recoverability is how good the system is at recovering from user made
errors.
● Adaptability is how efficiently the system can cope with different user
environments
Steps involved in the UI Evaluation
● Step 1: UI designer creates a preliminary design of the system.
● Step 2 : After the design is completed, a first-level prototype is created.
● Step 3 : The prototype is then evaluated by the users of the system. They
provide their feedback to the designers about the efficacy of the system
interface.
● Step 4: The evaluation is done through formal methods Iike-
○ numeric response type,
○ questionnaires to get user's feedback (questionnaires can be
simples yes/no type,
○ scaled response type or percentage response type rating sheets,
○ video recording of system use and subsequent tape evaluation, etc.
then the designer studies this evaluation feedback and extracts information
from this data.
● Step 5: UI designer makes modifications based upon the user feedback
and the next level prototype is developed
This evaluation cycle continues until no further modifications are recommended
by the user i.e, until the user accepts the prototype.
 CHP 3
PROJECT MANAGEMENT

Software Project Management/Why Software Project Management is

needed?
● A software project is the process executed in order to produce a software
product in a given time.
● This process includes software development steps from requirement
gathering to testing and maintenance.

->Need of software project management

● Software projects are needed to manage because of the occurrence of
business and environment risks given as follows in the project
development process.
● Software is said to be an intangible product.
● In business, Software development is a new thing so very little experience
in developing software products.
● Many software products are developed according to client's requirements
so they are only useful to those specific clients.
● The software products which are developed for business and used by
business clients become outdated due to the introduction of newer and
advanced technology in business. As the technology advances frequently
a product may not be applied to the other one or it is outdated after some
decades.
● The Time, Cost and Quality are constraints of software projects. Means
that the project should be delivered at scheduled time, with good quality
and in the customer's budget. If one of the constraints is not followed then
it will affect the other two.
● A person who is responsible for the software project management is known
as a software project manager. He/ She controls and monitors the project
management activities performed while developing the software product.
● He/she is responsible to do following tasks:
The project manager manages the people:
○ The project manager acts as project leader
○ The project manager Liaison with stakeholders
○ The project manager manages the human resources.
○ The project manager is responsible for setting the report hierarchy.
 ● The project manager manages the project:
○ The project manager defines and sets project scope
○ The project manager handles the project management activities
○ The project manager monitors the performance and progress of the
project
○ The project manager analyzes the risk at each phase of
development and handles them if they exist.
○ The project manager also acts as project spokesperson

Management Activities/Q. Describe various Management Activities

Many managers are responsible to execute some or all of the following
Management Activities involved in the Project Management:

● Project Proposal Writing

● Project planning and scheduling
● Project costing
● Project monitoring and reviews
● Personnel selection and evaluation
● Report writing and presentations

● The first four activities are grouped under the project planning, whereas
the last two are performed when running the project. All these activities
are performed iteratively.
● Writing a proposal is the initial step of a software project. While writing the
project proposal it is needed to justify why the particular project is assigned
to a specific team or an organization. This proposal illustrates the project
objectives and the plan to carry out the project. The cost and schedule
estimation is also contained in the proposal.
● There may be various organizations competing to get specific project
contracts. And among several proposals only the more effective proposal
is accepted and awarded the contract to the respective organization. Many
of the organization's existence are dependent on the number of proposals
it has. That's why the proposal writing is a critical task. The proposal
writing skill is achieved by experience.
● Project planning involves first identification of the activities, milestones and
project deliverables, and then a plan is formed which is to be executed for
 developing the project to produce estimated product in time and with good
quality.
● Cost estimation involves the estimation of resources which are needed to
successfully carry out the project plan
● An ongoing project activity, i.e. Project monitoring is done by the project
manager where he / she keeps examining the project progress and
compares it with planned progress and costs. Many organizations use
formal methods to do project monitoring But also by informal discussion
with project staff, a manager can understand the project progress.
● The informal monitoring predicts the possible risks, for example, because
of daily discussions with project staff the manager will know that
The project budget is low so instead of highly paid staff, less experienced
and less well-paid staff should be assigned to this project.
The appropriate experienced staff is assigned to other important projects
so there is a need to hire new staff to the project.
● The inexperienced staff are developing their skills while working on that
project and at least one project member is experienced and familiar with
the system used to develop the project. If no one is experienced there may
be chances of many simple mistakes made by the project members.
● The client and the organization who wins the contract get the report of the
project by the project manager. The Project manager is also responsible to
write short and abstract critical information from detailed project report and
use this information during the progress reviews

Project Planning/Q. Explain project planning.

● Before starting the actual production the planning is done. It is an ongoing

project management activity which starts from initial stage of the project
development to the project delivery.
● It involves creation of a set of plans which will help project members to
guide and manage time, cost, quality risks.

● Project planning involves following processes:

 1. Scope planning: In project planning the initial process is to define the project
scope, and determining the appropriate methods to accomplish the project in this
in-scope requirements are specified which facilitates the work-breakdown
structure creation.
2. Preparing the work breakdown structure: Followed by scope planning work
breakdown structure is constructed. In this the project is spitted into tasks and
subtasks, and forms a work breakdown structure by grouping and listing the
required duration of various task to accomplish the work
3. Project scheduling: This will list the schedules of activities involved in the
project and the implementation sequences.
4. Resource planning: It will concern the things which are responsible to
accomplish the project. That is it will signify who will do what work? At which
time? And if special skills are needed to accomplish the tasks.
5. Budget planning: it will estimate how much cost or budget is required to
accomplish the project. Also the required resources and the ways in which they
are used to balance the cost and time are estimated
6. Risk management: It involves the risk planning and migration strategy used
to handle the risks
7. Quality planning: to generate the quality product. The quality of product is
checked with respect to some already defined quality criteria
8. Communication planning: This will plan the communication strategy used to
communicate with stakeholders.

Project Scheduling/Explain Project scheduling

● The project schedule is a calendar that is used to associate the tasks to be
performed with the resources that will perform them. Before a project
schedule is estimated, the project manager designs a work breakdown
structure (WBS) which is an attempt to estimate the time needed to
implement each task and the resources that are available for
accomplishing each task.
● Project Scheduling is dependent on project managers' intuition and
experience.

❖ Project Scheduling Process

● Divide the project into various tasks and estimate the duration and
resources required to complete each task.
● Arrange the tasks so as to make optimal use of the workforce.
● Reduce the task dependencies so as to avoid delays that might be caused
by some task i.e. waiting for another to complete.

❖ Scheduling Problems
● Detecting the complexity of the problems and accordingly estimating the
cost of developing a solution is difficult.
● Achieved productivity is not proportional to the number of people working
on it.
● Adding new staff in the late project development moves the delivery date
further far because of the communication gap between old staff and new
staff.
● Always unforeseen events happen in the project development and these
need to be considered in the planning.
❖ Basic principles of Project Scheduling
● Project scheduling is about distributing or allocating the estimated efforts to
specific software engineering tasks across the planed project duration
● Project scheduling builds a road map for the project manager when
combined with estimation methods and risk analysis
1. Compartmentalisation The project must be categorized into a number
of manageable activities, actions and tasks by decomposing the process
into sub processes.
2. Interdependency: Few compartmentalized activities, actions, or tasks
occur in sequence where they are interdependent upon each other and
while others occur in parallel
3. Time allocation Scheduling is very important where each task must be
allocated some number of work units, defining their start date and
completion date especially in case of the inter dependencies and also state
whether work will be conducted on a full-time or part-time basis.
4. Effort allocation: The project manager must allocate a number of
people that must be present at any given point of time.
5. Effort validation: The project manager must monitor that no more than
the allocated number of people are present at any given point of time.
6. Defined responsibilities: Every task that is scheduled must be
assigned to a specific team member.
 7. Defined outcomes: Every task that is scheduled must have a defined
outcome
8.Defined milestones: Each set of tasks must be associated with a
project milestone. And the milestone is said to be accomplished only when
associated tasks are reviewed for quality.

Risk Management
Risk management is one of the most important job opportunities for a project
manager.
Risk management involves predicting risks that might affect the timetable for the
project or the quality of the software being established, and then acting to
prevent these risks.
❖ Three related types of risk:
1. Project risks: Risks that influence the project schedule or resources. An
example of a development risk is the loss of an experienced designer.
Discovering a replacement designer with appropriate knowledge and experience
may take a long time and, therefore, the software design will take a long time to
complete.
2. Product risks: Risks that influence the quality or performance of the
software being created. An example of a product risk is the failure of a purchased
component to work as expected. This may affect the overall performance of the
system in such a way that it is slower than expected.
3. Business risks: Risks that affect the company expanding or procuring the
software. For example, the competitor introducing a new product is a corporate
risk. The introduction of a competitive product may mean that the underlying
assumptions made about sales of existing software products might be unduly
optimistic.
❖ The stages involved in risk management are:
1. Risk identification You need to identify possible project, produce, and
business risks.
2. Risk analysis You should assess the probability and consequences of these
risks.
3. Risk planning You should make proposals to address the risk, either by
avoiding it or else minimizing its impact on the project.
4. Risk monitoring You should regularly evaluate the risk and your plans for
probability mitigation and modify these when you learn more about the risk.
Risk Management Process
The risk management process is the iterative process that is progressing
throughout the entire project. Once you have been prepared in accordance with
an initial risk management plan, you have the ability to monitor the problem to
detect emerging dangers.

1.Risk Identification Risk identification is the initial phase of the

risk-management process. It is worried about pinpointing the risks that could
constitute a serious threat to the software engineering process, the computer
software being developed, or development within the enterprise.
Hazard identification may be a team process where a team get together to
brainstorm the potential risks.

There are at least six kinds of risk that might be included in a risk checklist:
1. Technology risks: Risks that are derived from the software or hardware
technologies that will be used to develop the system.
2. People risk: Risks that are linked to the people in the development team.
3. Organizational risks: Risks that derive from the administrative environment
where third-party software is being developed.
4. Tools risks: Risks that are derived from the software tools and other support
software utilized to develop the system.
5. Requirements risks: Risks that stem from the changes to the customer
requirements and the whole process of managing the requirements
transformation.
6. Estimation risks: Risks that are derived from the administration estimates of
the resources needed to construct the system.

2. Risk Analysis
During the risk analysis process, you have to take into account each identified
risk and make a judgment about the probability and seriousness of that risk. It is
not possible to make precise, a number that represents the assessment of the
probability and significance of each risk.

Rather, you should assign the risk to one of several bands:

1. The probability of the risk might be assessed as very low (10%), low
(10–25%), moderate (25–50%), high (50–75%), or very high (> 75%).

2. The effects of the risk might be assessed as disastrous, serious (would cause
major delays), acceptable (delays are within allowed contingency), or
inconsequential.

3. Risk Planning
The risk planning process considers each of the key risks that have been
identified and has been developing strategies to manage such risks. For each of
the risks, you must think of actions that you might take to minimize the disruption
to the project if the problem found in the risk occurs there is no simple process
that can be followed for contingency planning.
It relies on the decision and experience of the project manager. possible risk
management policies which have been identified for the key risks shown in.
These policies are divided into three categories:
● Avoidance strategies Following these policies means that the probability
that the risk will emerge will be reduced. An example of a risk prevention
strategy is the strategy to deal with defective components.
● Minimization strategies Following these strategies means that the impact
of the risk will be reduced. An example of a risk minimization strategy is the
strategy for staff illness.
● Contingency plans Following these tactics means that you are ready for
the worst and have a strategy in place to deal with it. An example of a
contingency strategy is the strategy for organizational financial difficulties.

4.Risk Monitoring:
Risk monitoring is the whole process of checking that your beliefs about the
product, process, and business risks have not changed. You should periodically
assess each of the identified risks to decide whether that risk is becoming
probable. You should also think about whether the effects of the danger have
changed. To do this, you must look at other considerations, such as the number
of requirements to alter requests, which give you clues about the risk likelihood
and its effects.

CHAPTER 4
 Quality Management

Process and Product Quality

1. A fundamental assumption of quality management is that the quality

of the development process directly affects the quality of delivered
products.
2. This assumption comes from manufacturing systems where product
quality is intimately related to the production process.
3. In an automated manufacturing system, the process involves
configuring, setting up and operating the machines involved in
the process.
4. Once the machines are operating correctly, product quality naturally
follows. You measure the quality of the product and change the
process until you achieve the quality level that you need.
5. There is a clear link between process and product quality in
manufacturing because the process is relatively easy to standardize
and monitor.
6. Once manufacturing systems are calibrated, they can be run again
and again to produce high-quality products.
7. However, software is not manufactured but is designed.In software
development, therefore, the relationship between process quality and
product quality is more complex.
8. Software development is a creative rather than a mechanical
process, so the influence of Individual skills and experience is
significant/large/important.
9. External factors, such as the novelty of an application or commercial
pressure for an early product release, also affect product quality
irrespective of the process used.

Process quality management involves:

1) Defining process standards such as how and when reviews should be
conducted
2) Monitoring the development process to ensure that the standards are being
followed
3) Reporting the software process to project management and to the buyer of the
software

● One problem with process-based quality assurance is that the quality

assurance (QA) team may insist that standard processes should be used
irrespective of the type of software that is being developed.
● For example, process quality standards for critical systems may specify
that specification must be complete and approved before implementation
can begin.
● However, some critical systems may require prototyping where programs
are implemented without a complete specification.
● In some cases quality management team suggests that this prototyping
should not be carried out because the prototype quality cannot be
monitored.
● In such situations, senior management must intervene to ensure that the
quality process supports rather than hinders product development.

Quality Assurance and Software Standards

Quality assurance is a planned and systematic approach necessary to provide a

high degree of confidence in the quality of a product.
It provides quality assessment of the quality control activities and determines the
validity of the data for identifying the quality.
The main function of quality assurance is to define the standards as:
1. Product standards
2. Process standards
1. Product standards These apply to the software product being developed.
They include document standards, such as the structure of requirements
documents,
documentation standards, such as a standard comment header for an object
class definition, and coding standards, which define how a programming
language should be used.
2. Process standards These define the processes that should be followed
during software development.
They should encapsulate good development practice. Process standards may
include definitions of specification, design and validation processes, process
support tools, and a description of the documents that should be written during
these processes.
Quality Standards

● There are various international sets of standards set out by the International
Standards Organization that can be applied in the development of management
systems across all industries.
● These ISO standards are concerned with the quality process of design,
development and maintenance activities.
● One of such ISO standards is ISO 9126 that is specially aimed at software
development and sets out some key quality attributes to assure the quality of
the product being developed.

1. ISO 9000 Quality Standard

ISO 9000 is a set of quality management and QA standards that define a basic
set of good practices that will ensure in delivering a quality product to meet the
user's needs.
Benefits of ISO 9000
1. It focuses on the development process and not the product. It is
concerned about the way an organization goes about its work and
not the results of the work. And this is because having a quality
development process will ultimately help in achieving a quality
product.
2. It only illustrates the process requirements and not how they are
to be achieved.
For example, the ISO 9000 standards say that a software team
should plan and perform product design reviews but it doesn't say
how that requirement should be accomplished.
○ The sections of ISO 9000 that deal with software are ISO 9001 and
ISO 9000-3
○ The ISO 9001 is for business that designs, develops, installs, and
services the products.
○ The ISO 9000-3 is for business that develops, supplies, installs, and
maintains the computer software.
❖ ISO 9001
● It describes various aspects of the quality process and lays out the
organizational standards and procedures that the company should
define.
 ● These should be documented in an organizational quality manual
which should include the descriptions of the defined processes that
have been followed during product development.

Documentation standards in ISO 9001

● Documentation standards are imposed(ruled) on creating documents that
represent the software and the software process.
● There are three major types of documentation standards:
1. Document process standards: Defines the process to be followed for
document creation.
2. Document standards: Governs the structure and presentation of
documents.
3. Document Interchange standards: Ensures the compatibility of all the
softcopies of the documents.
● Fig. below depicts/shows the model of a documentation process
where drafting, checking, revising and redrafting are iterative
processes.
● It should continue until the document of acceptable quality is
produced.
● The acceptable quality level depends on the document type and the
potential readers of the document.
Quality Planning/ What does a quality plan include?

A quality plan is a document, or several documents, that together specify quality

standards, practices, resources, specifications, and the sequence of activities
relevant to a particular product, service, project, or contract.

❖ Quality control
Quality of the product needs to be controlled as it needs to be consistent
throughout the procedure. So, we need to implement a product or module by
following quality procedures and standards.
An out-line structure for a quality plan. This includes:
1. Product introduction: A description of the product, its intended market, and
the quality expectations for the product.
2. Product plans: the critical release dates and responsibilities for the product
along with plans for distribution and product servicing.
3. Process descriptions: the development and service processes and
standards that should be used for product development and management.
4. Quality goals: the quality goals and plans for the product, including an
identification and justification of critical product quality attributes.
5. Risks and risk management: the key risks that might affect product quality
and the actions to be taken to address these risks

Software measurement and metrics

Software Measurement:
A measurement is a manifestation of the size, quantity, amount, or dimension of a
particular attribute of a product or process.
Software measurement is a characteristic of a software product or the software process.
It is an authority within software engineering. The software measurement process is
defined and governed by ISO Standard.
Software Measurement Principles:

The software measurement process can be characterized by five activities-

1. Formulation: The derivation of software measures and metrics
appropriate for the representation of the software that is being
considered.
2. Collection: The mechanism used to accumulate/collect data required
to derive the formulated metrics.
3. Analysis: The computation of metrics and the application of
mathematical tools.
4. Interpretation: The evaluation of metrics resulting in insight into the
quality of the representation.
5. Feedback: Recommendation derived from the interpretation of product
metrics transmitted to the software team.
Need for Software Measurement:
Software is measured to:
● Create the quality of the current product or process.
● Anticipate/ Expect future qualities of the product or process.
● Enhance the quality of a product or process.
● Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement:

There are 2 types of software measurement:

1. Direct Measurement: In direct measurement, the product, process, or
thing is measured directly using a standard scale.
2. Indirect Measurement: In indirect measurement, the quantity or quality
to be measured is measured using related parameters i.e. by use of
reference.

Metrics:

A metric is a measurement of the level at which any impute /attribute belongs to

a system product or process.
Software metrics will be useful only if they are characterized effectively and
validated so that their worth is proven.
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, and the
method of computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the
development of the software.
4. Repeatable: The metric values should be the same when measured
repeatedly and consistent in nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any programming
language.

Classification of Software Metrics:

There are 3 types of software metrics:

1. Product Metrics: Product metrics are used to evaluate the state of the
product, tracing risks and undercover prospective problem areas. The
ability of the team to control quality is evaluated.
2. Process Metrics: Process metrics pay particular attention to enhancing
the long-term process of the team or organization.
3. Project Metrics: The project metric describes the project characteristic
and execution process.
○ Number of software developer
○ Staffing patterns over the life cycle of software
○ Cost and schedule
○ Productivity
Advantages of Software Metrics :
1. Reduction in cost or budget.
2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product.
6. It helps to determine the complexity of the code and to test the code
with resources.
7. It helps in providing effective planning, controlling and managing of the
entire product.

Disadvantages of Software Metrics :

1. It is expensive and difficult to implement the metrics in some cases.

2. Performance of the entire team or an individual from the team can’t be
determined. Only the performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measuring unwanted data which is a waste of time.
5. Measuring the incorrect data leads to wrong decision making.