lOMoARcPSD|43637711

Advanced Software Engg Notes Unit1-5

computer architecture (SRM Valliammai Engineering College)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Karthick M ([email protected])
 lOMoARcPSD|43637711

SE4151 ADVANCED SOFTWARE ENGINEERING LTPC3003

UNIT I SOFTWARE PROCESS & MODELING

Prescriptive Process Models

The following framework activities are carried out irrespective of the process
model chosen by the organization.

1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment

The name 'prescriptive' is given because the model prescribes a set of activities,
actions, tasks, quality assurance and change the mechanism for every project.

There are three types of prescriptive process models. They are:

1. The Waterfall Model

2. Incremental Process model
3. RAD model

1. The Waterfall Model

• The waterfall model is also called as 'Linear sequential

model' or 'Classic life cycle model'.
• In this model, each phase is fully completed before the beginning of the
next phase.
• This model is used for small projects.
• In this model, feedback is taken after each phase to ensure that the project
is on the right path.
• Testing part starts only after the development is complete.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

NOTE: The description of the phases of the waterfall model is same as that of
the process model.

An alternative design for 'linear sequential model' is as follows:

Advantages of waterfall model

• The waterfall model is simple and easy to understand, implement, and use.
• All the requirements are known at the beginning of the project; hence it is
easy to manage.
• It avoids overlapping of phases because each phase is completed at once.
• This model works for small projects because the requirements are
understood very well.
• This model is preferred for those projects where the quality is more
important as compared to the cost of the project.

Disadvantages of the waterfall model

• This model is not good for complex and object-oriented projects.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• It is a poor model for long projects.

• The problems with this model are uncovered, until the software testing.
• The amount of risk is high.

2. Incremental Process model

• The incremental model combines the elements of the waterfall model and
they are applied in an iterative fashion.
• The first increment in this model is generally a core product.
• Each increment builds the product and submits it to the customer for any
suggested modifications.
• The next increment implements the customer's suggestions and adds
additional requirements to the previous increment.
• This process is repeated until the product is finished.
For example, the word-processing software is developed using the
incremental model.

Advantages of incremental model

• This model is flexible because the cost of development is low and initial
product delivery is faster.
• It is easier to test and debug during the smaller iteration.
• The working software generates quickly and early during the software life
cycle.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• The customers can respond to its functionalities after every increment.

Disadvantages of the incremental model

• The cost of the final product may cross the cost estimated initially.
• This model requires a very clear and complete planning.
• The planning of design is required before the whole system is broken into
small increments.
• The demands of customer for the additional functionalities after every
increment causes problem during the system architecture.

3. RAD model

• RAD is a Rapid Application Development model.

• Using the RAD model, software product is developed in a short period of
time.
• The initial activity starts with the communication between customer and
developer.
• Planning depends upon the initial requirements and then the requirements
are divided into groups.
• Planning is more important to work together on different modules.

The RAD model consists of following phases:

1. Business Modeling
• Business modeling consist of the flow of information between various
functions in the project.
• For example, what type of information is produced by every function and
which are the functions to handle that information.
• A complete business analysis should be performed to get the essential
business information.
2. Data modeling
• The information in the business modeling phase is refined into the set of
objects and it is essential for the business.
• The attributes of each object are identified and define the relationship
between objects.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

3. Process modeling
• The data objects defined in the data modeling phase are changed to fulfil
the information flow to implement the business model.
• The process description is created for adding, modifying, deleting or
retrieving a data object.
4. Application generation
• In the application generation phase, the actual system is built.
• To construct the software the automated tools are used.
5. Testing and turnover
• The prototypes are independently tested after each iteration so that the
overall testing time is reduced.
• The data flow and the interfaces between all the components are fully
tested. Hence, most of the programming components are already tested.

Agility and Process

Agility in context of software engineering

• Agility means effective (rapid and adaptive) response to change, effective

communication among all stockholder.

• Drawing the customer onto team and organizing a team so that it is in

control of work performed. -The Agile process, light-weight methods are
People-based rather than plan-based methods.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• The agile process forces the development team to focus on software itself
rather than design and documentation.
• The agile process believes in iterative method.

• The aim of agile process is to deliver the working model of software quickly
to the customer for example: Extreme programming is the best known of
agile process.

Agile Principles

• The highest priority of this process is to satisfy the customer.

• Acceptance of changing requirement even late in development.
• Frequently deliver a working software in small time span.
• Throughout the project business people and developers work together on
daily basis.
• Projects are created around motivated people if they are given the proper
environment and support.
• Face to face interaction is the most efficient method of moving information
in the development team.
• Primary measure of progress is a working software.
• Agile process helps in sustainable development.
• Continuous attention to technical excellence and good design increases
agility.
• From self-organizing teams the best architecture, design and requirements
are emerged.
• Simplicity is necessary in development.
Advantages:
1. Flexible and adaptable to changing requirements.
2. Emphasizes rapid prototyping and continuous delivery, which can help to
identify and fix problems early on.
3. Encourages collaboration and communication between development teams
and stakeholders.
Disadvantages:
1. It may be difficult to plan and manage a project using Agile methodologies,
as requirements and deliverables are not always well-defined in advance.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

2. It can be difficult to estimate the overall time and cost of a project, as the
process is iterative and changes are made throughout the development.

Process in context of software engineering

The term software specifies to the set of computer programs, procedures and
associated documents (Flowcharts, manuals, etc.) that describe the program and
how they are to be used.
A software process is the set of activities and associated outcome that produce a
software product. Software engineers mostly carry out these activities. These are
four key process activities, which are common to all software processes. These
activities are:
1. Software specifications: The functionality of the software and
constraints on its operation must be defined.
2. Software development: The software to meet the requirement must be
produced.
3. Software validation: The software must be validated to ensure that it
does what the customer wants.
4. Software evolution: The software must evolve to meet changing client
needs.

Software processes in software engineering refer to the methods and

techniques used to develop and maintain software. Some examples of software
processes include:
• Waterfall: a linear, sequential approach to software development, with
distinct phases such as requirements gathering, design, implementation,
testing, and maintenance.
• Agile: a flexible, iterative approach to software development, with an
emphasis on rapid prototyping and continuous delivery.
• Scrum: a popular Agile methodology that emphasizes teamwork, iterative
development, and a flexible, adaptive approach to planning and
management.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• DevOps: a set of practices that aims to improve collaboration and

communication between development and operations teams, with an
emphasis on automating the software delivery process.
Each process has its own set of advantages and disadvantages, and the choice
of which one to use depends on the specific project and organization.

Scrum

One of the widely known and followed agile types, Scrum process usually is
followed in a small team. It majorly focuses on managing the process in a
development team. It uses a scrum board and divides the whole development
process into sprints. While the duration of the sprint may vary between 2 weeks
to 1 month, each of them is defined by analysis, development as well as user
acceptance.
Scrum also focuses on team interaction as well as effective client involvement.
There are different roles that people play in a scrum team, such as −
Scrum Master − The Scrum master’s responsibility is to set up the meeting,
team formation and overall managing of the whole sprint wise development. He/
she also takes care of any kind of hurdle faced during the development process.
Product owner − The product owner is responsible for creating and maintaining
the backlog, which is a repository or dashboard containing all the developmental
plans or requirement for the particular sprint. The product owner also assigns
and manages the requirements based on their priority order in each sprint.
Scrum team − The development team responsible for development or
completion of the tasks and successful execution of each of the sprints.
For each sprint, the product backlog is prepared by the product owner which
comprises of requirements or tasks and user stories for that particular sprint.
Once the tasks are selected for that sprint backlog, the development team works
on those tasks and executes them as a product sprint wise. The scrum master
manages the whole sprint process and takes care of the smooth execution of
plan.
Everyday there is a small meeting of around 15 mins, called the daily Scrum or
stand-up meeting, where the scrum master gets the status update regarding the
product backlog and tries to find out if there is any blockage for further action.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Some non-functional testing types include load testing, compatibility testing,

usability testing, scalability testing and so on.
Advantages:
1. Encourages teamwork and collaboration.
2. Provides a flexible and adaptive framework for planning and managing
software development projects.
3. Helps to identify and fix problems early on by using frequent testing and
inspection.
Disadvantages:
1. A lack of understanding of Scrum methodologies can lead to confusion and
inefficiency.
2. It can be difficult to estimate the overall time and cost of a project, as the
process is iterative and changes are made throughout the development.

XP

Extreme Programming or simply called as XP prioritizes customer satisfaction

over anything else. Developed by Kent Beck, XP requires higher level of
involvement from both Client as well as developers. Development cases where
there are frequent changes in customer requirement can opt for XP as it is flexible
regarding changes at any time of the production.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

It focuses on short deliveries with checkpoints all over the project in order to
analyze if there are any changes in requirement and act accordingly. The small
deliveries and iterative development cycles happen in a more confusing manner
without any clear picture. However, it makes sense once the whole development
is completed. XP is largely dependent on its developer team’s ability to
coordinate. There are 5 phases in Extreme programming, which are −
Planning −
The initial phase where clients and the developers meet and discuss about the
requirement and scope of the development. Based on the client input, developer
team prepare short iterative user stories or development cycles for the full
development as a whole. Based on the stories created, duration and cost of the
project is defined.
Designing −
Here all the user stories are broken down into smaller tasks and further analysis
is done regarding the execution. Even development standards such as class and
method names, architecture and formats etc. are planned during designing. Test

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

cases are concurrently prepared for those iterative tasks. For probable problems
even contingency plans as well as solutions are discussed.
Coding −
The most important phase where the development based on the planning takes
place which include coding based on requirement and simultaneous
documentation for updating customer regarding the present status. Coding
standards and architectures defined during designing are properly followed with
a strictly 40 hours work a week follow up.
Testing −
Once the coding is done, user acceptance testing is started. XP integrates testing
during the coding phase itself for testing and development to run simultaneously.
Based on the test results, bugs are eliminated and then the product goes through
customer acceptance testing which is based on the customer requirements. Once
the testing is passed, the product along with the test result is then delivered to
the customer.
Closure −
Here, once the product is delivered, the team waits for customer as well as
manager feedback. Based on the feedback, they again follow the same planning-
coding-testing iteration till customer acceptance test is passed. The team also
provide technical support during production in case of further issue arises.

Kanban

The Kanban methodology is somehow similar to Scrum. Developed by Taiichi

Ohno, it is derived from a Japanese word meaning an instruction card which gets
followed during the production cycle of a product. It is more of a visual
methodology which is quite dependent on its Kanban Board similar to a Scrum
board, which contains the complete workflow schedule of the development
process.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Unlike Scrum, where only the sprint tasks are added to the board, all the tasks
related to the production schedule are added into the Kanban board in form of
cards. Typically, the tasks are divided into 3 columns such as Completed tasks,
To-do tasks, ongoing tasks. Unlike Scrum, task completion based on priority is
optional in Kanban and it can contain all the tasks related to the whole
developmental cycle at one place.

DevOps

The DevOps is the combination of two words, one is Development and other
is Operations. It is a culture to promote the development and operation process
collectively.

What is DevOps?
The DevOps is a combination of two words, one is software Development, and
second is Operations. This allows a single team to handle the entire application
lifecycle, from development to testing, deployment, and operations. DevOps
helps you to reduce the disconnection between software developers, quality
assurance (QA) engineers, and system administrators.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Promotes collaboration between Development and Operations team to

deploy code to production faster in an automated & repeatable way.
• Helps to increase organization speed to deliver applications and services.
It also allows organizations to serve their customers better and compete
more strongly in the market.
• Defined as a sequence of development and IT operations with better
communication and collaboration.
• One of the most valuable business disciplines for enterprises or
organizations. With the help of DevOps, quality, and speed of the
application delivery has improved to a great extent.
• A practice or methodology of making "Developers" and "Operations"
folks work together. DevOps represents a change in the IT culture with a
complete focus on rapid IT service delivery through the adoption of agile
practices in the context of a system-oriented approach.
DevOps is all about the integration of the operations and development process.
Organizations that have adopted DevOps noticed a 22% improvement in software
quality and a 17% improvement in application deployment frequency and achieve
a 22% hike in customer satisfaction. 19% of revenue hikes as a result of the
successful DevOps implementation.

Why DevOps?
o The operation and development team worked in complete isolation.
o After the design-build, the testing and deployment are performed
respectively. That's why they consumed more time than actual build cycles.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

o Without the use of DevOps, the team members are spending a large
amount of time on designing, testing, and deploying instead of building the
project.
o Manual code deployment leads to human errors in production.
o Coding and operation teams have their separate timelines and are not in
synch, causing further delays.

DevOps Architecture Features

1) Automation
Automation can reduce time consumption, especially during the testing and
deployment phase. The productivity increases, and releases are made quicker by
automation. This will lead in catching bugs quickly so that it can be fixed easily.
For contiguous delivery, each code is defined through automated tests, cloud-
based services, and builds. This promotes production using automated deploys.
2) Collaboration
The Development and Operations team collaborates as a DevOps team, which
improves the cultural model as the teams become more productive with their
productivity, which strengthens accountability and ownership. The teams share
their responsibilities and work closely in sync, which in turn makes the
deployment to production faster.
3) Integration
Applications need to be integrated with other components in the environment.
The integration phase is where the existing code is combined with new
functionality and then tested. Continuous integration and testing enable
continuous development. The frequency in the releases and micro-services leads
to significant operational challenges. To overcome such problems, continuous
integration and delivery are implemented to deliver in a quicker, safer,
and reliable manner.
4) Configuration management
It ensures the application to interact with only those resources that are concerned
with the environment in which it runs. The configuration files are not created
where the external configuration to the application is separated from the source

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

code. The configuration file can be written during deployment, or they can be
loaded at the run time, depending on the environment in which it is running.
Advantages:
1. Improves collaboration and communication between development and
operations teams.
2. Automates software delivery process, making it faster and more efficient.
3. Enables faster recovery and response time in case of issues.
Disadvantages:
1. Requires a significant investment in tools and technologies.
2. Can be difficult to implement in organizations with existing silos and lack
of culture of collaboration.
3. Need to have a skilled workforce to effectively implement the DevOps
practices.
4. Ultimately, the choice of which methodology to use depends on the specific
project and organization, as well as the goals and requirements of the
project.

Prototype Construction

The Software Prototyping refers to building software application prototypes

which displays the functionality of the product under development, but may not
actually hold the exact logic of the original software.
Software prototyping is becoming very popular as a software development
model, as it enables to understand customer requirements at an early stage of
development. It helps get valuable feedback from the customer and helps
software designers and developers understand about what exactly is expected
from the product under development.

What is Software Prototyping?

Prototype is a working model of software with some limited functionality. The
prototype does not always hold the exact logic used in the actual software
application and is an extra effort to be considered under effort estimation.
Prototyping is used to allow the users evaluate developer proposals and try them
out before implementation. It also helps understand the requirements which are

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

user specific and may not have been considered by the developer during product
design.

Following is a stepwise approach explained to design a software prototype.

Basic Requirement Identification
This step involves understanding the very basics product requirements especially
in terms of user interface. The more intricate details of the internal design and
external aspects like performance and security can be ignored at this stage.

Developing the initial Prototype

The initial Prototype is developed in this stage, where the very basic requirements
are showcased and user interfaces are provided. These features may not exactly
work in the same manner internally in the actual software developed. While, the
workarounds are used to give the same look and feel to the customer in the
prototype developed.

Review of the Prototype

The prototype developed is then presented to the customer and the other
important stakeholders in the project. The feedback is collected in an organized
manner and used for further enhancements in the product under development.

Revise and Enhance the Prototype

The feedback and the review comments are discussed during this stage and some
negotiations happen with the customer based on factors like – time and budget
constraints and technical feasibility of the actual implementation. The changes
accepted are again incorporated in the new Prototype developed and the cycle
repeats until the customer expectations are met.

Prototypes can have horizontal or vertical dimensions. A Horizontal prototype

displays the user interface for the product and gives a broader view of the entire
system, without concentrating on internal functions. A Vertical prototype on the
other side is a detailed elaboration of a specific function or a sub system in the
product. The purpose of both horizontal and vertical prototype is different.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Horizontal prototypes are used to get more information on the user interface level
and the business requirements. It can even be presented in the sales demos to
get business in the market. Vertical prototypes are technical in nature and are
used to get details of the exact functioning of the sub systems. For example,
database requirements, interaction and data processing load in a given sub
system.

Types of Prototyping Models

Four types of Prototyping models are:
1. Rapid Throwaway prototypes
2. Evolutionary prototype
3. Incremental prototype
4. Extreme prototype
Rapid Throwaway Prototype
Rapid throwaway is based on the preliminary requirement. It is quickly developed
to show how the requirement will look visually. The customer’s feedback helps
drives changes to the requirement, and the prototype is again created until the
requirement is baselined.
In this method, a developed prototype will be discarded and will not be a part of
the ultimately accepted prototype. This technique is useful for exploring ideas
and getting instant feedback for customer requirements.
Evolutionary Prototyping
Here, the prototype developed is incrementally refined based on customer’s
feedback until it is finally accepted. It helps you to save time as well as effort.
That’s because developing a prototype from scratch for every interaction of the
process can sometimes be very frustrating.
This model is helpful for a project which uses a new technology that is not well
understood. It is also used for a complex project where every functionality must
be checked once. It is helpful when the requirement is not stable or not
understood clearly at the initial stage.
Incremental Prototyping
In incremental Prototyping, the final product is decimated into different small
prototypes and developed individually. Eventually, the different prototypes are

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

merged into a single product. This method is helpful to reduce the feedback time
between the user and the application development team.
Extreme Prototyping:
Extreme prototyping method is mostly used for web development. It is consists
of three sequential phases.
1. Basic prototype with all the existing page is present in the HTML format.
2. You can simulate data process using a prototype services layer.
3. The services are implemented and integrated into the final prototype.

The advantages of the Prototyping Model are as follows −

• Increased user involvement in the product even before its implementation.
• Since a working model of the system is displayed, the users get a better
understanding of the system being developed.
• Reduces time and cost as the defects can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily.
• Confusing or difficult functions can be identified.
The Disadvantages of the Prototyping Model are as follows −
• Risk of insufficient requirement analysis owing to too much dependency on
the prototype.
• Users may get confused in the prototypes and actual systems.
• Practically, this methodology may increase the complexity of the system
as scope of the system may expand beyond original plans.
• Developers may try to reuse the existing prototypes to build the actual
system, even when it is not technically feasible.
• The effort invested in building prototypes may be too much if it is not
monitored properly.

Prototype Evaluation

A prototype is the first step on your way to a successful digital product. You’ve
already spent a lot of time and money on your idea, so you shouldn’t risk
developing a product that doesn’t match your users’ needs or preferences, or

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

that your users won’t understand. That’s why you should invest in usability
testing and UX testing.
In a Prototype Evaluation, you get the chance to ask your target users for initial
feedback on design, usability, and user experience. In this phase, the prototype
is tested to see if it meets the requirements and specifications. This is done by
evaluating its functionality, performance, and reliability.
During the user testing process, the testers will check your prototype and make
sure you don’t work further on a product with usability problems or that’s not
suited to your users’ needs. Based on the feedback of your target users you can
then adapt your first draft and move on with development.
Advantages of Prototype Evaluation
• Make sure your future product is suited to your users’ needs and
expectations
• Prevent operational blindness by involving your target group in
development
• Get feedback on design, usability, and UX at an early stage
• Only invest time and money in features your users will use

Prototype Evolution

The prototype developed is then presented to the customer and the other
important stakeholders in the project. The feedback is collected in an organized
manner and used for further enhancements in the product under development.

The feedback and the review comments are discussed during this stage and some
negotiations happen with the customer based on factors like – time and budget

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

constraints and technical feasibility of the actual implementation. The changes

accepted are again incorporated in the new Prototype developed and the cycle
repeats until the customer expectations are met.

Based on the results of the testing and evaluation phase, the prototype is refined
and improvements are made. After the refinement phase, the final prototype is
created. This prototype is then tested and evaluated to ensure that it meets all
the requirements before it is mass-produced.

Evolutionary Prototype
In an evolutionary prototype, a system or product is built via several iterations,
with each iteration building on the one before it to enhance and improve the
design. The objective is to provide a final design that satisfies the expectations
and requirements of the intended audience.
This method can be used for a wide variety of projects in various industries, but
it is frequently utilized in software development and engineering.

Modeling

Modeling is a central part of all activities that lead up to the deployment of good
software. It is required to build quality software. Modeling is widely used in
science and engineering to provide abstractions of a system at some level of
precision and detail. The model is then analyzed in order to obtain a better
understanding of the system being developed. “Modeling” is the designing of
software applications before coding.”
In model-based software design and development, software modeling is used as
an essential part of the software development process. Models are built and
analyzed prior to the implementation of the system and are used to direct the
subsequent implementation.
A better understanding of a system can be obtained by considering it from
different perspectives, such as requirements models, static models, and dynamic
models of the software system. A graphical modeling language such as UML helps
in developing, understanding, and communicating the different views.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Importance of Modeling:
• Modeling gives a graphical representation of the system to be built.
• Modeling contributes to a successful software organization.
• Modeling is a proven and well-accepted engineering technique.
• Modeling is not just a part of the building industry. It would be
inconceivable to deploy a new aircraft or an automobile without first
building models-from computer models to physical wind tunnel models to
full scale prototypes.
• A model is a simplification of reality. A model provides the blueprint of a
system.
• A model may be structural, emphasizing the organization of the system,
or it may be behavioral, emphasizing the dynamics of the system.
• Models are built for a better understanding of the system that we are
developing:
a. Models help us to visualize a system as it is or as we want it to be.
b. Models permit us to specify the structure or behavior of a system.
c. Models give us a template that guides us in constructing a system.
d. Models support the decisions we have made.

The Software Development Life Cycle, or SDLC, is the process of planning,

designing, developing, testing, and deploying high-quality software at the lowest
cost possible, preferably in the shortest amount of time. To achieve this goal,
software engineering teams must choose the correct software development
model to fit their organization’s requirements, stakeholders’ expectations, and
the project. There are myriad software development models, each with distinct
advantages and disadvantages.
Details of the project, including timeframe and budget, should influence your
choice of model. The goal is to select a software development model that will
ensure project success. Selecting the incorrect model will result in drawn-out
timelines, exceeded budgets, low-quality outputs, and even project failure.

Principles

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

There are several basic principles of a good software engineering approach that
are commonly followed by software developers and engineers to produce high-
quality software. Some of these principles include:
1. Modularity: Breaking down the software into smaller, independent, and
reusable components or modules. This makes the software easier to
understand, test, and maintain.
2. Abstraction: Hiding the implementation details of a module or component
and exposing only the necessary information. This makes the software
more flexible and easier to change.
3. Encapsulation: Wrapping the data and functions of a module or
component into a single unit, and providing controlled access to that unit.
This helps to protect the data and functions from unauthorized access and
modification.
4. DRY principle (Don’t Repeat Yourself): Avoiding duplication of code
and data in the software. This makes the software more maintainable and
less error-prone.
5. KISS principle (Keep It Simple, Stupid): Keeping the software design
and implementation as simple as possible. This makes the software more
understandable, testable, and maintainable.
6. YAGNI (You Ain’t Gonna Need It): Avoiding adding unnecessary
features or functionality to the software. This helps to keep the software
focused on the essential requirements and makes it more maintainable.
7. SOLID principles: A set of principles that guide the design of software to
make it more maintainable, reusable, and extensible. This includes the
Single Responsibility Principle, Open/Closed Principle, Liskov Substitution
Principle, Interface Segregation Principle, and Dependency Inversion
Principle.
8. Test-driven development: Writing automated tests before writing the
code, and ensuring that the code passes all tests before it is considered
complete. This helps to ensure that the software meets the requirements
and specifications.
9. By following these principles, software engineers can develop software that
is more reliable, maintainable, and extensible.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

10. It’s also important to note that these principles are not mutually
exclusive, and often work together to improve the overall quality of the
software.

Requirement Engineering
Requirements engineering (RE) refers to the process of defining, documenting,
and maintaining requirements in the engineering design process. Requirement
engineering provides the appropriate mechanism to understand what the
customer desires, analyzing the need, and assessing feasibility, negotiating a
reasonable solution, specifying the solution clearly, validating the specifications
and managing the requirements as they are transformed into a working system.
Thus, requirement engineering is the disciplined application of proven principles,
methods, tools, and notation to describe a proposed system's intended behavior
and its associated constraints.

Tools involved in requirement engineering:

• observation report
• Questionnaire (survey, poll)
• Use cases
• User stories
• Requirement workshop
• Mind mapping
• Role playing
• Prototyping

Requirement Engineering Process

It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing
the software that is acceptable to users, flexible to change and conformable to
established standards.
Types of Feasibility:
1. Technical Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements
within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve business
problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the
necessary software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are
identified with the help of customers and existing systems processes, if available.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Analysis of requirements starts with requirement elicitation. The requirements

are analyzed to identify inconsistencies, defects, omission, etc. We describe
requirements in terms of relationships and also resolve conflicts if any.
Problems of Elicitation and Analysis
o Getting all, and only, the right people involved.
o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a
software analyst after the requirements collected from the various sources - the
requirement received by the customer written in ordinary language. It is the job

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

of the analyst to write the requirement in technical language so that they can be
understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs),
function decomposition diagrams (FDDs), data dictionaries, etc.
o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for
modeling the requirements. DFD shows the flow of data through a system.
The system may be a company, an organization, a set of procedures, a
computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements
stage, the data dictionary should at least define customer data items, to
ensure that the customer and developers use the same definition and
terminologies.
o Entity-Relationship Diagrams: Another tool for requirement
specification is the entity-relationship diagram, often called an "E-R
diagram." It is a detailed logical representation of the data for the
organization and uses three main constructs i.e., data entities,
relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this
document are validated. The user might demand illegal, impossible solution or
experts may misinterpret the needs. Requirements can be the check against the
following conditions -
o If they can practically implement
o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe
Requirements Validation Techniques
o Requirements reviews/inspections: systematic manual analysis of the
requirements.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

o Prototyping: Using an executable model of the system to check

requirements.
o Test-case generation: Developing tests for requirements to check
testability.
o Automated consistency analysis: checking for the consistency of
structured requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements
during the requirements engineering process and system development.
New requirements emerge during the process as business needs a change, and
a better understanding of the system is developed.
The priority of requirements from different viewpoints changes during
development process.
The business and technical environment of the system changes during the
development.

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software
development project. Hence, they should be clear, correct, and well-defined.
A complete Software Requirement Specifications should be:
o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Software Requirements: Largely software requirements must be categorized

into two categories:
1. Functional Requirements: Functional requirements define a function
that a system or system element must be qualified to perform and must
be documented in different forms. The functional requirements are
describing the behavior of the system as it correlates to the system's
functionality.
2. Non-functional Requirements: This can be the necessities that specify
the criteria that can be used to decide the operation instead of specific
behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are
observable at run time.
o Evolution qualities like testability, maintainability, extensibility,
and scalability that embodied in the static structure of the software
system.

Scenario-based Modelling
Requirements for a computer-based system can be seen in many different ways.
Some software people argue that it’s worth using a number of different modes of
representation while others believe that it’s best to select one mode of
representation. The specific elements of the requirements model are
dedicated to the analysis modeling method that is to be used.

Scenario-Based Elements
Using a scenario-based approach, system is described from user’s point of
view. For example, basic use cases and their corresponding use-case diagrams
evolve into more elaborate template-based use cases. Figure 1(a) depicts a UML
activity diagram for eliciting requirements and representing them using use
cases. There are three levels of elaboration.
Class-Based Elements
A collection of things that have similar attributes and common behaviors i.e.,
objects are categorized into classes. For example, a UML case diagram can be

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

used to depict a Sensor class for the SafeHome security function. Note that
diagram lists attributes of sensors and operations that can be applied to modify
these attributes. In addition to class diagrams, other analysis modeling elements
depict manner in which classes collaborate with one another and relationships
and interactions between classes.

Class-based Modelling
Class-based modeling identifies classes, attributes and relationships that the
system will use. In the airline application example, the traveler/user and the
boarding pass represent classes. The traveler's first and last name, and travel
document type represent attributes, characteristics that describe the traveler
class. The relationship between traveler and boarding pass classes is that the
traveler must enter these details into the application in order to get the boarding
pass, and that the boarding pass contains this information along with other
details like the flight departure gate, seat number etc.
Class based modeling represents the object. The system manipulates the
operations.
The elements of the class-based model consist of classes and object, attributes,
operations, class – responsibility - collaborator (CRS) models.
Classes
Classes are determined using underlining each noun or noun clause and enter it
into the simple table.
Classes are found in following forms:
External entities: The system, people or the device generates the information
that is used by the computer-based system.
Things: The reports, displays, letter, signal are the part of the information
domain or the problem.
Occurrences or events: A property transfer or the completion of a series or
robot movements occurs in the context of the system operation.
Roles: The people like manager, engineer, salesperson are interacting with the
system.
Organizational units: The division, group, team are suitable for an application.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Places: The manufacturing floor or loading dock from the context of the problem
and the overall function of the system.
Structures: The sensors, computers are defined a class of objects or related
classes of objects.
Attributes
Attributes are the set of data objects that are defining a complete class within
the context of the problem.
For example, 'employee' is a class and it consists of name, Id, department,
designation and salary of the employee are the attributes.
Operations
The operations define the behavior of an object.
The operations are characterized into following types:
• The operations manipulate the data like adding, modifying, deleting and
displaying etc.
• The operations perform a computation.
• The operation monitors the objects for the occurrence of controlling an
event
CRS Modeling
• The CRS stands for Class-Responsibility-Collaborator.
• It provides a simple method for identifying and organizing the classes that
are applicable to the system or product requirement.
• Class is an object-oriented class name. It consists of information about sub
classes and super class
• Responsibilities are the attributes and operations that are related to the
class.
• Collaborations are identified and determined when a class can achieve each
responsibility of it. If the class cannot identify itself, then it needs to
interact with another class.

Functional Modelling
Functional Modelling gives the process perspective of the object-oriented analysis
model and an overview of what the system is supposed to do. It defines the
function of the internal processes in the system with the aid of Data Flow

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Diagrams (DFDs). It depicts the functional derivation of the data values without
indicating how they are derived when they are computed, or why they need to
be computed.
Data Flow Diagrams
Functional Modelling is represented through a hierarchy of DFDs. The DFD is a
graphical representation of a system that shows the inputs to the system, the
processing upon the inputs, the outputs of the system as well as the internal data
stores. DFDs illustrate the series of transformations or computations performed
on the objects or the system, and the external controls and objects that affect
the transformation.
Rumbaugh et al. have defined DFD as, “A data flow diagram is a graph which
shows the flow of data values from their sources in objects through processes
that transform them to their destinations on other objects.”
The four main parts of a DFD are −
• Processes - Processes are the computational activities that transform data
values. A whole system can be visualized as a high-level process. A process
may be further divided into smaller components. The lowest-level process
may be a simple function.
• Data Flows - Data flow represents the flow of data between two processes.
It could be between an actor and a process, or between a data store and
a process. A data flow denotes the value of a data item at some point of
the computation. This value is not changed by the data flow.
• Actors - Actors are the active objects that interact with the system by either
producing data and inputting them to the system, or consuming data
produced by the system. In other words, actors serve as the sources and
the sinks of data.
• Data Stores - Data stores are the passive objects that act as a repository
of data. Unlike actors, they cannot perform any operations. They are used
to store data and retrieve the stored data. They represent a data structure,
a disk file, or a table in a database.
The other parts of a DFD are −

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Constraints - Constraints specify the conditions or restrictions that need to

be satisfied over time. They allow adding new rules or modifying existing
ones.
• Control Flows – A process may be associated with a certain Boolean value
and is evaluated only if the value is true, though it is not a direct input to
the process. These Boolean values are called the control flows.

Behavioural Modelling
Behavioural Modelling indicates how software will respond to external events or
stimuli. In behavioral model, the behavior of the system is represented as a
function of specific events and time.
To create behavioral model following things can be considered:
• Evaluation of all use-cases to fully understand the sequence of interaction
within the system.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Identification of events that drive the interaction sequence and understand

how these events relate to specific classes.
• Creating sequence for each use case.
• Building state diagram for the system.
• Reviewing the behavioral model to verify accuracy and consistency.
It describes interactions between objects. It shows how individual objects
collaborate to achieve the behavior of the system as a whole. In UML behavior of
a system is shown with the help of use case diagram, sequence diagram and
activity diagram
• A use case focuses on the functionality of a system i.e., what a system
does for users. It shows interaction between the system and outside
actors. Ex: Student, librarians are actors, issue book use case.
• A sequence diagram shows the objects that interact and the time sequence
of their interactions. Ex: Student, librarians are objects. Time sequence
enquires for book check availability –with respect time.
• An activity diagram specifies important processing steps. It shows
operations required for processing steps. It shows operations required for
processing. Ex issue book, check availability does not show objects

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

UNIT II SOFTWARE DESIGN

Design Concepts

What is Software Design?

Software design is a method that converts user requirements into a suitable form
for the programmer to employ in software coding and implementation. It is
concerned with converting the client's requirements as defined in the SRS
(Software Requirement Specification) document into a form that can be easily
implemented using a programming language. A good software designer needs to
have knowledge of what software engineering is.

The software design phase is the first step in the SDLC (Software Development
Life Cycle) that shifts the focus from the problem domain to the solution domain.
In software design, the system is viewed as a collection of components or
modules with clearly defined behaviors and bounds.

Objectives of Software Design

The following objectives describe what is software design in software
engineering.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Correctness: A good design should be correct, which means that it should

correctly implement all of the system's features.
• Efficiency: A good software design should consider resource, time, and
cost optimization parameters.
• Understandability: A good design should be easy to grasp, which is why
it should be modular, with all parts organized in layers.
• Completeness: The design should include all components, such as data
structures, modules, and external interfaces, among others.
• Maintainability: A good software design should be flexible when the client
issues a modification request.

Levels of Software Design

There are three levels of software design.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Architectural Design
A system's architecture can be defined as the system's overall structure and how
that structure offers conceptual integrity to the system. The architectural
design characterizes the software as a system with numerous interconnected
components. The designers acquire an overview of the proposed solution domain
at this level.
High-level Design
The high-level design deconstructs the architectural design's 'single entity-
multiple component' notion into a less abstract perspective of subsystems and
modules, depicting their interaction with one another. High-level design is
concerned with how the system and its components can be implemented as
modules. It recognizes the modular structure of each subsystem, as well as their
relationship and interaction with one another.
Detailed Design
After the high-level design is completed, the detailed design begins. Each module
is extensively investigated at this level of software design to establish the data
structures and algorithms to be used. Finally, a module specification
document is used to document the stage's outcome. It defines the logical
structure of each module as well as its interfaces with other modules.

Software Design Concepts

Let us look at some software design concepts that assist a software engineer in
creating the model of the system or software product to be developed or built.
The following ideas should be grasped before designing a software system.
Abstraction
One of the fundamental concepts of object-oriented programming
(OOP) languages is an abstraction. Its primary purpose is to deal with complexity
by concealing internal details from the user. This allows the user to build more
complicated logic on top of the offered abstraction without having to understand
or even consider all the hidden complexity.
Modularity
Modularity refers to breaking a system or project into smaller sections to lessen
the system's or project's complexity. Similarly, modularity in design refers to the

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

division of a system into smaller elements that can be built independently and
then used in multiple systems to execute different purposes. Sometimes to deal
with Monolithic software, which is difficult to grasp for software engineers, it is
required to partition the software into components known as modules. As a
result, modularity in design has become a trend that is also essential.
Architecture
A system's software architecture represents the design decisions linked to the
general structure and behavior of the system. Architecture assists stakeholders
in comprehending and analyzing how the system will attain critical characteristics
such as modifiability, availability, and security. It specifies how components
of a software system are constructed, as well as their relationships and
communication. It acts as a software application blueprint and a development
foundation for the developer team.
Refinement
Refinement means removing any impurities and improving the quality of
something. The software design refinement idea is a process of building or
presenting the software or system in a detailed manner, which implies
elaborating on a system or software. In addition, refinement is essential for
identifying and correcting any possible errors.
Design Patterns
A Software Design Pattern is a general, reusable solution to a commonly
occurring problem within a given context in software design. They are templates
to solve common software engineering problems, representing some of the finest
practices experienced object-oriented software engineers utilize. A design
pattern systematically describes and explains a general design that handles a
recurring design challenge in object-oriented systems. It discusses the problem,
the remedy, when to use it, and the repercussions. It also provides
implementation guidance and examples.
Information/Data Hiding

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Simply put, information hiding implies concealing information so that an

unauthorized entity cannot access it. In software design, information hiding is
accomplished by creating modules in such a way that information acquired or
contained in one module is concealed and cannot be accessible by other modules.
Refactoring
Refactoring is the process of reorganizing code without affecting its original
functionality. Refactoring aims to improve internal code by making modest
changes that do not affect the code's exterior behavior. Computer programmers
and software developers refactor code to improve the software's design,
structure, and implementation. As a result, Refactoring increases code readability
while decreasing complications. Refactoring can also assist software engineers in
locating faults or vulnerabilities in their code.

Design Model
A design model in software engineering is an object-based picture or pictures that
represent the use cases for a system. Or to put it another way, it's the means to
describe a system's implementation and source code in a diagrammatic
fashion. Software modeling should address the entire software design including
interfaces, interactions with other software, and all the software methods.
Software models are ways of expressing a software design. Usually, some sort of
abstract language or pictures are used to express the software design. For object-

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

oriented software, an object modeling language such as UML is used to develop

and express the software design. There are several tools that you can use to
develop your UML design.

In almost all cases a modeling language is used to develop the design not just to
capture the design after it is complete. This allows the designer to try different
designs and decide which will be best for the final solution. Think of designing
your software as you would a house. You start by drawing a rough sketch of the
floor plan and layout of the rooms and floors. The drawing is your modeling
language and the resulting blueprint will be a model of your final design. You will
continue to modify your drawings until you arrive at a design that meets all your
requirements. Only then should you start cutting boards or writing code.
Again, the benefit of designing your software using a modeling language is that
you discover problems early and fix them without refactoring your code.

The design model builds on the analysis model by describing, in greater detail,
the structure of the system and how the system will be implemented. Classes
that were identified in the analysis model are refined to include the
implementation constructs.

The design model is based on the analysis and architectural requirements of the
system. It represents the application components and determines their
appropriate placement and use within the overall architecture.

In the design model, packages contain the design elements of the system, such
as design classes, interfaces, and design subsystems, that evolve from the
analysis classes. Each package can contain any number of subpackages that
further partition the contained design elements. These architectural layers form
the basis for a second-level organization of the elements that describe the
specifications and implementation details of the system.

Within each package, sequence diagrams illustrate how the objects in the classes
interact, state machine diagrams to model the dynamic behavior in classes,
component diagrams to describe the software architecture of the system, and
deployment diagrams to describe the physical architecture of the system.

Software Architecture
Software Architecture defines fundamental organization of a system and more
simply defines a structured solution. It defines how components of a software
system are assembled, their relationship and communication between them. It
serves as a blueprint for software application and development basis for
developer team.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Software architecture defines a list of things which results in making many things
easier in the software development process.

• A software architecture defines structure of a system.

• A software architecture defines behavior of a system.

• A software architecture defines component relationship.

• A software architecture defines communication structure.

• A software architecture balances stakeholder’s needs.

• A software architecture influences team structure.

• A software architecture focuses on significant elements.

• A software architecture captures early design decisions.

Importance of Software Architecture:

Software architecture comes under design phase of software development life
cycle. It is one of initial step of whole software development process. Without
software architecture proceeding to software development is like building a house
without designing architecture of house.

So, software architecture is one of important part of software application

development. In technical and developmental aspects point of view below are
reasons software architecture are important.

• Selects quality attributes to be optimized for a system.

• Facilitates early prototyping.
• Allows to be built a system in component wise.

• Helps in managing the changes in System.

Besides all these software architectures is also important for many other factors
like quality of software, reliability of software, maintainability of software,
Supportability of software and performance of software and so on.

Advantages of Software Architecture:

• Provides a solid foundation for software project.

• Helps in providing increased performance.

• Reduces development cost.

Disadvantages of Software Architecture:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Sometimes getting good tools and standardization becomes a problem for

software architecture.

• Initial prediction of success of project based on architecture is not always

possible.

Architectural Styles
The software needs the architectural design to represent the design of the
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.

An architectural style is a set of principles. You can think of it as a coarse-grained

pattern that provides an abstract framework for a family of systems. An
architectural style improves partitioning and promotes design reuse by providing
solutions to frequently recurring problems.

• Named collection. An architectural style is a named collection of

architectural design decisions that are applicable in a given development
context, constrain architectural design decisions that are specific to a
particular system within that context, elicit beneficial qualities in each
resulting system.

• Recurring organizational patterns and idioms. Established, shared

understanding of common design forms. Mark of mature engineering field.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Abstraction. Abstraction of recurring composition and interaction

characteristics in a set of architectures.

Benefits of Architectural Styles in Software Engineering

Architectural styles provide several benefits. The most important of these benefits
is that they provide a common language.

Another benefit is that they provide a way to have a conversation that is

technology-agnostic.

This allows you to facilitate a higher level of conversation that is inclusive of

patterns and principles, without getting into the specifics. For example, by using
architecture styles, you can talk about client-server versus N-Tier.

• Design Reuse. Well-understood solutions applied to new problems.

• Code reuse. Shared implementations of invariant aspects of a style.
• Understandability of system organization. A phrase such as ‘client-
server” conveys a lot of information.
• Interoperability. Supported by style standardization.
• Style-specific analysis. Enabled by the constrained design space.
• Visualizations. Style-specific descriptions matching the engineer’s
mental models.

Architectural Design

The requirements of the software should be transformed into an architecture that

describes the software’s top-level structure and identifies its components. This is
accomplished through architectural design (also called system design), which
acts as a preliminary ‘blueprint’ from which software can be
developed. 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.’ This framework is
established by examining the software requirements document and designing a
model for providing implementation details. These details are used to specify the
components of the system along with their inputs, outputs, functions, and the
interaction between them. An architectural design performs the following
functions.

1. It defines an abstraction level at which the designers can specify the functional
and performance behavior of the system.

2. It acts as a guideline for enhancing the system (whenever required) by

describing those features of the system that can be modified easily without
affecting the system’s integrity.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

3. It evaluates all top-level designs.

4. It develops and documents top-level design for the external and internal
interfaces.

5. It develops preliminary versions of user documentation.

6. It defines and documents preliminary test requirements and the schedule for
software integration.

7. The sources of architectural design are listed below.

8. Information regarding the application domain for the software to be developed

9. Using data-flow diagrams

10. Availability of architectural patterns and architectural styles.

Architectural design is of crucial importance in software engineering during which

the essential requirements like reliability, cost, and performance are dealt with.
This task is cumbersome as the software engineering paradigm is shifting from
monolithic, stand-alone, built-from-scratch systems to componentized,
evolvable, standards-based, and product line-oriented systems. Also, a key
challenge for designers is to know precisely how to proceed from requirements to
architectural design. To avoid these problems, designers adopt strategies such as
reusability, componentization, platform-based, standards-based, and so on.

Though the architectural design is the responsibility of developers, some other

people like user representatives, systems engineers, hardware engineers, and
operations personnel are also involved. All these stakeholders must also be
consulted while reviewing the architectural design in order to minimize the risks
and errors.

Architectural Design Representation

Architectural design can be represented using the following models.

▪ Structural model: Illustrates architecture as an ordered collection of

program components
▪ Dynamic model: Specifies the behavioral aspect of the software
architecture and indicates how the structure or system configuration
changes as the function changes due to change in the external environment

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

▪ Process model: Focuses on the design of the business or technical

process, which must be implemented in the system
▪ Functional model: Represents the functional hierarchy of a system
▪ Framework model: Attempts to identify repeatable architectural design
patterns encountered in similar types of application. This leads to an
increase in the level of abstraction.

Architectural Design Output

The architectural design process results in an Architectural Design Document

(ADD). This document consists of a number of graphical representations that
comprises software models along with the associated descriptive text. The
software models include the static model, interface model, relationship model,
and dynamic process model. They show how the system is organized into a
process at run-time.

Architectural design document gives the developers a solution to the problem

stated in the Software Requirements Specification (SRS). Note that it considers
only those requirements in detail that affect the program structure. In addition,
to ADD, other outputs of the architectural design are listed below.

▪ Various reports including audit report, progress report, and configuration

status accounts report
▪ Various plans for detailed design phase, which include the following
▪ Software verification and validation plan
▪ Software configuration management plan
▪ Software quality assurance plan
▪ Software project management plan.

Component-Level Design

As soon as the first iteration of architectural design is complete, component-

level design takes place. The objective of this design is to transform the design
model into functional software. To achieve this objective, the component-level
design represents -the internal data structures and processing details of all the
software components (defined during architectural design) at an abstraction
level, closer to the actual code. In addition, it specifies an interface that may be
used to access the functionality of all the software components.

The component-level design can be represented by using different approaches.

One approach is to use a programming language while other is to use some
intermediate design notation such as graphical (DFD, flowchart, or structure
chart), tabular (decision table), or text-based (program design language)
whichever is easier to be translated into source code.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

The component-level design provides a way to determine whether the defined

algorithms, data structures, and interfaces will work properly. Note that a
component (also known as module) can be defined as a modular building block
for the software. However, the meaning of component differs according to how
software engineers use it. The modular design of the software should exhibit the
following sets of properties.

▪ Provide simple interface: Simple interfaces decrease the number of

interactions. Note that the number of interactions is taken into account
while determining whether the software performs the desired function.
Simple interfaces also provide support for reusability of components which
reduces the cost to a greater extent. It not only decreases the time involved
in design, coding, and testing but the overall software development cost is
also liquidated gradually with several projects. A number of studies so far
have proven that the reusability of software design is the most valuable
way of reducing the cost involved in software development.

▪ Ensure information hiding: The benefits of modularity cannot be

achieved merely by decomposing a program into several modules; rather
each module should be designed and developed in such a way that
the information hiding is ensured. It implies that the implementation
details of one module should not be visible to other modules of the
program. The concept of information hiding helps in reducing the cost of
subsequent design changes.

Modularity has become an accepted approach in every engineering discipline.

With the introduction of modular design, complexity of software design has
considerably reduced; change in the program is facilitated that has encouraged
parallel development of systems. To achieve effective modularity, design
concepts like functional independence are considered to be very important.

Functional Independence

Functional independence is the refined form of the design concepts of modularity,

abstraction, and information hiding. Functional independence is achieved by
developing a module in such a way that it uniquely performs given sets of function
without interacting with other parts of the system. The software that uses the
property of functional independence is easier to develop because its functions can
be categorized in a systematic manner. Moreover, independent modules require
less maintenance and testing activity, as secondary effects caused by design
modification are limited with less propagation of errors. In short, it can be said
that functional independence is the key to a good software design and a good
design results in high-quality software. There exist two qualitative criteria for
measuring functional independence, namely, coupling and cohesion.

Coupling

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Coupling measures the degree of interdependence among the modules. Several

factors like interface complexity, type of data that pass across the interface, type
of communication, number of interfaces per module, etc. influence the strength
of coupling between two modules. For better interface and well-structured
system, the modules should be loosely coupled in order to minimize the ‘ripple
effect’ in which modifications in one module results in errors in other modules.
Module coupling is categorized into the following types.

1. No direct coupling: Two modules are said to be ‘no direct coupled’ if they
are independent of each other.
2. Data coupling: Two modules are said to be ‘data coupled’ if they use
parameter list to pass data items for communication.
3. Stamp coupling: Two modules are said to be ‘stamp coupled’ if they
communicate by passing a data structure that stores additional information
than what is required to perform their functions.
4. Control coupling: Two modules are said to be ‘control coupled’ if they
communicate (pass a piece of information intended to control the internal
logic) using at least one ‘control flag’. The control flag is a variable whose
value is used by the dependent modules to make decisions.
5. Content coupling: Two modules are said to be ‘content coupled’ if one
module modifies data of some other module or one module is under the
control of another module or one module branches into the middle of
another module.
6. Common coupling: Two modules are said to be ‘common coupled’ if they
both reference a common data block.
Cohesion

Cohesion measures the relative functional strength of a module. It represents the

strength of bond between the internal elements of the modules. The tighter the
elements are bound to each other, the higher will be the cohesion of a module.
In practice, designers should avoid a low level of cohesion when designing a
module. Generally, low coupling results in high cohesion and vice versa.

Various types of cohesion are listed below.

1. Functional cohesion: In this, the elements within the modules are

concerned with the execution of a single function.
2. Sequential cohesion: In this, the elements within the modules are involved
in activities in such a way that the output from one activity becomes the
input for the next activity.
3. Communicational cohesion: In this, the elements within the modules
perform different functions, yet each function references the same input or
output information.
4. Procedural cohesion: In this, the elements within the modules are involved
in different and possibly unrelated activities.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

5. Temporal cohesion: In this, the elements within the modules contain

unrelated activities that can be carried out at the same time.
6. Logical cohesion: In this, the elements within the modules perform similar
activities, which are executed from outside the module.
7. Coincidental cohesion: In this, the elements within the modules perform
activities with no meaningful relationship to one another.

User Experience Design

“User Experience Design” is often used interchangeably with terms such as “User
Interface Design” and “Usability.” However, while usability and user interface (UI)
design are important aspects of UX design, they are subsets of it.

User interface is the front-end application view to which user interacts in order to
use the software. The software becomes more popular if its user interface is:

• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interface screens

There are two types of User Interface:

1. Command Line Interface: Command Line Interface provides a command

prompt, where the user types the command and feeds to the system. The
user needs to remember the syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides the simple
interactive interface to interact with the system. GUI can be a combination
of both hardware and software. Using GUI, user interprets the software.

User Interface Design Process:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

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.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

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.

Golden Rules:

The following are the golden rules stated by Theo Mandel that must be followed
during the design of the interface. Place the user in control:

• Define the interaction modes in such a way that does not force the user
into unnecessary or undesired actions: The user should be able to easily
enter and exit the mode with little or no effort.
• Provide for flexible interaction: Different people will use different
interaction mechanisms, some might use keyboard commands, some might
use mouse, some might use touch screen, etc, Hence all interaction
mechanisms should be provided.
• Allow user interaction to be interruptible and undoable: When a user is
doing a sequence of actions the user must be able to interrupt the sequence
to do some other work without losing the work that had been done. The
user should also be able to do undo operation.
• Streamline interaction as skill level advances and allow the interaction to
be customized: Advanced or highly skilled user should be provided a chance
to customize the interface as user wants which allows different interaction
mechanisms so that user doesn’t feel bored while using the same
interaction mechanism.
• Hide technical internals from casual users: The user should not be aware
of the internal technical details of the system. He should interact with the
interface just to do his work.
• Design for direct interaction with objects that appear on screen: The user
should be able to use the objects and manipulate the objects that are
present on the screen to perform a necessary task. By this, the user feels
easy to control over the screen.

Reduce the user’s memory load:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Reduce demand on short-term memory: When users are involved in some

complex tasks the demand on short-term memory is significant. So the
interface should be designed in such a way to reduce the remembering of
previously done actions, given inputs and results.
• Establish meaningful defaults: Always initial set of defaults should be
provided to the average user, if a user needs to add some new features
then he should be able to add the required features.
• Define shortcuts that are intuitive: Mnemonics should be used by the user.
Mnemonics means the keyboard shortcuts to do some action on the screen.
• The visual layout of the interface should be based on a real-world
metaphor: Anything you represent on a screen if it is a metaphor for real-
world entity then users would easily understand.
• Disclose information in a progressive fashion: The interface should be
organized hierarchically i.e. on the main screen the information about the
task, an object or some behavior should be presented first at a high level
of abstraction. More detail should be presented after the user indicates
interest with a mouse pick.

Make the interface consistent:

• Allow the user to put the current task into a meaningful context: Many
interfaces have dozens of screens. So it is important to provide indicators
consistently so that the user know about the doing work. The user should
also know from which page has navigated to the current page and from the
current page where can navigate.
• Maintain consistency across a family of applications: The development of
some set of applications all should follow and implement the same design,
rules so that consistency is maintained among applications.
• If past interactive models have created user expectations do not make
changes unless there is a compelling reason.

User interface design is a crucial aspect of software engineering, as it is the means

by which users interact with software applications. A well-designed user interface
can improve the usability and user experience of an application, making it easier
to use and more effective.

There are several key principles that software engineers should follow
when designing user interfaces:

1. User-centered design: User interface design should be focused on the

needs and preferences of the user. This involves understanding the user’s
goals, tasks, and context of use, and designing interfaces that meet their
needs and expectations.
2. Consistency: Consistency is important in user interface design, as it helps
users to understand and learn how to use an application. Consistent design

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

elements such as icons, color schemes, and navigation menus should be

used throughout the application.
3. Simplicity: User interfaces should be designed to be simple and easy to
use, with clear and concise language and intuitive navigation. Users should
be able to accomplish their tasks without being overwhelmed by
unnecessary complexity.
4. Feedback: Feedback is important in user interface design, as it helps users
to understand the results of their actions and confirms that they are making
progress towards their goals. Feedback can take the form of visual cues,
messages, or sounds.
5. Accessibility: User interfaces should be designed to be accessible to all
users, regardless of their abilities. This involves considering factors such as
color contrast, font size, and assistive technologies such as screen readers.
6. Flexibility: User interfaces should be designed to be flexible and
customizable, allowing users to tailor the interface to their own preferences
and needs.

Overall, user interface design is a key component of software engineering, as it

can have a significant impact on the usability, effectiveness, and user experience
of an application. Software engineers should follow best practices and design
principles to create interfaces that are user-centered, consistent, simple, and
accessible.

Design for Mobility

Once a software system is in operation, parts of it may need to be redeployed, or

migrated in response to changes in the run time environment. The redeployment
of a software system’s components is a type of software system mobility. Mobile
computing involves the movement of human users together with their hosts
across different physical locations, while still being able to access an information
system. This is also referred to as physical mobility. If a piece of software moves
across hardware hosts during the systems execution, that action is referred to as
code mobility or logical mobility. If a software module that needs to be migrated
contains run time state, it is known as stateful mobility. If only the code needs to
be migrated, it is known as stateless mobility. Supporting stateful mobility is more
challenging since the mobile component’s state on the source host needs to be
captured, migrated and reconstituted on the destination host. The effect of the
component’s migration and its temporary downtime on the rest of the system and
its dependence on the components internal state must be considered.

There are three general classes of mobile code systems: remote evaluation, code-
on-demand and mobile agent.

1. Remote evaluation: A component on the source host has the know-how but
not the resources needed for performing a service. The component is transferred

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

to the destination host, where it is executed using the available resource. The
result is returned to the source host.

In remote evaluation a software component is:

• Redeployed at run-time from a source host to destination host

• Installed on destination host, ensuring that the software system’s
architectural configuration and any architectural constraints are preserved.
• Activated
• Executed to provide the desired service.
• Possibly de-activated and de-installed.

2. Code-on-Demand:

Here the needed resources are available locally, but the know-how is not known.
The local sub-system thus requests the component providing the know-how from
the appropriate remote host. The code-on-demand requires the same steps as
remote-evaluation, the only difference is that roles of target and destination hosts
are reserved.

3. Mobile agent:

If a component on a given host has the know-how for providing some service,
has some execution state and has access to some of the resources needed to
provide that service along with its state and local resources, may migrate to the
destination host, which may have remaining resources need for providing the
service. From a software architectural perspective, mobile agents are stateful
software components.

There are some factors which has to be taken care of while migrating the code,
some architectural concerns of which engineers must be aware are:

Quiescence: It may be unsafe to attempt to migrate a software component in

the middle of processing, while it is waiting for a result from another component,
or while other components are requesting its services. Therefore, the system
must provide facilities that allow temporary suspension of all interactions
originating from or targeted at the component, until the component is relocated
to a new host. Quiescence requires at least two capabilities. The first one must
be embodied in the component itself, allowing the system to instruct the
component to cease any autonomous processing. The second capability may
require that special-purpose elements be inserted into the system temporarily, to
insulate the component from outside request and route them for processing after
the component has been migrated.

Quality of Service: Migrating the components may result in degradation of

availability of the service if some changes occur in the system. Consider a system

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

which provides a given level of availability. If the stakeholders want to improve

the availability to a higher level by migrating some components to a different
host, it should be evaluated where the component should reside. Once the target
host is determined, quiescence is rendered to the mobile components which are
packaged for redeployment and migrated to target host. They are installed and
activated on target hosts, after which the system operates at higher availability
level until there occurs some changes in the system.

Pattern-Based Design

In software engineering, a software design pattern is a general, reusable solution

of how to solve a common problem when designing an application or system.
Unlike a library or framework, which can be inserted and used right away, a
design pattern is more of a template to approach the problem at hand.

Design patterns are used to support object-oriented programming (OOP), a

paradigm that is based on the concepts of both objects (instances of a class; data
with unique attributes) and classes (user-defined types of data).

Design patterns can be broken down into three types, organized by their intent
into creational design patterns, structural design patterns, and behavioral design
patterns.

1. Creational Design Patterns

A creational design pattern deals with object creation and initialization, providing
guidance about which objects are created for a given situation. These design
patterns are used to increase flexibility and to reuse existing code.

• Factory Method: Creates objects with a common interface and lets a class
defer instantiation to subclasses.
• Abstract Factory: Creates a family of related objects.
• Builder: A step-by-step pattern for creating complex objects, separating
construction and representation.
• Prototype: Supports the copying of existing objects without code
becoming dependent on classes.
• Singleton: Restricts object creation for a class to only one instance.

2. Structural Design Patterns

A structural design pattern deals with class and object composition, or how to
assemble objects and classes into larger structures.

• Adapter: How to change or adapt an interface to that of another existing

class to allow incompatible interfaces to work together.
• Bridge: A method to decouple an interface from its implementation.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Composite: Leverages a tree structure to support manipulation as one

object.
• Decorator: Dynamically extends (adds or overrides) functionality.
• Façade: Defines a high-level interface to simplify the use of a large body
of code.
• Flyweight: Minimize memory use by sharing data with similar objects.
• Proxy: How to represent an object with another object to enable access
control, reduce cost and reduce complexity.

3. Behavioral Design Patterns

A behavioral design pattern is concerned with communication between objects

and how responsibilities are assigned between objects.

• Chain of Responsibility: A method for commands to be delegated to a

chain of processing objects.
• Command: Encapsulates a command request in an object.
• Interpreter: Supports the use of language elements within an application.
• Iterator: Supports iterative (sequential) access to collection elements.
• Mediator: Articulates simple communication between classes.
• Memento: A process to save and restore the internal/original state of an
object.
• Observer: Defines how to notify objects of changes to other object(s).
• State: How to alter the behavior of an object when its stage changes.
• Strategy: Encapsulates an algorithm inside a class.
• Visitor: Defines a new operation on a class without making changes to the
class.
• Template Method: Defines the skeleton of an operation while allowing
subclasses to refine certain steps.

Need for Design Patterns

Design patterns offer a best practice approach to support object-oriented

software design, which is easier to design, implement, change, test and reuse.
These design patterns provide best practices and structures.

1. Proven Solution - Design patterns provide a proven, reliable solution to a

common problem, meaning the software developer does not have to “reinvent
the wheel” when that problem occurs.

2. Reusable - Design patterns can be modified to solve many kinds of problems

– they are not just tied to a single problem.

3. Expressive - Design patterns are an elegant solution.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

4. Prevent the Need for Refactoring Code - Since the design pattern is already
the optimal solution for the problem, this can avoid refactoring.

5. Lower the Size of the Codebase - Each pattern helps software developers
change how the system works without a full redesign. Further, as the “optimal”
solution, the design pattern often requires less code.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

UNIT III SYSTEM DEPENDABILITY AND SECURITY

Dependable Systems

Dependable systems are desirable since they are “trustworthy,” as discussed in

the security communities and reliable engineering communities. Dependable
systems are typically characterized by the following attributes:

•Reliability: the system behaves as expected, with very few errors.

•Availability: the system and services are mostly available, with very little or
no down time.

•Safety: the systems do not pose unacceptable risks to the environment or the
health of users.

•Confidentiality: data and other information should not be divulged without intent
and authorization.

•Survivability: The system services should be robust enough to withstand

accidents and attacks.

•Integrity: System data should not be modified without intent and authorization.

•Maintainability: Maintenance of system hardware and services should not be

difficult or excessively expensive.

These attributes have some overlap among themselves. For example, just like
security, it is a weakest link phenomenon, in that the strength of the whole is
determined by the weakest link in the chain. Thus, for a product or system to be
considered dependable, it should possess all the aforementioned attributes.
Conversely, a system is not dependable in proportion to the degree of lack of
these dependability attributes. In most cases, dependability is also not a binary
phenomenon (present or absent) but based on gradations and acceptable
thresholds. These thresholds are specific to infrastructures such as electronic,
electromechanical, and quantum, as well as applications, such as
communications, process control, and data processing.

Among the dependability attributes, some need to be emphasized over others in

specific system applications. For example, in banking transactions, accuracy is
crucial, and if accuracy cannot be guaranteed, the transaction must be aborted
and rolled back. In contrast, sensors controlling a deep-sea oil rig may be large
in number, and the base station utilizes all the signals, including signals from
malfunctioning sensors and a composite picture is constructed from all available
data. Hundred percent accuracy can be sacrificed if sufficient degrees of

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

availability, survivability, and maintainability are achieved within a budget

threshold. Similarly, intelligence communications demand security and privacy
but might not be that concerned with delays of the order of seconds or minutes.

One of the keys for dependable systems is that they should be empirically
verifiable in terms of their dependability. That means that fashionable or trendy
methodologies that may be very popular need to be objectively assessed on the
basis of their true effectiveness. One of the measures for dependability is the
number of faults. Faults are errors in design or implementation that
cause failures. A failure is deemed to have occurred if any of the functional
specifications of the system are not met. Failures can range from minor to
catastrophic, depending upon the impact of failure on the system and the
immediate environment. Minor failures are referred to as errors. The underlying
faults may thus be prioritized, based on their potential impact. Lack of
dependability means that the system is undependable due to shortcoming in one
or more of the dependability attributes, caused by faults in the system and
potential cause of system failure.

Faults can manifest themselves during the operation of a system. Such faults are
known as active. Otherwise, the faults may be present and possibly manifest
themselves in the future. Such faults are referred to as dormant, and the purpose
of the testing phase in systems engineering is to discover as many dormant and
active faults as possible before deployment and general use of the tested system.

Dependability Properties

Principal properties:

• Availability: The probability that the system will be up and running and
able to deliver useful services to users.
• Reliability: The probability that the system will correctly deliver services
as expected by users.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Safety: A judgment of how likely it is that the system will cause damage
to people or its environment.
• Security: A judgment of how likely it is that the system can resist
accidental or deliberate intrusions.
• Resilience: A judgment of how well a system can maintain the continuity
of its critical services in the presence of disruptive events such as
equipment failure and cyberattacks.

Other properties of software dependability:

• Repairability reflects the extent to which the system can be repaired in

the event of a failure;
• Maintainability reflects the extent to which the system can be adapted to
new requirements;
• Survivability reflects the extent to which the system can deliver services
whilst under hostile attack;
• Error tolerance reflects the extent to which user input errors can be
avoided and tolerated.

Many dependability attributes depend on one another. Safe system operation

depends on the system being available and operating reliably. A system may be
unreliable because its data has been corrupted by an external attack. Denial of
service attacks on a system are intended to make it unavailable. If a system is
infected with a virus, you cannot be confident in its reliability or safety.

How to achieve dependability?

• Avoid the introduction of accidental errors when developing the system.

• Design V & V processes that are effective in discovering residual errors in
the system.
• Design systems to be fault tolerant so that they can continue in operation
when faults occur.
• Design protection mechanisms that guard against external attacks.
• Configure the system correctly for its operating environment.
• Include system capabilities to recognize and resist cyberattacks.
• Include recovery mechanisms to help restore normal system service after
a failure.

Dependability costs tend to increase exponentially as increasing levels of

dependability are required because of two reasons. The use of more expensive
development techniques and hardware that are required to achieve the higher
levels of dependability. The increased testing and system validation that is
required to convince the system client and regulators that the required levels of
dependability have been achieved.

Socio-technical systems

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Software engineering is not an isolated activity but is part of a broader systems

engineering process. Software systems are therefore not isolated systems but
are essential components of broader systems that have a human, social or
organizational purpose.

• Equipment: hardware devices, some of which may be computers; most

devices will include an embedded system of some kind.
• Operating system: provides a set of common facilities for higher levels in
the system.
• Communications and data management: middleware that provides
access to remote systems and databases.
• Application systems: specific functionality to meet some organization
requirements.
• Business processes: a set of processes involving people and computer
systems that support the activities of the business.
• Organizations: higher level strategic business activities that affect the
operation of the system.
• Society: laws, regulation and culture that affect the operation of the
system.

There are interactions and dependencies between the layers in a system and
changes at one level ripple through the other levels. For dependability, a
systems perspective is essential.

Redundancy and Diversity

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Redundancy: Keep more than a single version of critical components so that if

one fails then a backup is available.
Diversity: Provide the same functionality in different ways in different
components so that they will not fail in the same way.
Redundant and diverse components should be independent so that they will not
suffer from 'common-mode' failures.

Process activities, such as validation, should not depend on a single approach,

such as testing, to validate the system. Redundant and diverse process activities
are important especially for verification and validation. Multiple, different process
activities the complement each other and allow for cross-checking help to avoid
process errors, which may lead to errors in the software.

Dependable processes

To ensure a minimal number of software faults, it is important to have a well-

defined, repeatable software process. A well-defined repeatable process is
one that does not depend entirely on individual skills; rather can be enacted by
different people. Regulators use information about the process to check if good
software engineering practice has been used. For fault detection, it is clear that
the process activities should include significant effort devoted to verification and
validation.

Dependable process characteristics:

Explicitly defined

A process that has a defined process model that is used to drive the software
production process. Data must be collected during the process that proves that
the development team has followed the process as defined in the process model.

Repeatable

A process that does not rely on individual interpretation and judgment. The
process can be repeated across projects and with different team members,
irrespective of who is involved in the development.

Dependable process activities

• Requirements reviews to check that the requirements are, as far as

possible, complete and consistent.
• Requirements management to ensure that changes to the requirements
are controlled and that the impact of proposed requirements changes is
understood.
• Formal specification, where a mathematical model of the software is
created and analyzed.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• System modeling, where the software design is explicitly documented as

a set of graphical models, and the links between the requirements and
these models are documented.
• Design and program inspections, where the different descriptions of the
system are inspected and checked by different people.
• Static analysis, where automated checks are carried out on the source
code of the program.
• Test planning and management, where a comprehensive set of system
tests is designed.

Formal Methods

Formal methods are techniques used by software engineers to design safety-

critical systems and their components. In software engineering, they are
techniques that involve mathematical expressions to model “abstract
representation” of the system.

Long story short – it uses mathematical rigour to describe/specify systems before

they get implemented.

Such models are subject to proof-check (Formal Specification) with regards to

stability, cohesion and reliability. Proving validation is a core process for
evaluating models using automatic theorem proofs. This is based on a set of
mathematical formulas to be proven called proof obligations (Formal Verification).
This allows identification of potential flaws earlier in the design stage, to prevent
from “bricking” expensive systems later when placed into exploitation. Standard
development techniques revolve around the following phases:

1. Requirements engineering
2. Architecture design
3. Implementation
4. Testing
5. Maintenance
6. Evolution

Some may argue that all these steps usually take place, but they must, to some
extent for at least usable software with longer perspectives for exploitation. Some
of the earlier steps – particularly design stages – may bring a sense of uncertainty
in terms of unforeseen problems later in the process. The reasons could be:

1. Lack of grasp of the problem as a whole

2. Dispersed engineering teams have different perceptions of the end-product
3. Lack of domain knowledge
4. Inconsistent requirements
5. Yet-to-be discovered areas of expertise

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

These are just some avoidable factors in the completion of complex projects.
Safety-critical systems, in particular, have a significant need for earlier fault
detection. It is crucial to validate software faultlessness where agile incremental
analysis and development bring about quality assurance concerns. Thus, that is
where the implementation of such techniques finds its highest demand.

There are notable differences between standard and formal software

development methods. Formal methods are somewhat supporting tools. Here,
the reliability of mathematics improves software production quality at any stage.
They are not necessarily there to implement data processing. Choice of
programming language is irrelevant. Instead, it creates a ‘bridge’ between
modelled concepts and the environment towards final software implementation:
“What shall we do?” over “How shall we do this?”.

Examples of Formal Method Techniques

B METHOD

B is an example of formal method techniques that covers the whole development

life-cycle. It divides software onto separated components that further represent
as Abstract Machines.

B methods represent system models in the form of mathematical expressions as

an Abstract Notation Machine (AMN). These are further subject to stepwise
refinement and proof obligation evaluation. This consists of verification of
invariant preservation and refinement correctness.

The B method is a widely-cited technique in scientific publications concerning

formal method implementation. Notably, it is used in the specification for
transport automation systems in Paris and Sao Paulo, by Siemens Transportation
Systems.

Z NOTATION

Z notation is a model-based, abstract formal specification technique most

compatible with object-oriented programming. Z defines system models in the
form of states where each state consists of variables, values and operations that
change from one state to another.

As opposed to the usability of B, which is involved in full development life-cycle,

Z formalizes a specification of the system at the design level.

EVENT-B

Event-B is an advanced implementation of the B method. Using this approach,

formal software specification is the process of creating a discrete model that

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

represents a specific state of the system. The state is an abstract representation

of constants, variables and transitions (events). Part of an event is the guard that
determines the condition for the transition to another other state to take place.
Constructed models (blueprints) are a further subject of refinement, proof
obligation and decomposition for the correctness of verification.

Evaluation

Before deciding on the use of formal methods, each architect must list the pros
and cons against resources available, as well as the system’s needs.

BENEFITS

1. Significantly improves reliability at the design level decreasing the cost of

testing
2. Improves system cohesion, reliability, and safety-critical components by
fault detection on early phases in the development cycle
3. Validated models present deterministic system behavior

Reliability Engineering

Reliability engineering is a sub-discipline of systems engineering that emphasizes

the ability of equipment to function without failure. Reliability describes the ability
of a system or component to function under stated conditions for a specified
period of time. Reliability is closely related to availability, which is typically
described as the ability of a component or system to function at a specified
moment or interval of time.

The reliability function is theoretically defined as the probability of success at time

t, which is denoted R(t). In practice, it is calculated using different techniques
and its value ranges between 0 and 1, where 0 indicates no probability of success
while 1 indicates definite success. This probability is estimated from detailed
(physics of failure) analysis, previous data sets or through reliability testing and
reliability modeling. Availability, testability, maintainability and maintenance are
often defined as a part of "reliability engineering" in reliability programs.
Reliability often plays the key role in the cost-effectiveness of systems.

Reliability engineering deals with the prediction, prevention and management of

high levels of "lifetime" engineering uncertainty and risks of failure. Although
stochastic parameters define and affect reliability, reliability is not only achieved
by mathematics and statistics. "Nearly all teaching and literature on the subject
emphasize these aspects, and ignore the reality that the ranges of uncertainty
involved largely invalidate quantitative methods for prediction and
measurement." For example, it is easy to represent "probability of failure" as a
symbol or value in an equation, but it is almost impossible to predict its true
magnitude in practice, which is massively multivariate, so having the equation for

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

reliability does not begin to equal having an accurate predictive measurement of

reliability.

Reliability engineering relates closely to Quality Engineering, safety engineering

and system safety, in that they use common methods for their analysis and may
require input from each other. It can be said that a system must be reliably safe.
Reliability engineering focuses on costs of failure caused by system downtime,
cost of spares, repair equipment, personnel, and cost of warranty claims.

Objectives

The objectives of reliability engineering, in decreasing order of priority, are:

1. To apply engineering knowledge and specialist techniques to prevent or to

reduce the likelihood or frequency of failures.
2. To identify and correct the causes of failures that do occur despite the
efforts to prevent them.
3. To determine ways of coping with failures that do occur, if their causes
have not been corrected.
4. To apply methods for estimating the likely reliability of new designs, and
for analyzing reliability data.

The reason for the priority emphasis is that it is by far the most effective way of
working, in terms of minimizing costs and generating reliable products. The
primary skills that are required, therefore, are the ability to understand and
anticipate the possible causes of failures, and knowledge of how to prevent them.
It is also necessary to have knowledge of the methods that can be used for
analyzing designs and data.

Availability and Reliability

Availability refers to the percentage of time a system is available to users.

Reliability refers to the likelihood that the system will meet a certain level of
performance based on user needs within a certain time frame.

What is Availability?

Availability, also known as operational availability, is the ability of a system to

deliver required services that are requested to do so. Availability ensures that an
application or service is continuously available to its users. The formal definition
would be – availability is the probability that a system, at a point in time, would
remain operational under normal circumstances in order to serve its intended
purpose. Simply put, it ensures that a system is able to perform required function
under given conditions at a given point of time. Service availability can be
quantified via a simple equation as service uptime divided by the sum of service
uptime and service downtime.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Availability = Uptime/ Uptime + Downtime

What is Reliability?

Reliability is the ability of a system to deliver services correctly under given

conditions for a given time period. Failures are inevitable in complex system; in
fact, both native and virtualized systems are subject to the same fundamental
error and failure scenarios. This takes into account the fact that if you’re using
the system for something it’s not designed to do, you don’t get the same level of
reliability. It is the degree of consistency of a measure. A system is said to be
reliable when it delivers the same repeated results under the same conditions at
any point of time, without failures. Reliability can be measured using a metric
called mean time between failures (MTBF). It’s a measure of how reliable a
product or system is.

MTBF = Operating Time (hours)/ Number of Failures

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Reliability is the probability of failure-free system operation over a specified time

in a given environment for a given purpose. Availability is the probability that a
system, at a point in time, will be operational and able to deliver the requested
services. Both of these attributes can be expressed quantitatively e.g.
availability of 0.999 means that the system is up and running for 99.9% of the
time.

The formal definition of reliability does not always reflect the user's
perception of a system's reliability. Reliability can only be defined formally with
respect to a system specification i.e. a failure is a deviation from a
specification. Users don't read specifications and don't know how the system is
supposed to behave; therefore, perceived reliability is more important in practice.

Availability is usually expressed as a percentage of the time that the system

is available to deliver services e.g. 99.95%. However, this does not take into
account two factors:

• The number of users affected by the service outage. Loss of service in

the middle of the night is less important for many systems than loss of
service during peak usage periods.
• The length of the outage. The longer the outage, the more the disruption.
Several short outages are less likely to be disruptive than 1 long outage.
Long repair times are a particular problem.

Removing X% of the faults in a system will not necessarily improve the reliability
by X%. Program defects may be in rarely executed sections of the code so may
never be encountered by users. Removing these does not affect the perceived
reliability. Users adapt their behavior to avoid system features that may fail for
them. A program with known faults may therefore still be perceived as reliable
by its users.

Reliability Requirements

Functional reliability requirements define system and software functions that

avoid, detect or tolerate faults in the software and so ensure that these faults do
not lead to system failure.

Reliability is a measurable system attribute so non-functional reliability

requirements may be specified quantitatively. These define the number of
failures that are acceptable during normal use of the system or the time in
which the system must be available. Functional reliability requirements define
system and software functions that avoid, detect or tolerate faults in the software
and so ensure that these faults do not lead to system failure. Software reliability
requirements may also be included to cope with hardware failure or operator
error.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Reliability metrics are units of measurement of system reliability. System

reliability is measured by counting the number of operational failures and, where
appropriate, relating these to the demands made on the system and the time that
the system has been operational. Metrics include:

• Probability of failure on demand (POFOD). The probability that the

system will fail when a service request is made. Useful when demands for
service are intermittent and relatively infrequent.
• Rate of occurrence of failures (ROCOF). Reflects the rate of occurrence
of failure in the system. Relevant for systems where the system has to
process a large number of similar requests in a short time. Mean time to
failure (MTTF) is the reciprocal of ROCOF.
• Availability (AVAIL). Measure of the fraction of the time that the system
is available for use. Takes repair and restart time into account. Relevant
for non-stop, continuously running systems.

Non-functional reliability requirements are specifications of the required

reliability and availability of a system using one of the reliability metrics (POFOD,
ROCOF or AVAIL). Quantitative reliability and availability specification has been
used for many years in safety-critical systems but is uncommon for business-
critical systems. However, as more and more companies demand 24/7 service
from their systems, it makes sense for them to be precise about their reliability
and availability expectations.

Functional reliability requirements specify the faults to be detected and the

actions to be taken to ensure that these faults do not lead to system failures.

• Checking requirements that identify checks to ensure that incorrect data is

detected before it leads to a failure.
• Recovery requirements that are geared to help the system recover after a
failure has occurred.
• Redundancy requirements that specify redundant features of the system to
be included.
• Process requirements for reliability which specify the development process
to be used may also be included.

Fault-Tolerant Architectures

In critical situations, software systems must be fault tolerant. Fault tolerance is

required where there are high availability requirements or where system
failure costs are very high. Fault tolerance means that the system can continue
in operation in spite of software failure. Even if the system has been proved to
conform to its specification, it must also be fault tolerant as there may be
specification errors or the validation may be incorrect.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Fault-tolerant systems architectures are used in situations where fault

tolerance is essential. These architectures are generally all based on redundancy
and diversity. Examples of situations where dependable architectures are used:

• Flight control systems, where system failure could threaten the safety of
passengers;
• Reactor systems where failure of a control system could lead to a chemical
or nuclear emergency;
• Telecommunication systems, where there is a need for 24/7 availability.

Protection system is a specialized system that is associated with some other

control system, which can take emergency action if a failure occurs, e.g. a system
to stop a train if it passes a red light, or a system to shut down a reactor if
temperature/pressure are too high. Protection systems independently monitor
the controlled system and the environment. If a problem is detected, it issues
commands to take emergency action to shut down the system and avoid a
catastrophe. Protection systems are redundant because they include monitoring
and control capabilities that replicate those in the control software. Protection
systems should be diverse and use different technology from the control software.
They are simpler than the control system so more effort can be expended in
validation and dependability assurance. Aim is to ensure that there is a low
probability of failure on demand for the protection system.

Self-monitoring architecture is a multi-channel architecture where the system

monitors its own operations and takes action if inconsistencies are detected. The
same computation is carried out on each channel and the results are compared.
If the results are identical and are produced at the same time, then it is assumed
that the system is operating correctly. If the results are different, then a failure

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

is assumed and a failure exception is raised. Hardware in each channel has to be

diverse so that common mode hardware failure will not lead to each channel
producing the same results. Software in each channel must also be diverse,
otherwise the same software error would affect each channel. If high-availability
is required, you may use several self-checking systems in parallel. This is the
approach used in the Airbus family of aircraft for their flight control systems.

N-version programming involves multiple versions of a software system to

carry out computations at the same time. There should be an odd number of
computers involved, typically 3. The results are compared using a voting system
and the majority result is taken to be the correct result. Approach derived from
the notion of triple-modular redundancy, as used in hardware systems.

Hardware fault tolerance depends on triple-modular redundancy (TMR). There

are three replicated identical components that receive the same input and whose
outputs are compared. If one output is different, it is ignored and component
failure is assumed. Based on most faults resulting from component failures rather
than design faults and a low probability of simultaneous component failure.

Programming for reliability

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Good programming practices can be adopted that help reduce the incidence of
program faults. These programming practices support fault avoidance, detection,
and tolerance.

Limit the visibility of information in a program

Program components should only be allowed access to data that they need for
their implementation. This means that accidental corruption of parts of the
program state by these components is impossible. You can control visibility by
using abstract data types where the data representation is private and you only
allow access to the data through predefined operations such as get () and put ().

Check all inputs for validity

All program take inputs from their environment and make assumptions about
these inputs. However, program specifications rarely define what to do if an input
is not consistent with these assumptions. Consequently, many programs behave
unpredictably when presented with unusual inputs and, sometimes, these are
threats to the security of the system. Consequently, you should always check
inputs before processing against the assumptions made about these inputs.

Provide a handler for all exceptions

A program exception is an error or some unexpected event such as a power

failure. Exception handling constructs allow for such events to be handled without
the need for continual status checking to detect exceptions. Using normal control
constructs to detect exceptions needs many additional statements to be added to
the program. This adds a significant overhead and is potentially error-prone.

Minimize the use of error-prone constructs

Program faults are usually a consequence of human error because programmers

lose track of the relationships between the different parts of the system This is
exacerbated by error-prone constructs in programming languages that are
inherently complex or that don't check for mistakes when they could do so.
Therefore, when programming, you should try to avoid or at least minimize the
use of these error-prone constructs.

Error-prone constructs:

• Unconditional branch (goto) statements

• Floating-point numbers (inherently imprecise, which may lead to invalid
comparisons)
• Pointers
• Dynamic memory allocation

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Parallelism (can result in subtle timing errors because of unforeseen

interaction between parallel processes)
• Recursion (can cause memory overflow as the program stack fills up)
• Interrupts (can cause a critical operation to be terminated and make a
program difficult to understand)
• Inheritance (code is not localized, which may result in unexpected behavior
when changes are made and problems of understanding the code)
• Aliasing (using more than 1 name to refer to the same state variable)
• Unbounded arrays (may result in buffer overflow)
• Default input processing (if the default action is to transfer control
elsewhere in the program, incorrect or deliberately malicious input can then
trigger a program failure)

Provide restart capabilities

For systems that involve long transactions or user interactions, you should always
provide a restart capability that allows the system to restart after failure without
users having to redo everything that they have done.

Check array bounds

In some programming languages, such as C, it is possible to address a memory

location outside of the range allowed for in an array declaration. This leads to the
well-known 'bounded buffer' vulnerability where attackers write executable code
into memory by deliberately writing beyond the top element in an array. If your
language does not include bound checking, you should therefore always check
that an array access is within the bounds of the array.

Include timeouts when calling external components

In a distributed system, failure of a remote computer can be 'silent' so that

programs expecting a service from that computer may never receive that service
or any indication that there has been a failure. To avoid this, you should always
include timeouts on all calls to external components. After a defined time period
has elapsed without a response, your system should then assume failure and take
whatever actions are required to recover from this.

Name all constants that represent real-world values

Always give constants that reflect real-world values (such as tax rates) names
rather than using their numeric values and always refer to them by name You are
less likely to make mistakes and type the wrong value when you are using a name
rather than a value. This means that when these 'constants' change (for sure,
they are not really constant), then you only have to make the change in one place
in your program.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Reliability Measurement

Reliability metrics are used to quantitatively expressed the reliability of the

software product. The option of which parameter is to be used depends upon
the type of system to which it applies & the requirements of the application
domain.

Measuring software reliability is a severe problem because we don't have a good

understanding of the nature of software. It is difficult to find a suitable method to
measure software reliability and most of the aspects connected to software
reliability. Even the software estimates have no uniform definition. If we cannot
measure the reliability directly, something can be measured that reflects the
features related to reliability.

The current methods of software reliability measurement can be divided

into four categories:

1. Product Metrics

Product metrics are those which are used to build the artifacts, i.e., requirement
specification documents, system design documents, etc. These metrics help in
the assessment if the product is right sufficient through records on attributes like
usability, reliability, maintainability & portability. In these measurements are
taken from the actual body of the source code.

i. Software size is thought to be reflective of complexity, development effort,

and reliability. Lines of Code (LOC), or LOC in thousands (KLOC), is an
initial intuitive approach to measuring software size. The basis of LOC is

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

that program length can be used as a predictor of program characteristics

such as effort &ease of maintenance. It is a measure of the functional
complexity of the program and is independent of the programming
language.
ii. Function point metric is a technique to measure the functionality of
proposed software development based on the count of inputs, outputs,
master files, inquires, and interfaces.
iii. Test coverage metric size fault and reliability by performing tests on
software products, assuming that software reliability is a function of the
portion of software that is successfully verified or tested.
iv. Complexity is directly linked to software reliability, so representing
complexity is essential. Complexity-oriented metrics is a way of
determining the complexity of a program's control structure by simplifying
the code into a graphical representation. The representative metric is
McCabe's Complexity Metric.
v. Quality metrics measure the quality at various steps of software product
development. An vital quality metric is Defect Removal Efficiency
(DRE). DRE provides a measure of quality because of different quality
assurance and control activities applied throughout the development
process.

2. Project Management Metrics

Project metrics define project characteristics and execution. If there is proper

management of the project by the programmer, then this helps us to achieve
better products. A relationship exists between the development process and the
ability to complete projects on time and within the desired quality objectives. Cost
increase when developers use inadequate methods. Higher reliability can be
achieved by using a better development process, risk management process,
configuration management process.

These metrics are:

o Number of software developers

o Staffing pattern over the life-cycle of the software
o Cost and schedule
o Productivity

3. Process Metrics

Process metrics quantify useful attributes of the software development process &
its environment. They tell if the process is functioning optimally as they report on
characteristics like cycle time & rework time. The goal of process metric is to do
the right job on the first time through the process. The quality of the product is
a direct function of the process. So process metrics can be used to estimate,
monitor, and improve the reliability and quality of software. Process metrics

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

describe the effectiveness and quality of the processes that produce the software
product.

Examples are:

o The effort required in the process

o Time to produce the product
o Effectiveness of defect removal during development
o Number of defects found during testing
o Maturity of the process

4. Fault and Failure Metrics

A fault is a defect in a program which appears when the programmer makes an

error and causes failure when executed under particular conditions. These metrics
are used to determine the failure-free execution software.

To achieve this objective, a number of faults found during testing and the failures
or other problems which are reported by the user after delivery are collected,
summarized, and analyzed. Failure metrics are based upon customer information
regarding faults found after release of the software. The failure data collected is
therefore used to calculate failure density, Mean Time between Failures
(MTBF), or other parameters to measure or predict software reliability.

Safety Engineering and Safety Engineering Processes

Safety engineering is an engineering discipline which assures that engineered

systems provide acceptable levels of safety. It is strongly related to industrial
engineering/systems engineering, and the subset system safety engineering.

Safety engineering processes are based on reliability engineering

processes. Regulators may require evidence that safety engineering
processes have been used in system development.

Agile methods are not usually used for safety-critical systems engineering.
Extensive process and product documentation is needed for system regulation,
which contradicts the focus in agile methods on the software itself. A detailed
safety analysis of a complete system specification is important, which contradicts
the interleaved development of a system specification and program. However,
some agile techniques such as test-driven development may be used.

Process assurance involves defining a dependable process and ensuring that

this process is followed during the system development. Process assurance
focuses on:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Do we have the right processes? Are the processes appropriate for the
level of dependability required. Should include requirements management,
change management, reviews and inspections, etc.
• Are we doing the processes right? Have these processes been followed
by the development team.

Process assurance is important for safety-critical systems development:

accidents are rare events so testing may not find all problems; safety
requirements are sometimes 'shall not' requirements so cannot be demonstrated
through testing. Safety assurance activities may be included in the software
process that record the analyses that have been carried out and the people
responsible for these.

Safety-related process activities:

• Creation of a hazard logging and monitoring system;

• Appointment of project safety engineers who have explicit responsibility for
system safety;
• Extensive use of safety reviews;
• Creation of a safety certification system where the safety of critical
components is formally certified;
• Detailed configuration management.

Formal methods can be used when a mathematical specification of the system

is produced. They are the ultimate static verification technique that may be used
at different stages in the development process. A formal specification may be
developed and mathematically analyzed for consistency. This helps discover
specification errors and omissions. Formal arguments that a program conforms
to its mathematical specification may be developed. This is effective in
discovering programming and design errors.

Advantages of formal methods

Producing a mathematical specification requires a detailed analysis of the

requirements and this is likely to uncover errors. Concurrent systems can be
analyzed to discover race conditions that might lead to deadlock. Testing for such
problems is very difficult. They can detect implementation errors before testing
when the program is analyzed alongside the specification.

Disadvantages of formal methods

Require specialized notations that cannot be understood by domain experts. Very

expensive to develop a specification and even more expensive to show that a
program meets that specification. Proofs may contain errors. It may be possible
to reach the same level of confidence in a program more cheaply using other V &
V techniques.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Model checking involves creating an extended finite state model of a system

and, using a specialized system (a model checker), checking that model for
errors. The model checker explores all possible paths through the
model and checks that a user-specified property is valid for each path. Model
checking is particularly valuable for verifying concurrent systems, which are hard
to test. Although model checking is computationally very expensive, it is now
practical to use it in the verification of small to medium sized critical systems.

Static program analysis uses software tools for source text processing. They
parse the program text and try to discover potentially erroneous conditions and
bring these to the attention of the V & V team. They are very effective as an aid
to inspections - they are a supplement to but not a replacement for inspections.

Three levels of static analysis:

Characteristic error checking

The static analyzer can check for patterns in the code that are characteristic of
errors made by programmers using a particular language.

User-defined error checking

Users of a programming language define error patterns, thus extending the types
of error that can be detected. This allows specific rules that apply to a program
to be checked.

Assertion checking

Developers include formal assertions in their program and relationships that must
hold. The static analyzer symbolically executes the code and highlights potential
problems.

Static analysis is particularly valuable when a language such as C is used which

has weak typing and hence many errors are undetected by the compiler.
Particularly valuable for security checking - the static analyzer can discover areas
of vulnerability such as buffer overflows or unchecked inputs. Static analysis is
now routinely used in the development of many safety and security critical
systems.

Safety-critical systems

In safety-critical systems it is essential that system operation is always safe i.e.

the system should never cause damage to people or the system's environment.
Examples: control and monitoring systems in aircraft, process control systems in
chemical manufacture, automobile control systems such as braking and engine
management systems.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Two levels of safety criticality:

• Primary safety-critical systems: embedded software systems whose

failure can cause the associated hardware to fail and directly threaten
people.
• Secondary safety-critical systems: systems whose failure results in faults
in other (socio-technical) systems, which can then have safety
consequences.

Safety terminology

Term Definition
An unplanned event or sequence of events which results in human death
Accident
or injury, damage to property, or to the environment. An overdose of
(mishap)
insulin is an example of an accident.

Hazard A condition with the potential for causing or contributing to an accident.

A measure of the loss resulting from a mishap. Damage can range from
Damage many people being killed as a result of an accident to minor injury or
property damage.

An assessment of the worst possible damage that could result from a

Hazard
particular hazard. Hazard severity can range from catastrophic, where
severity
many people are killed, to minor, where only minor damage results.

The probability of the events occurring which create a hazard. Probability

Hazard values tend to be arbitrary but range from 'probable' (e.g. 1/100 chance
probability of a hazard occurring) to 'implausible' (no conceivable situations are likely
in which the hazard could occur).

This is a measure of the probability that the system will cause an accident.
Risk The risk is assessed by considering the hazard probability, the hazard
severity, and the probability that the hazard will lead to an accident.

Safety achievement strategies:

Hazard avoidance

The system is designed so that some classes of hazard simply cannot arise.

Hazard detection and removal

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

The system is designed so that hazards are detected and removed before they
result in an accident.

Damage limitation

The system includes protection features that minimize the damage that may
result from an accident.

Accidents in complex systems rarely have a single cause as these systems are
designed to be resilient to a single point of failure. Almost all accidents are a
result of combinations of malfunctions rather than single failures. It is probably
the case that anticipating all problem combinations, especially, in software-
controlled systems is impossible so achieving complete safety is impossible.
However, accidents are inevitable.

Safety Requirements

The goal of safety requirements engineering is to identify protection

requirements that ensure that system failures do not cause injury or death or
environmental damage. Safety requirements may be 'shall not' requirements i.e.
they define situations and events that should never occur. Functional safety
requirements define: checking and recovery features that should be included in a
system, and features that provide protection against system failures and external
attacks.

Hazard-driven analysis:

Hazard identification

Identify the hazards that may threaten the system. Hazard identification may be
based on different types of hazards: physical, electrical, biological, service
failure, etc.

Hazard assessment

The process is concerned with understanding the likelihood that a risk will
arise and the potential consequences if an accident or incident should occur.
Risks may be categorized as: intolerable (must never arise or result in an
accident), as low as reasonably practical - ALARP (must minimize the
possibility of risk given cost and schedule constraints), and acceptable (the
consequences of the risk are acceptable and no extra costs should be incurred to
reduce hazard probability).

The acceptability of a risk is determined by human, social, and political

considerations. In most societies, the boundaries between the regions are pushed
upwards with time i.e. society is less willing to accept risk (e.g., the costs of

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

cleaning up pollution may be less than the costs of preventing it but this may not
be socially acceptable). Risk assessment is subjective.

Hazard assessment process: for each identified hazard, assess hazard probability,
accident severity, estimated risk, acceptability.

Hazard analysis

Concerned with discovering the root causes of risks in a particular system.

Techniques have been mostly derived from safety-critical systems and can
be: inductive, bottom-up: start with a proposed system failure and assess the
hazards that could arise from that failure; and deductive, top-down: start with
a hazard and deduce what the causes of this could be.

Fault-tree analysis is a deductive top-down technique.:

• Put the risk or hazard at the root of the tree and identify the system states
that could lead to that hazard.
• Where appropriate, link these with 'and' or 'or' conditions.
• A goal should be to minimize the number of single causes of system failure.

Risk reduction

The aim of this process is to identify dependability requirements that specify

how the risks should be managed and ensure that accidents/incidents do not
arise. Risk reduction strategies: hazard avoidance; hazard detection and removal;
damage limitation.

Safety Cases

A safety case is a written proof that identifies the hazards and risks of a
manufactured product or installation. A safety case is a structured argument,
supported by evidence, intended to justify that a system is acceptably safe, and
when there is danger or damage to make it as low as reasonably possible
(ALARP). In industries like transportation and medicine, safety cases are
mandatory and legally binding. Safety cases tend to be presented in a document
of textual information and requirements accompanied by a graphical notation.
The most popular way to this graphical notation is using the Goal Structure
Notation (GSN). Even though a requirement in the automotive ISO 26262, the
GSN notation is not some farfetched complex. It is basically sets the goals, the
strategies justifying the claims and evidence, and a solution to make that goal
safe.

The elements of the Goal Structured Notation have a Symbol plus a count, and
are inside a shape. They are as following: (*N represents a number that grows
to N+1 on each preceding)

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• A goal G(N), are rectangles, setting up and objective or sub objective of

the safety case.
• A strategy S(N), represented in a parallelogram, describes process or
inference between a goal and its supporting goal(s) and solutions.
• A solution Sn(N) shown inside a circle, demonstrates a reference or proof.
• A context C(N), shown like a square with curved edges. It defines the limits
that apply to the outlined structure.
• A justification J(N), rendered as an oval shows a rational or logical
statement
• An assumption A(N), also rendered as an oval, presents an intentionally
unsubstantiated statement.

So, considering how a safety case in the GSN notation is structured any program
that can make sketches like Microsoft Visio or mind map could work. But there is
a tool specifically for this it is called ASTHA-GSN. It has an student license, and
the tool has some major pluses:

• A simple easy to use user interface

• It will track the number of structures you have placed and sequentially
number them. Your first goal will automatically be G1, and then G2 and so
on
• It follows the structure, and knowing you are building a GSN safety case it
will tell you if what you are connecting is incorrect.
• It lets you color scheme
o All Goals as Blue
o Strategies as Green
o Solutions as red

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

o Contexts are yellow

o And justifications and Arguments are white and grey

Security Engineering

Security engineering is a sub-field of the broader field of computer security. It

encompasses tools, techniques and methods to support the development and
maintenance of systems that can resist malicious attacks that are intended to
damage a computer-based system or its data.

Dimensions of security:

• Confidentiality Information in a system may be disclosed or made

accessible to people or programs that are not authorized to have access to
that information.
• Integrity Information in a system may be damaged or corrupted making
it unusual or unreliable.
• Availability Access to a system or its data that is normally available may
not be possible.

Three levels of security:

• Infrastructure security is concerned with maintaining the security of all

systems and networks that provide an infrastructure and a set of shared
services to the organization.
• Application security is concerned with the security of individual
application systems or related groups of systems.
• Operational security is concerned with the secure operation and use of
the organization's systems.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Application security is a software engineering problem where the system is

designed to resist attacks. Infrastructure security is a systems management
problem where the infrastructure is configured to resist attacks.

System security management involves user and permission

management (adding and removing users from the system and setting up
appropriate permissions for users), software deployment and
maintenance (installing application software and middleware and configuring
these systems so that vulnerabilities are avoided), attack monitoring,
detection and recovery (monitoring the system for unauthorized access, design
strategies for resisting attacks and develop backup and recovery strategies).

Operational security is primarily a human and social issue, which is concerned

with ensuring the people do not take actions that may compromise system
security. Users sometimes take insecure actions to make it easier for them to do
their jobs. There is therefore a trade-off between system security and system
effectiveness.

Security and Dependability

The security of a system is a property that reflects the system's ability to

protect itself from accidental or deliberate external attack. Security is
essential as most systems are networked so that external access to the system
through the Internet is possible. Security is an essential pre-requisite for
availability, reliability and safety.

Reliability terminology

Term Description
Something of value which has to be protected. The asset may be
Asset
the software system itself or data used by that system.
An exploitation of a system's vulnerability. Generally, this is from
Attack outside the system and is a deliberate attempt to cause some
damage.
A protective measure that reduces a system's vulnerability.
Control Encryption is an example of a control that reduces a vulnerability of
a weak access control system.
Possible loss or harm to a computing system. This can be loss or
Exposure damage to data, or can be a loss of time and effort if recovery is
necessary after a security breach.
Circumstances that have potential to cause loss or harm. You can
Threat think of these as a system vulnerability that is subjected to an
attack.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

A weakness in a computer-based system that may be exploited to

Vulnerability
cause loss or harm.

Four types of security threats:

• Interception threats that allow an attacker to gain access to an asset.

• Interruption threats that allow an attacker to make part of the system
unavailable.
• Modification threats that allow an attacker to tamper with a system asset.
• Fabrication threats that allow an attacker to insert false information into
a system.

Security assurance strategies:

Vulnerability avoidance

The system is designed so that vulnerabilities do not occur. For example, if there
is no external network connection then external attack is impossible.

Attack detection and elimination

The system is designed so that attacks on vulnerabilities are detected and

neutralized before they result in an exposure. For example, virus checkers find
and remove viruses before they infect a system.

Exposure limitation and recovery

The system is designed so that the adverse consequences of a successful attack

are minimized. For example, a backup policy allows damaged information to be
restored.

Security and attributes of dependability:

Security and reliability

If a system is attacked and the system or its data are corrupted as a consequence
of that attack, then this may induce system failures that compromise the
reliability of the system.

Security and availability

A common attack on a web-based system is a denial-of-service attack, where a

web server is flooded with service requests from a range of different sources. The
aim of this attack is to make the system unavailable.

Security and safety

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

An attack that corrupts the system or its data means that assumptions about
safety may not hold. Safety checks rely on analyzing the source code of safety
critical software and assume the executing code is a completely accurate
translation of that source code. If this is not the case, safety-related failures may
be induced and the safety case made for the software is invalid.

Security and resilience

Resilience is a system characteristic that reflects its ability to resist and recover
from damaging events. The most probable damaging event on networked
software systems is a cyberattack of some kind so most of the work now done in
resilience is aimed at deterring, detecting and recovering from such attacks.

Security and organizations

Security is expensive and it is important that security decisions are made in a

cost-effective way. There is no point in spending more than the value of an asset
to keep that asset secure. Organizations use a risk-based approach to support
security decision making and should have a defined security policy based on
security risk analysis. Security risk analysis is a business rather than a technical
process.

Security policies should set out general information access strategies that
should apply across the organization. The point of security policies is to inform
everyone in an organization about security so these should not be long and
detailed technical documents. From a security engineering perspective, the
security policy defines, in broad terms, the security goals of the organization. The
security engineering process is concerned with implementing these goals.

Security policies principles:

The assets that must be protected

It is not cost-effective to apply stringent security procedures to all organizational

assets. Many assets are not confidential and can be made freely available.

The level of protection that is required for different types of asset

For sensitive personal information, a high level of security is required; for other
information, the consequences of loss may be minor so a lower level of security
is adequate.

The responsibilities of individual users, managers and the organization

The security policy should set out what is expected of users e.g. strong
passwords, log out of computers, office security, etc.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Existing security procedures and technologies that should be maintained

For reasons of practicality and cost, it may be essential to continue to use existing
approaches to security even where these have known limitations.

Risk assessment and management is concerned with assessing the possible

losses that might ensue from attacks on the system and balancing these losses
against the costs of security procedures that may reduce these losses. Risk
management should be driven by an organizational security policy. Risk
management involves:

Preliminary risk assessment

The aim of this initial risk assessment is to identify generic risks that are
applicable to the system and to decide if an adequate level of security can be
achieved at a reasonable cost. The risk assessment should focus on the
identification and analysis of high-level risks to the system. The outcomes of the
risk assessment process are used to help identify security requirements.

Design risk assessment

This risk assessment takes place during the system development life cycle and is
informed by the technical system design and implementation decisions. The
results of the assessment may lead to changes to the security requirements and
the addition of new requirements. Known and potential vulnerabilities are
identified, and this knowledge is used to inform decision making about the system
functionality and how it is to be implemented, tested, and deployed.

Operational risk assessment

This risk assessment process focuses on the use of the system and the possible
risks that can arise from human behavior. Operational risk assessment should
continue after a system has been installed to take account of how the system is
used. Organizational changes may mean that the system is used in different ways
from those originally planned. These changes lead to new security requirements
that have to be implemented as the system evolves.

Security Requirements

Security specification has something in common with safety requirements

specification - in both cases, your concern is to avoid something bad happening.
Four major differences:

• Safety problems are accidental - the software is not operating in a

hostile environment. In security, you must assume that attackers have
knowledge of system weaknesses.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• When safety failures occur, you can look for the root cause or
weakness that led to the failure. When failure results from a deliberate
attack, the attacker may conceal the cause of the failure.
• Shutting down a system can avoid a safety-related failure. Causing a
shutdown may be the aim of an attack.
• Safety-related events are not generated from an intelligent
adversary. An attacker can probe defenses over time to discover
weaknesses.

Security requirement classification

• Risk avoidance requirements set out the risks that should be avoided by
designing the system so that these risks simply cannot arise.
• Risk detection requirements define mechanisms that identify the risk if it
arises and neutralize the risk before losses occur.
• Risk mitigation requirements set out how the system should be designed
so that it can recover from and restore system assets after some loss has
occurred.

Security risk assessment

• Asset identification: identify the key system assets (or services) that
have to be protected.
• Asset value assessment: estimate the value of the identified assets.
• Exposure assessment: assess the potential losses associated with each
asset.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Threat identification: identify the most probable threats to the system

assets.
• Attack assessment: decompose threats into possible attacks on the
system and the ways that these may occur.
• Control identification: propose the controls that may be put in place to
protect an asset.
• Feasibility assessment: assess the technical feasibility and cost of the
controls.
• Security requirements definition: define system security requirements.
These can be infrastructure or application system requirements.

Misuse cases are instances of threats to a system:

• Interception threats: attacker gains access to an asset.

• Interruption threats: attacker makes part of a system unavailable.
• Modification threats: a system asset if tampered with.
• Fabrication threats: false information is added to a system.

Secure System Design

Security should be designed into a system - it is very difficult to make an

insecure system secure after it has been designed or implemented.

Adding security features to a system to enhance its security affects other

attributes of the system:

• Performance: additional security checks slow down a system so its

response time or throughput may be affected.
• Usability: security measures may require users to remember information
or require additional interactions to complete a transaction. This makes the
system less usable and can frustrate system users.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Design risk assessment is done while the system is being developed and after
it has been deployed. More information is available - system platform, middleware
and the system architecture and data organization. Vulnerabilities that arise from
design choices may therefore be identified.

During architectural design, two fundamental issues have to be considered

when designing an architecture for security:

Protection: how should the system be organized so that critical assets

can be protected against external attack?

Layered protection architecture:

Platform-level protection: top-level controls on the platform on which a
system runs.
Application-level protection: specific protection mechanisms built into the
application itself e.g., additional password protection.
Record-level protection: protection that is invoked when access to specific
information is requested.

Distribution: how should system assets be distributed so that the effects

of a successful attack are minimized?

Distributing assets means that attacks on one system do not necessarily lead to
complete loss of system service. Each platform has separate protection features
and may be different from other platforms so that they do not share a common
vulnerability. Distribution is particularly important if the risk of denial-of-service
attacks is high.

These are potentially conflicting. If assets are distributed, then they are more
expensive to protect. If assets are protected, then usability and performance
requirements may be compromised.

Design guidelines for security engineering: -

Design guidelines encapsulate good practice in secure systems design. Design

guidelines serve two purposes: they raise awareness of security issues in a
software engineering team, and they can be used as the basis of a review
checklist that is applied during the system validation process. Design guidelines
here are applicable during software specification and design.

o Base decisions on an explicit security policy - Define a security policy

for the organization that sets out the fundamental security requirements
that should apply to all organizational systems.
o Avoid a single point of failure - Ensure that a security failure can only
result when there is more than one failure in security procedures. For
example, have password and question-based authentication.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

o Fail securely - When systems fail, for whatever reason, ensure that
sensitive information cannot be accessed by unauthorized users even
although normal security procedures are unavailable.
o Balance security and usability - Try to avoid security procedures that
make the system difficult to use. Sometimes you have to accept weaker
security to make the system more usable.
o Log user actions - Maintain a log of user actions that can be analyzed to
discover who did what. If users know about such a log, they are less likely
to behave in an irresponsible way.
o Use redundancy and diversity to reduce risk - Keep multiple copies of
data and use diverse infrastructure so that an infrastructure vulnerability
cannot be the single point of failure.
o Specify the format of all system inputs - If input formats are known
then you can check that all inputs are within range so that unexpected
inputs don't cause problems.
o Compartmentalize your assets - Organize the system so that assets are
in separate areas and users only have access to the information that they
need rather than all system information.
o Design for deployment - Design the system to avoid deployment
problems
o Design for recoverability - Design the system to simplify recoverability
after a successful attack.

Security Testing and Assurance

What is Security Testing?

Security Testing is a type of Software Testing that uncovers vulnerabilities,

threats, risks in a software application and prevents malicious attacks from
intruders. The purpose of Security Tests is to identify all possible loopholes and
weaknesses of the software system which might result in a loss of information,
revenue, repute at the hands of the employees or outsiders of the Organization.

Why Security Testing is Important?

The main goal of Security Testing is to identify the threats in the system and
measure its potential vulnerabilities, so the threats can be encountered and the
system does not stop functioning or cannot be exploited. It also helps in detecting
all possible security risks in the system and helps developers to fix the problems
through coding.

Types of Security Testing in Software Testing

There are seven main types of security testing as per Open-Source Security
Testing methodology manual. They are explained as follows:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Vulnerability Scanning: This is done through automated software to scan

a system against known vulnerability signatures.
• Security Scanning: It involves identifying network and system
weaknesses, and later provides solutions for reducing these risks. This
scanning can be performed for both Manual and Automated scanning.
• Penetration testing: This kind of testing simulates an attack from a
malicious hacker. This testing involves analysis of a particular system to
check for potential vulnerabilities to an external hacking attempt.
• Risk Assessment: This testing involves analysis of security risks observed
in the organization. Risks are classified as Low, Medium and High. This
testing recommends controls and measures to reduce the risk.
• Security Auditing: This is an internal inspection of Applications and
Operating systems for security flaws. An audit can also be done via line-
by-line inspection of code
• Ethical hacking: It’s hacking an Organization Software system. Unlike
malicious hackers, who steal for their own gains, the intent is to expose
security flaws in the system.
• Posture Assessment: This combines Security scanning, Ethical Hacking
and Risk Assessments to show an overall security posture of an
organization.

How to do Security Testing

It is always agreed, that cost will be more if we postpone security testing after
software implementation phase or after deployment. So, it is necessary to involve
security testing in the SDLC life cycle in the earlier phases.

Let’s look into the corresponding Security processes to be adopted for every
phase in SDLC

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

SDLC Phases Security Processes

Security analysis for requirements and check abuse/misuse
Requirements
cases
Security risks analysis for designing. Development of Test
Design
Plan including security tests
Coding and Unit
Static and Dynamic Testing and Security White Box Testing
Testing
Integration Testing Black Box Testing
System Testing Black Box Testing and Vulnerability scanning
Implementation Penetration Testing, Vulnerability Scanning
Support Impact analysis of Patches

The test plan should include

• Security-related test cases or scenarios

• Test Data related to security testing
• Test Tools required for security testing
• Analysis of various tests outputs from different security tools

Example Test Scenarios for Security Testing

Sample Test scenarios to give you a glimpse of security test cases –

• A password should be in encrypted format

• Application or System should not allow invalid users
• Check cookies and session time for application
• For financial sites, the Browser back button should not work.

Methodologies/ Approach / Techniques for Security Testing

In security testing, different methodologies are followed, and they are as follows:

• Tiger Box: This hacking is usually done on a laptop which has a collection
of OSs and hacking tools. This testing helps penetration testers and security
testers to conduct vulnerabilities assessment and attacks.
• Black Box: Tester is authorized to do testing on everything about the
network topology and the technology.
• Grey Box: Partial information is given to the tester about the system, and
it is a hybrid of white and black box models.

Security Testing Roles

• Hackers – Access computer system or network without authorization

• Crackers – Break into the systems to steal or destroy data

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Ethical Hacker – Performs most of the breaking activities but with

permission from the owner
• Script Kiddies or packet monkeys – Inexperienced Hackers with
programming language skill

What is Software Security Assurance?

Software security assurance (SSA) is an approach to designing, building,

and implementing software that addresses security needs from the
ground up. Transparency is critical with SSA because it provides a high level of
trust that an application performs as intended without any unexpected functions
that could lead to security compromises.

The benefits of SSA extend from the companies that develop software to
the end users of that software. When procuring a third-party application, SSA
assures that you’re getting code built from the ground up with security in mind.

Today’s digitally-powered businesses often depend on integrating

multiple software components. Poor security in any of these components
could either bring the store offline or put customer data at risk
(see SolarWinds). Consider how an eCommerce company depends on a
website, an online store, analytics, CRM software, inventory management
software, and more.

For software-led businesses that sell software to other companies or users, SSA
increases trust in your code. And, when coding custom web applications in-
house for your own company’s use, SSA can significantly reduce the likelihood of
breaches or compromises from basic security mistakes.

It’s important not to confuse the concept of SSA with the popular idea of shifting
security to the left. Shift left guard mainly focuses on moving security checks and
tests to earlier phases of the development cycle.

SSA, however, is an entire secure-by-design ethos that evaluates

security concerns based on the software’s tasks, the data it will handle,
and the vulnerabilities that could be present.

Software security assurance also differs from quality assurance in that the latter
is about ensuring software engineering processes meet defined policies and
standards, usually through testing. Security assurance, on the other hand, is
all about ensuring that software conforms to its security requirements
and doesn’t include any functionality that could compromise security.

Resilience Engineering

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

The resilience of a system is a judgment of how well that system can maintain
the continuity of its critical services in the presence of disruptive events, such
as equipment failure and cyberattacks. This view encompasses these three ideas:

• Some of the services offered by a system are critical services whose

failure could have serious human, social or economic effects.
• Some events are disruptive and can affect the ability of a system to
deliver its critical services.
• Resilience is a judgment - there are no resilience metrics and resilience
cannot be measured. The resilience of a system can only be assessed by
experts, who can examine the system and its operational processes.

Resilience engineering places more emphasis on limiting the number of

system failures that arise from external events such as operator errors or
cyberattacks. Assumptions:

• It is impossible to avoid system failures and so is concerned

with limiting the costs of these failures and recovering from them.
• Good reliability engineering practices have been used to minimize the
number of technical faults in a system.

Four related resilience activities are involved in the detection and recovery
from system problems:

• The system or its operators should recognize early indications of system

failure.
• If the symptoms of a problem or cyberattack are detected early,
then resistance strategies may be used to reduce the probability that the
system will fail.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• If a failure occurs, the recovery activity ensures that critical system

services are restored quickly so that system users are not badly affected
by failure.
• In this final activity, all of the system services are restored and normal
system operation can continue.

Cybersecurity

Cybercrime is the illegal use of networked systems and is one of the most
serious problems facing our society. Cybersecurity is a broader topic than system
security engineering. Cybersecurity is a socio-technical issue covering all
aspects of ensuring the protection of citizens, businesses, and critical
infrastructures from threats that arise from their use of computers and the
Internet. Cybersecurity is concerned with all of an organization's IT assets from
networks through to application systems.

Factors contributing to cybersecurity failure:

• Organizational ignorance of the seriousness of the problem,

• Poor design and lax application of security procedures,
• Human carelessness,
• Inappropriate trade-offs between usability and security.

Cybersecurity threats:

• Threats to the confidentiality of assets: data is not damaged but it is

made available to people who should not have access to it.
• Threats to the integrity of assets: systems or data are damaged in some
way by a cyberattack.
• Threats to the availability of assets: aim to deny the use of assets by
authorized users.

Examples of controls to protect the assets:

• Authentication, where users of a system have to show that they are

authorized to access the system.
• Encryption, where data is algorithmically scrambled so that an
unauthorized reader cannot access the information.
• Firewalls, where incoming network packets are examined then accepted
or rejected according to a set of organizational rules.

Redundancy and diversity are valuable for cybersecurity resilience:

• Copies of data and software should be maintained on separate computer

systems (supports recovery and reinstatement).

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Multi-stage diverse authentication can protect against password attacks

(supports resistance).
• Critical servers may be over-provisioned i.e. they may be more powerful
than is required to handle their expected load (supports resistance).

Cyber resilience planning:

• Asset classification: the organization's hardware, software and human

assets are examined and classified depending on how essential they are to
normal operations.
• Threat identification: for each of the assets (or, at least the critical and
important assets), you should identify and classify threats to that asset.
• Threat recognition: for each threat or, sometimes asset/threat pair, you
should identify how an attack based on that threat might be recognized.
• Threat resistance: for each threat or asset/threat pair, you should
identify possible resistance strategies. These may be either embedded in
the system (technical strategies) or may rely on operational procedures.
• Asset recovery: for each critical asset or asset/threat pair, you should
work out how that asset could be recovered in the event of a successful
cyberattack.
• Asset reinstatement: this is a more general process of asset recovery
where you define procedures to bring the system back into normal
operation.

Socio-technical Resilience

Resilience engineering is concerned with adverse external events that can lead to
system failure. To design a resilient system, you have to think about socio-
technical systems design and not exclusively focus on software. Dealing with
these events is often easier and more effective in the broader socio-technical
system.

Four characteristics that reflect the resilience of an organization:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

The ability to respond

Organizations have to be able to adapt their processes and procedures in

response to risks. These risks may be anticipated risks or may be detected threats
to the organization and its systems.

The ability to monitor

Organizations should monitor both their internal operations and their external
environment for threats before they arise.

The ability to anticipate

A resilient organization should not simply focus on its current operations but
should anticipate possible future events and changes that may affect its
operations and resilience.

The ability to learn

Organizational resilience can be improved by learning from experience. It is

particularly important to learn from successful responses to adverse events such
as the effective resistance of a cyberattack. Learning from success allows.

People inevitably make mistakes (human errors) that sometimes lead to serious
system failures. There are two ways to consider human error:

• The person approach. Errors are considered to be the responsibility of

the individual and 'unsafe acts' (such as an operator failing to engage a
safety barrier) are a consequence of individual carelessness or reckless
behavior.
• The systems approach. The basic assumption is that people are fallible
and will make mistakes. People make mistakes because they are under
pressure from high workloads, poor training or because of inappropriate
system design.

Systems engineers should assume that human errors will occur during system
operation. To improve the resilience of a system, designers have to think about
the defense and barriers to human error that could be part of a system. Can
these barriers should be built into the technical components of the system
(technical barriers)? If not, they could be part of the processes, procedures and
guidelines for using the system (socio-technical barriers).

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Defensive layers have vulnerabilities: they are like slices of Swiss cheese
with holes in the layer corresponding to these vulnerabilities. Vulnerabilities are
dynamic: the 'holes' are not always in the same place and the size of the holes
may vary depending on the operating conditions. System failures occur when the
holes line up and all of the defenses fail.

Strategies to increase system resilience:

• Reduce the probability of the occurrence of an external event that

might trigger system failures.
• Increase the number of defensive layers. The more layers that you
have in a system, the less likely it is that the holes will line up and a system
failure occur.
• Design a system so that diverse types of barriers are included. The
'holes' will probably be in different places and so there is less chance of the
holes lining up and failing to trap an error.
• Minimize the number of latent conditions in a system. This means
reducing the number and size of system 'holes'.

Resilient systems design

Designing systems for resilience involves two streams of work:

• Identifying critical services and assets that allow a system to fulfill its
primary purpose.
• Designing system components that support problem recognition,
resistance, recovery and reinstatement.

Survivable systems analysis

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• System understanding: for an existing or proposed system, review the

goals of the system (sometimes called the mission objectives), the system
requirements and the system architecture.
• Critical service identification: the services that must always be
maintained and the components that are required to maintain these
services are identified.
• Attack simulation: scenarios or use cases for possible attacks are
identified along with the system components that would be affected by
these attacks.
• Survivability analysis: components that are both essential and
comprisable by an attack are identified and survivability strategies based
on resistance, recognition and recovery are identified.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

UNIT IV SERVICE-ORIENTED SOFTWARE ENGINEERING, SYSTEMS

ENGINEERING AND REAL-TIME SOFTWARE ENGINEERING

Service-oriented Architecture

Service-Oriented Architecture (SOA) is a stage in the evolution of application

development and/or integration. It defines a way to make software components
reusable using the interfaces.

Formally, SOA is an architectural approach in which applications make use of

services available in the network. In this architecture, services are provided to
form applications, through a network call over the internet. It uses common
communication standards to speed up and streamline the service integrations in
applications. Each service in SOA is a complete business function in itself. The
services are published in such a way that it makes it easy for the developers to
assemble their apps using those services. Note that SOA is different from
microservice architecture.

• SOA allows users to combine a large number of facilities from existing

services to form applications.
• SOA encompasses a set of design principles that structure system
development and provide means for integrating components into a
coherent and decentralized system.
• SOA-based computing packages functionalities into a set of interoperable
services, which can be integrated into different software systems belonging
to separate business domains.

The different characteristics of SOA are as follows:

o Provides interoperability between the services.
o Provides methods for service encapsulation, service discovery, service
composition,
service reusability and service integration.
o Facilitates QoS (Quality of Services) through service contract based on Service
Level
Agreement (SLA).
o Provides loosely couples services.
o Provides location transparency with better scalability and availability.
o Ease of maintenance with reduced cost of application development and
deployment.
There are two major roles within Service-oriented Architecture:

1. Service provider: The service provider is the maintainer of the service

and the organization that makes available one or more services for others
to use. To advertise services, the provider can publish them in a registry,

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

together with a service contract that specifies the nature of the service,
how to use it, the requirements for the service, and the fees charged.
2. Service consumer: The service consumer can locate the service metadata
in the registry and develop the required client components to bind and use
the service.

Services might aggregate information and data retrieved from other services or
create workflows of services to satisfy the request of a given service consumer.
This practice is known as service orchestration Another important interaction
pattern is service choreography, which is the coordinated interaction of services
without a single point of control.

Components of SOA:

Guiding Principles of SOA:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

1. Standardized service contract: Specified through one or more service

description documents.
2. Loose coupling: Services are designed as self-contained components,
maintain relationships that minimize dependencies on other services.
3. Abstraction: A service is completely defined by service contracts and
description documents. They hide their logic, which is encapsulated within
their implementation.
4. Reusability: Designed as components, services can be reused more
effectively, thus reducing development time and the associated costs.
5. Autonomy: Services have control over the logic they encapsulate and,
from a service consumer point of view, there is no need to know about their
implementation.
6. Discoverability: Services are defined by description documents that
constitute supplemental metadata through which they can be effectively
discovered. Service discovery provides an effective means for utilizing
third-party resources.
7. Composability: Using services as building blocks, sophisticated and
complex operations can be implemented. Service orchestration and
choreography provide a solid support for composing services and achieving
business goals.

Advantages of SOA:

• Service reusability: In SOA, applications are made from existing services.

Thus, services can be reused to make many applications.
• Easy maintenance: As services are independent of each other they can
be updated and modified easily without affecting other services.
• Platform independent: SOA allows making a complex application by
combining services picked from different sources, independent of the
platform.
• Availability: SOA facilities are easily available to anyone on request.
• Reliability: SOA applications are more reliable because it is easy to debug
small services rather than huge codes
• Scalability: Services can run on different servers within an environment,
this increases scalability

Disadvantages of SOA:

• High overhead: A validation of input parameters of services is done

whenever services interact this decreases performance as it increases load
and response time.
• High investment: A huge initial investment is required for SOA.
• Complex service management: When services interact they exchange
messages to tasks. the number of messages may go in millions. It becomes
a cumbersome task to handle a large number of messages.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Practical applications of SOA: SOA is used in many ways around us whether

it is mentioned or not.

1. SOA infrastructure is used by many armies and air forces to deploy

situational awareness systems.
2. SOA is used to improve healthcare delivery.
3. Nowadays many apps are games and they use inbuilt functions to run. For
example, an app might need GPS so it uses the inbuilt GPS functions of the
device. This is SOA in mobile solutions.
4. SOA helps maintain museums a virtualized storage pool for their
information and content.

RESTful Services

REST or Representational State Transfer is an architectural style that can be

applied to web services to create and enhance properties like performance,
scalability, and modifiability. RESTful web services are generally highly scalable,
light, and maintainable and are used to create APIs for web-based applications.
It exposes API from an application in a secure and stateless manner to the client.
The protocol for REST is HTTP. In this architecture style, clients and servers use
a standardized interface and protocol to exchange representation of resources.

REST emerged as the predominant Web service design model just a couple of
years after its launch, measured by the number of Web services that use it. Owing
to its more straightforward style, it has mostly displaced SOAP and WSDL-based
interface design.

REST became popular due to the following reasons:

1. It allows web applications built using different programming languages to

communicate with each other. Also, web applications may reside in
different environments, like on Windows, or for example, Linux.
2. Mobile devices have become more popular than desktops. Using REST, you
don’t need to worry about the underlying layer for the device. Therefore, it
saves the amount of effort it would take to code applications on mobiles to
talk with normal web applications.
3. Modern applications have to be made compatible with the Cloud. As Cloud-
based architectures work using the REST principle, it makes sense for web
services to be programmed using the REST service-based architecture.

RESTful Architecture:

1. Division of State and Functionality: State and functionality are divided

into distributed resources. This is because every resource has to be
accessible via normal HTTP commands. That means a user should be able
to issue the GET request to get a file, issue the POST or PUT request to put

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

a file on the server, or issue the DELETE request to delete a file from the
server.
2. Stateless, Layered, Caching-Support, Client/Server Architecture: A
type of architecture where the web browser acts as the client, and the web
server acts as the server hosting the application, is called a client/server
architecture. The state of the application should not be maintained by
REST. The architecture should also be layered, meaning that there can be
intermediate servers between the client and the end server. It should also
be able to implement a well-managed caching mechanism.

Principles of RESTful applications:

1. URI Resource Identification: A RESTful web service should have a set

of resources that can be used to select targets of interactions with clients.
These resources can be identified by URI (Uniform Resource Identifiers).
The URIs provide a global addressing space and help with service discovery.
2. Uniform Interface: Resources should have a uniform or fixed set of
operations, such as PUT, GET, POST, and DELETE operations. This is a key
principle that differentiates between a REST web service and a non-REST
web service.
3. Self-Descriptive Messages: As resources are decoupled from their
representation, content can be accessed through a large number of formats
like HTML, PDF, JPEG, XML, plain text, JSON, etc. The metadata of the
resource can be used for various purposes like control caching, detecting
transmission errors, finding the appropriate representation format, and
performing authentication or access control.
4. Use of Hyperlinks for State Interactions: In REST, interactions with a
resource are stateless, that is, request messages are self-contained. So
explicit state transfer concept is used to provide stateful interactions. URI
rewriting, cookies, and form fields can be used to implement the exchange
of state. A state can also be embedded in response messages and can be
used to point to valid future states of interaction.

Advantages of RESTful web services:

1. Speed: As there is no strict specification, RESTful web services are faster

as compared to SOAP. It also consumes fewer resources and bandwidth.
2. Compatible with SOAP: RESTful web services are compatible with SOAP,
which can be used as the implementation.
3. Language and Platform Independency: RESTful web services can be
written in any programming language and can be used on any platform.
4. Supports Various Data Formats: It permits the use of several data
formats like HTML, XML, Plain Text, JSON, etc.

Service Engineering

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Service engineering is the process of developing services for reuse in service-

oriented applications. The service has to be designed as a reusable abstraction
that can be used in different systems. Generally useful functionality associated
with that abstraction must be designed and the service must be robust and
reliable. The service must be documented so that it can be discovered and
understood by potential users.

Stages of service engineering include:

• Service candidate identification, where you identify possible services

that might be implemented and define the service requirements. It involves
understanding an organization's business processes to decide which
reusable services could support these processes. Three fundamental
types of service:
o Utility services that implement general functionality used by
different business processes.
o Business services that are associated with a specific business
function e.g., in a university, student registration.
o Coordination services that support composite processes such as
ordering.
• Service design, where you design the logical service interface and its
implementation interfaces (SOAP and/or RESTful). Involves thinking about
the operations associated with the service and the messages exchanged.
The number of messages exchanged to complete a service request should
normally be minimized. Service state information may have to be included
in messages. Interface design stages:
o Logical interface design. Starts with the service requirements and
defines the operation names and parameters associated with the
service. Exceptions should also be defined.
o Message design (SOAP). For SOAP-based services, design the
structure and organization of the input and output messages.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Notations such as the UML are a more abstract representation than

XML. The logical specification is converted to a WSDL description.
o Interface design (REST). Design how the required operations map
onto REST operations and what resources are required.
• Service implementation and deployment, where you implement and
test the service and make it available for use. Programming services using
a standard programming language or a workflow language. Services then
have to be tested by creating input messages and checking that the output
messages produced are as expected. Deployment involves publicizing the
service and installing it on a web server. Current servers provide support
for service installation.

Service Composition
Existing services are composed and configured to create new composite services
and applications. The basis for service composition is often a workflow. Workflows
are logical sequences of activities that, together, model a coherent business
process. For example, provide a travel reservation services which allows flights,
car hire and hotel bookings to be coordinated.

Service construction by composition:

Formulate outline workflow
In this initial stage of service design, you use the requirements for the
composite service as a basis for creating an 'ideal' service design.
Discover services
During this stage of the process, you search service registries or catalogs
to discover what services exist, who provides these services and the details
of the service provision.
Select possible services
Your selection criteria will obviously include the functionality of the services
offered. They may also include the cost of the services and the quality of
service (responsiveness, availability, etc.) offered.
Refine workflow
This involves adding detail to the abstract description and perhaps adding
or removing workflow activities.
Create workflow program

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

During this stage, the abstract workflow design is transformed to an

executable program and the service interface is defined. You can use a
conventional programming language, such as Java or a workflow language,
such as WS-BPEL.
Test completed service or application
The process of testing the completed, composite service is more complex
than component testing in situations where external services are used.

Systems Engineering
Systems Engineering is an engineering field that takes an interdisciplinary
approach to product development. Systems engineers analyze the collection of
pieces to make sure when working together, they achieve the intended objectives
or purpose of the product. For example, in automotive development, a propulsion
system or braking system will involve mechanical engineers, electrical engineers,
and a host of other specialized engineering disciplines. A systems engineer will
focus on making each of the individual systems work together into an integrated
whole that performs as expected across the lifecycle of the product.

What are the fundamentals of systems engineering?

In product development, systems engineering is the interdisciplinary field that

focuses on designing, integrating, and managing the systems that work together
to form a more complex system. Systems engineering is based around systems
thinking principles, and the goal of a systems engineer is to help a product team
produce an engineered system that performs a useful function as defined by the
requirements written at the beginning of the project. The final product should be
one where the individual systems work together in a cohesive whole that meet
the requirements of the product.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

What is the role of a systems engineer?

A systems engineer is tasked with looking at the entire integrated system and
evaluating it against its desired outcomes. In that role, the systems engineer
must know a little bit about everything and have an ability to see the “big picture.”
While specialists can focus on their specific disciplines, the systems engineer must
evaluate the complex system as a whole against the initial requirements and
desired outcomes.

Systems engineers have multi-faceted roles to play but primarily assist with:

• Design compatibility
• Definition of requirements
• Management of projects
• Cost analysis
• Scheduling
• Possible maintenance needs
• Ease of operations
• Future systems upgrades
• Communication among engineers, managers, suppliers, and customers in
regards to the system’s operations

What is the Systems Engineering Process?

The systems engineering process can take a top-down approach, bottoms up, or
middle out depending on the system being developed. The process encompasses
all creative, manual, and technical activities necessary to define the ultimate
outcomes and see that the development process results in a product that meets
objectives.

The process typically has four basic steps:

• Task definition/analysis/conceptual: In this step, the systems

engineer works with stakeholders to understand their needs and
constraints. This stage could be considered a creative or idea stage where
brainstorming takes place and market analysis and end user desires are
included.
• Design/requirements: In this phase, individual engineers and team
members analyze the needs in step 1 and translate them into requirements
that describe how the system needs to work. The systems engineer
evaluates the systems as a whole and offers feedback to improve
integration and overall design.
• Create traceability: Although we’re listing traceability here as the third
step, traceability is actually created throughout the lifecycle of development
and is not a discrete activity taking place during one phase. Throughout the
lifecycle of development, the team works together to design individual

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

systems that will integrate into one cohesive whole. The systems engineer
helps manage traceability and integration of the individual systems.
• Implementation/market launch: When everyone has executed their
roles properly, the final product is manufactured or launched with the
assurance that it will operate as expected in a complex system throughout
its anticipated life cycle.

Socio-technical systems

Socio-technical systems are large-scale systems that do not just include software
and hardware but also people, processes and organizational policies. Socio-
technical systems are often 'systems of systems' i.e., are made up of a number
of independent systems. The boundaries of socio-technical system are subjective
rather than objective: different people see the system in different ways.

Socio-technical systems are used within organizations and are therefore

profoundly affected by the organizational environment in which they are used.
Failure to take this environment into account when designing the system is likely
to lead to user dissatisfaction and system rejection.

There are a number of key elements in an organization that may affect the
requirements, design, and operation of a socio-technical system. A new system
may lead to changes in some or all of these elements:

• Process changes: Systems may require changes to business processes so

training may be required. Significant changes may be resisted by users.
• Job changes: Systems may de-skill users or cause changes to the way
they work. The status of individuals may be affected by a new system.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Organizational policies: The proposed system may not be consistent

with current organizational policies.
• Organizational politics: Systems may change the political power
structure in an organization. Those that control the system have more
power.

A complex system may include software, mechanical, electrical and electronic

hardware and be operated by people. System components are dependent on
other
system components. The properties and behavior of system components are
inextricably inter-mingled. This leads to complexity. Complexity is the reason why
socio-technical systems have emergent properties, are non-deterministic and
have subjective success criteria:

• Emergent properties: Properties of the system of a whole that depend

on the system components and their relationships.
• Non-deterministic: They do not always produce the same output when
presented with the same input because the system’s behavior is partially
dependent on human operators.
• Complex relationships with organizational objectives: The extent to
which the system supports organizational objectives does not just depend
on the system itself.

Emergent properties are properties of the system as a whole rather than

properties that can be derived from the properties of components of a system.
Emergent properties are a consequence of the relationships between system
components. They can therefore only be assessed and measured once the
components have been integrated into a system.

Two types of emergent properties:

• Functional properties: These appear when all the parts of a system work
together to achieve some objective. For example, a bicycle has the
functional property of being a transportation device once it has been
assembled from its components.
• Non-functional emergent properties: Examples are reliability,
performance, safety, and security. These relate to the behavior of the
system in its operational environment. They are often critical for computer-
based systems as failure to achieve some minimal defined level in these
properties may make the system unusable.

System reliability is a good example of an emergent property. Because of

component inter-dependencies,
faults can be propagated through the system. System failures often occur
because of unforeseen inter-relationships between components. It is practically
impossible to anticipate all possible component relationships. Software reliability

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

measures may give a false

picture of the overall system reliability.

System reliability is influenced by:

• Hardware reliability: What is the probability of a hardware component

failing and how long does it take to repair that component?
• Software reliability: How likely is it that a software component will
produce an incorrect output. Software failure is usually distinct from
hardware failure in that software does not wear out.
• Operator reliability: How likely is it that the operator of a system will
make an error?

Failures are not independent and they propagate from one level to another.

System reliability depends on the context where the system is used. A system
that is reliable in one environment may be less reliable in a different environment
because the physical conditions (e.g., the temperature) and the mode of
operation is different.

A deterministic system is one where a given sequence of inputs will always

produce the same sequence of outputs. Software systems are deterministic;
systems that include humans are non-deterministic. A socio-technical
system will not always produce the same sequence of outputs from the same
input sequence:

• Human elements: People do not always behave in the same way.

• System changes: System behavior is unpredictable because of frequent
changes to hardware, software and data.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Complex systems are developed to address 'wicked problems' - problems

where there cannot be a complete specification. Different stakeholders see the
problem in different ways and each has a partial understanding of the issues
affecting the system. Consequently, different stakeholders have their own views
about whether or not a system is 'successful'. Success is a judgment and cannot
be objectively measured. Success is judged using the effectiveness of the system
when deployed rather than judged against the original reasons for procurement.

Conceptual design

Conceptual design investigates the feasibility of an idea and develops that idea
to create an overall vision of a system. Conceptual design precedes and overlaps
with requirements engineering. May involve discussions with users and other
stakeholders and the identification of critical requirements. The aim of conceptual
design is to create a high-level system description that communicates the system
purpose to non-technical decision makers.

Conceptual design activities:

• Concept formulation: Refine an initial statement of needs and work out

what type of system is most likely to meet the needs of system
stakeholders.
• Problem understanding: Discuss with stakeholders how they do their
work, what is and isn't important to them, what they like and don't like
about existing systems.
• System proposal development: Set out ideas for possible systems
(maybe more than one).

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Feasibility study: Look at comparable systems that have been developed

elsewhere (if any) and assess whether or not the proposed system could
be implemented using current hardware and software technologies.
• System structure development: Develop an outline architecture for the
system, identifying (where appropriate) other systems that may be reused.
• System vision document: Document the results of the conceptual design
in a readable, non-technical way. Should include a short summary and
more detailed appendices.

System Procurement

System procurement is the process of acquiring a system (or systems) to meet

some identified organizational need. Before procurement, decisions are made
on: scope of the system, system budgets and timescales, high-level
system requirements. Based on this information, decisions are made on
whether to procure a system, the type of system and the potential system
suppliers. These decisions are driven by:

• The state of other organizational systems and whether or not they need to
be replaced
• The need to comply with external regulations
• External competition
• Business re-organization
• Available budget

It is usually necessary to develop a conceptual design document and high-level

requirements before procurement. You need a specification to let a contract for
system development. The specification may allow you to buy a commercial off-
the-shelf (COTS) system. Almost always cheaper than developing a system from
scratch. Large complex systems usually consist of a mix of off the shelf and
specially designed components. The procurement processes for these different
types of components are usually different.

Three types of systems or system components may have to be procured:

• Off-the-shelf applications that may be used without change and which need
only minimal configuration for use.
• Configurable application or ERP systems that have to be modified or
adapted for use either by modifying the code or by using inbuilt
configuration features, such as process definitions and rules.
• Custom systems that have to be designed and implemented specially for
use.

Issues with system procurement:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Organizations often have an approved and recommended set of application

software that has been checked by the IT department. It is usually possible
to buy or acquire open-source software from this set directly without the
need for detailed justification. There are no detailed requirements and the
users adapt to the features of the chosen application.
• Off-the-shelf components do not usually match requirements exactly.
Choosing a system means that you have to find the closest match between
the system requirements and the facilities offered by off-the-shelf systems.
• When a system is to be built specially, the specification of requirements is
part of the contract for the system being acquired. It is therefore a legal as
well as a technical document. The requirements document is critical and
procurement processes of this type usually take a considerable amount of
time.
• For public sector systems especially, there are detailed rules and
regulations that affect the procurement of systems. These force the
development of detailed requirements and make agile development
difficult.
• For application systems that require change or for custom systems there is
usually a contract negotiation period where the customer and supplier
negotiate the terms and conditions for the development of the system.
During this process, requirements changes may be agreed to reduce the
overall costs and avoid some development problems.

System Development

System development usually follows a plan-driven approach because of the need

for parallel development of different parts of the system. Little scope for iteration
between phases because hardware changes are very expensive. Software may
have to compensate for hardware problems. Inevitably involves engineers from
different disciplines who must work together. Much scope for misunderstanding
here. Different disciplines use a different vocabulary and much negotiation is
required. Engineers may have personal agendas to fulfil.

The system development process:

• Requirements engineering: The process of refining, analyzing and

documenting the high-level and business requirements identified in the
conceptual design.
• Architectural design: Establishing the overall architecture of the system,
identifying components and their relationships.
• Requirements partitioning: Deciding which subsystems (identified in the
system architecture) are responsible for implementing the system
requirements.
• Subsystem engineering: Developing the software components of the
system, configuring off-the-shelf hardware and software, defining the
operational processes for the system and re-designing business processes.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• System integration: Putting together system elements to create a new

system.
• System testing: The whole system is tested to discover problems.
• System deployment: the process of making the system available to its
users, transferring data from existing systems and establishing
communications with other systems in the environment.

Requirements engineering and system design are inextricably linked.

Constraints posed by the system's environment and other systems limit design
choices so the actual design to be used may be a requirement. Initial design may
be necessary to structure the requirements. As you do design, you learn more
about the requirements.

Subsystem engineering may involve some application systems procurement.

Typically, parallel projects developing the hardware, software and
communications. Lack of communication across implementation teams can cause
problems. There may be a bureaucratic and slow mechanism for
proposing system changes, which means that the development schedule may be
extended because of the need for rework.

System integration is the process of putting hardware, software and

people together to make a system. Should ideally be tackled incrementally so
that sub-systems are integrated one at a time. The system is tested as it is
integrated. Interface problems between sub-systems are usually found at this
stage. May be problems with uncoordinated deliveries
of system components.

System delivery and deployment takes place after completion, when the
system has to be installed in the customer's environment. A number of issues can
occur:

• Environmental assumptions may be incorrect;

• May be human resistance to the introduction of a new system;
• System may have to coexist with alternative systems for some time;
• May be physical installation problems (e.g., cabling problems);
• Data cleanup may be required;
• Operator training has to be identified.

System Operation and Evolution

Operational processes are the processes involved in using the system for its
defined purpose. For new systems, these processes may have to be designed and
tested and operators trained in the use of the system. Operational processes
should be flexible to allow operators to cope with problems and periods of
fluctuating workload.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Problems with operation automation:

• It is likely to increase the technical complexity of the system because it has

to be designed to cope with all anticipated failure modes. This increases
the costs and time required to build the system.
• Automated systems are inflexible. People are adaptable and can cope with
problems and unexpected situations. This means that you do not have to
anticipate everything that could possibly go wrong when you are specifying
and designing the system.

Large systems have a long lifetime. They must evolve to meet changing
requirements. Existing systems which must be maintained are sometimes called
legacy systems. Evolution is inherently costly for a number of reasons:

• Changes must be analyzed from a technical and business perspective;

• Sub-systems interact so unanticipated problems can arise;
• There is rarely a rationale for original design decisions;
• System structure is corrupted as changes are made to it.

Factors that affect system lifetimes:

• Investment cost: The costs of a systems engineering project may be tens

or even hundreds of millions of dollars. These costs can only be justified if
the system can deliver value to an organization for many years.
• Loss of expertise: As businesses change and restructure to focus on their
core activities, they often lose engineering expertise. This may mean that
they lack the ability to specify the requirements for a new system.
• Replacement cost: The cost of replacing a large system is very high.
Replacing an existing system can only be justified if this leads to significant
cost savings over the existing system.
• Return on investment: If a fixed budget is available for systems
engineering, spending this on new systems in some other area of the
business may lead to a higher return on investment than replacing an
existing system.
• Risks of change: Systems are an inherent part of business operations and
the risks of replacing existing systems with new systems cannot be
justified. The danger with a new system is that things can go wrong in the
hardware, software and operational processes. The potential costs of these
problems for the business may be so high that they cannot take the risk of
system replacement.
• System dependencies: Other systems may depend on a system and
making changes to these other systems to accommodate a replacement
system may be impractical.

Proposed changes have to be analyzed very carefully from a business and a

technical perspective. Subsystems are never completely independent so changes

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

to a subsystem may have side-effects that adversely affect other subsystems.

Reasons for original design decisions are often unrecorded. Those responsible for
the system evolution have to work out why these decisions were made. As
systems age, their structure becomes corrupted by change so the costs of making
further changes increases.

Real-time Software Engineering

Computers are used to control a wide range of systems from simple domestic
machines, through games controllers, to entire manufacturing plants. Their
software must react to events generated by the hardware and, often, issue control
signals in response to these events. The software in these systems is
embedded in system hardware, often in read-only memory, and usually
responds, in real time, to events from the system's environment.

Responsiveness in real-time is the critical difference between embedded

systems and other software systems, such as information systems, web-based
systems or personal software systems. For non-real-time systems, correctness
can be defined by specifying how system inputs map to corresponding outputs
that should be produced by the system. In a real-time system, the correctness
depends both on the response to an input and the time taken to generate
that response. If the system takes too long to respond, then the required
response may be ineffective.

A real-time system is a software system where the correct functioning of the

system depends on the results produced by the system and the time at which
these results are produced. A soft real-time system is a system whose
operation is degraded if results are not produced according to the specified timing
requirements. A hard real-time system is a system whose operation is incorrect
if results are not produced according to the timing specification.

Characteristics of embedded systems:

• Embedded systems generally run continuously and do not terminate.

• Interactions with the system's environment are unpredictable.
• There may be physical limitations that affect the design of a system.
• Direct hardware interaction may be necessary.
• Issues of safety and reliability may dominate the system design.

Embedded System Design

The design process for embedded systems is a system engineering process that
has to consider, in detail, the design and performance of the system hardware.
Part of the design process may involve deciding which system capabilities are to
be implemented in software and which in hardware. Low-level decisions on
hardware, support software and system timing must be considered early in the

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

process. These may mean that additional software functionality, such as battery
and power management, has to be included in the system.

Real-time systems are often considered to be reactive systems. Given a

stimulus, the system must produce a
reaction or response within a specified time. Stimuli come from sensors in the
systems environment and from actuators controlled by the system.

• Periodic stimuli occur at predictable time intervals. For example, the

system may examine a sensor every 50 milliseconds and take action
(respond) depending on that sensor value (the stimulus).
• Aperiodic stimuli occur irregularly and unpredictably and are may be
signaled using the computer's interrupt mechanism. An example of such a
stimulus would be an interrupt indicating that an I/O transfer was complete
and that data was available in a buffer.

Because of the need to respond to timing demands made by different

stimuli/responses, the system architecture must allow for fast switching
between stimulus handlers. Timing demands of different stimuli are different
so a simple sequential loop is not usually adequate. Real-time systems are
therefore usually designed as cooperating processes with a real-time executive
controlling these processes.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Sensor control processes collect information from sensors. May buffer

information collected in response to a sensor stimulus.
• Data processor carries out processing of collected information and
computes the system response.
• Actuator control processes generate control signals for the actuators.

Processes in a real-time system have to be coordinated and share

information. Process coordination mechanisms ensure mutual exclusion to
shared resources. When one process is modifying a shared resource, other
processes should not be able to change that resource. When designing the
information exchange between processes, you have to take into account the fact
that these processes may be running at different speeds.

Producer processes collect data and add it to the buffer. Consumer processes take
data from the buffer and make elements available. Producer and consumer
processes must be mutually excluded from accessing the same element. The
buffer must stop producer processes adding information to a full buffer and
consumer processes trying to take information from an empty buffer.

The effect of a stimulus in a real-time system may trigger a transition

from one state to another. State models are therefore often used to describe
embedded real-time systems. UML state diagrams may be used to show the
states and state transitions in a real-time system.

Programming languages for real-time systems development have to include

facilities to access system hardware, and it should be possible to predict the
timing of particular operations in these languages. Systems-level languages, such
as C, which allow efficient code to be generated are widely used in preference to
languages such as Java. There is a performance overhead in object-oriented
systems because extra code is required to mediate access to attributes and
handle calls to operations. The loss of performance may make it impossible to
meet real-time deadlines.

Architectural Patterns for Real-time Software

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Characteristic system architectures for embedded systems:

• Observe and React pattern is used when a set of sensors are routinely
monitored and displayed.
• Environmental Control pattern is used when a system includes sensors,
which provide information about the environment and actuators that can
change the environment.
• Process Pipeline pattern is used when data has to be transformed from
one representation to another before it can be processed.

Observe and React pattern description

The input values of a set of sensors of the same types are collected and analyzed.
These values are displayed in some way. If the sensor values indicate that some
exceptional condition has arisen, then actions are initiated to draw the operator's
attention to that value and, in certain cases, to take actions in response to the
exceptional value.

Stimuli - Values from sensors attached to the system.

Responses - Outputs to display, alarm triggers, signals to reacting systems.

Processes - Observer, Analysis, Display, Alarm, Reactor.

Used in - Monitoring systems, alarm systems.

Environmental Control pattern description

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

The system analyzes information from a set of sensors that collect data from the
system's environment. Further information may also be collected on the state of
the actuators that are connected to the system. Based on the data from the
sensors and actuators, control signals are sent to the actuators that then cause
changes to the system's environment. Information about the sensor values and
the state of the actuators may be displayed.

Stimuli - Values from sensors attached to the system and the state of the system
actuators.

Responses - Control signals to actuators, display information.

Processes - Monitor, Control, Display, Actuator Driver, Actuator monitor.

Used in - Control systems.

Process Pipeline pattern description

A pipeline of processes is set up with data moving in sequence from one end of
the pipeline to another. The processes are often linked by synchronized buffers
to allow the producer and consumer processes to run at different speeds. The
culmination of a pipeline may be display or data storage or the pipeline may
terminate in an actuator.

Stimuli - Input values from the environment or some other process

Responses - Output values to the environment or a shared buffer

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Processes - Producer, Buffer, Consumer

Used in - Data acquisition systems, multimedia systems

Timing Analysis

The correctness of a real-time system depends not just on the correctness of its
outputs but also on the time at which these outputs were produced. In a timing
analysis, you calculate how often each process in the system must be executed
to ensure that all inputs are processed and all system responses produced in a
timely way. The results of the timing analysis are used to decide how frequently
each process should execute and how these processes should be scheduled by
the real-time operating system.

Factors in timing analysis:

• Deadlines: the times by which stimuli must be processed and some

response produced by the system.
• Frequency: the number of times per second that a process must execute
so that you are confident that it can always meet its deadlines.
• Execution time: the time required to process a stimulus and produce a
response.

Real-time Operating Systems

Real-time operating systems are specialized operating systems which manage the
processes in the RTS. Responsible for process management and
resource (processor and memory) allocation. May be based on a standard kernel
which
is used unchanged or modified for a particular
application. Do not normally include facilities such as file management.

Real-time operating system components:

• Real-time clock provides information for process scheduling.

• Interrupt handler manages aperiodic requests for service.
• Scheduler chooses the next process to be run.
• Resource manager allocates memory and processor resources.
• Dispatcher starts process execution.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

The scheduler chooses the next process to be executed by the processor. This
depends on a scheduling strategy which may take the process priority into
account. The resource manager allocates memory and a processor for the process
to be executed. The dispatcher takes the process from ready list, loads it onto a
processor and starts execution.

Scheduling strategies:

• Non-pre-emptive scheduling: once a process has been scheduled for

execution, it runs to completion or until it is blocked for some reason (e.g.,
waiting for I/O).
• Pre-emptive scheduling: the execution of an executing processes may
be stopped if a higher priority process requires service.
• Scheduling algorithms include round-robin, rate monotonic, and shortest
deadline first.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

UNIT V SOFTWARE TESTING AND SOFTWARE CONFIGURATION

MANAGEMENT

Neural Networks

A neural network is a method in artificial intelligence that teaches computers to

process data in a way that is inspired by the human brain. It is a type of machine
learning process, called deep learning, that uses interconnected nodes or neurons
in a layered structure that resembles the human brain. It creates an adaptive
system that computers use to learn from their mistakes and improve
continuously. Thus, artificial neural networks attempt to solve complicated
problems, like summarizing documents or recognizing faces, with greater
accuracy.

Why are neural networks important?

Neural networks can help computers make intelligent decisions with limited
human assistance. This is because they can learn and model the relationships
between input and output data that are nonlinear and complex. For instance, they
can do the following tasks.

Make generalizations and inferences

Neural networks can comprehend unstructured data and make general

observations without explicit training. For instance, they can recognize that two
different input sentences have a similar meaning:

• Can you tell me how to make the payment?

• How do I transfer money?

A neural network would know that both sentences mean the same thing. Or it
would be able to broadly recognize that Baxter Road is a place, but Baxter Smith
is a person’s name.

What are neural networks used for?

Neural networks have several use cases across many industries, such as the
following:

• Medical diagnosis by medical image classification

• Targeted marketing by social network filtering and behavioral data analysis
• Financial predictions by processing historical data of financial instruments
• Electrical load and energy demand forecasting
• Process and quality control
• Chemical compound identification

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

We give four of the important applications of neural networks below.

Computer vision

Computer vision is the ability of computers to extract information and insights

from images and videos. With neural networks, computers can distinguish and
recognize images similar to humans. Computer vision has several applications,
such as the following:

• Visual recognition in self-driving cars so they can recognize road signs and
other road users
• Content moderation to automatically remove unsafe or inappropriate
content from image and video archives
• Facial recognition to identify faces and recognize attributes like open eyes,
glasses, and facial hair
• Image labeling to identify brand logos, clothing, safety gear, and other
image details

Speech recognition

Neural networks can analyze human speech despite varying speech patterns,
pitch, tone, language, and accent. Virtual assistants like Amazon Alexa and
automatic transcription software use speech recognition to do tasks like these:

• Assist call center agents and automatically classify calls

• Convert clinical conversations into documentation in real time
• Accurately subtitle videos and meeting recordings for wider content reach

Natural language processing

Natural language processing (NLP) is the ability to process natural, human-

created text. Neural networks help computers gather insights and meaning from
text data and documents. NLP has several use cases, including in these functions:

• Automated virtual agents and chatbots

• Automatic organization and classification of written data
• Business intelligence analysis of long-form documents like emails and
forms
• Indexing of key phrases that indicate sentiment, like positive and negative
comments on social media
• Document summarization and article generation for a given topic

Recommendation engines

Neural networks can track user activity to develop personalized

recommendations. They can also analyze all user behavior and discover new

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

products or services that interest a specific user. For example, Curalate, a

Philadelphia-based startup, helps brands convert social media posts into sales.
Brands use Curalate’s intelligent product tagging (IPT) service to automate the
collection and curation of user-generated social content. IPT uses neural networks
to automatically find and recommend products relevant to the user’s social media
activity. Consumers don't have to hunt through online catalogs to find a specific
product from a social media image. Instead, they can use Curalate’s auto product
tagging to purchase the product with ease.

How do neural networks work?

The human brain is the inspiration behind neural network architecture. Human
brain cells, called neurons, form a complex, highly interconnected network and
send electrical signals to each other to help humans process information.
Similarly, an artificial neural network is made of artificial neurons that work
together to solve a problem. Artificial neurons are software modules, called
nodes, and artificial neural networks are software programs or algorithms that,
at their core, use computing systems to solve mathematical calculations.

Simple neural network architecture

A basic neural network has interconnected artificial neurons in three layers:

Input Layer

Information from the outside world enters the artificial neural network from the
input layer. Input nodes process the data, analyze or categorize it, and pass it on
to the next layer.

Hidden Layer

Hidden layers take their input from the input layer or other hidden layers. Artificial
neural networks can have a large number of hidden layers. Each hidden layer
analyzes the output from the previous layer, processes it further, and passes it
on to the next layer.

Output Layer

The output layer gives the final result of all the data processing by the artificial
neural network. It can have single or multiple nodes. For instance, if we have a
binary (yes/no) classification problem, the output layer will have one output node,
which will give the result as 1 or 0. However, if we have a multi-class classification
problem, the output layer might consist of more than one output node.

Deep neural network architecture

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Deep neural networks, or deep learning networks, have several hidden layers
with millions of artificial neurons linked together. A number, called weight,
represents the connections between one node and another. The weight is a
positive number if one node excites another, or negative if one node suppresses
the other. Nodes with higher weight values have more influence on the other
nodes.
Theoretically, deep neural networks can map any input type to any output type.
However, they also need much more training as compared to other machine
learning methods. They need millions of examples of training data rather than
perhaps the hundreds or thousands that a simpler network might need.

What are the types of neural networks?

Artificial neural networks can be categorized by how the data flows from the input
node to the output node. Below are some examples:

Feedforward neural networks

Feedforward neural networks process data in one direction, from the input node
to the output node. Every node in one layer is connected to every node in the
next layer. A feedforward network uses a feedback process to improve predictions
over time.

Backpropagation algorithm

Artificial neural networks learn continuously by using corrective feedback loops

to improve their predictive analytics. In simple terms, you can think of the data
flowing from the input node to the output node through many different paths in
the neural network. Only one path is the correct one that maps the input node to
the correct output node. To find this path, the neural network uses a feedback
loop, which works as follows:

1. Each node makes a guess about the next node in the path.
2. It checks if the guess was correct. Nodes assign higher weight values to
paths that lead to more correct guesses and lower weight values to node
paths that lead to incorrect guesses.
3. For the next data point, the nodes make a new prediction using the higher
weight paths and then repeat Step 1.

Convolutional neural networks

The hidden layers in convolutional neural networks perform specific mathematical

functions, like summarizing or filtering, called convolutions. They are very useful
for image classification because they can extract relevant features from images
that are useful for image recognition and classification. The new form is easier to
process without losing features that are critical for making a good prediction. Each

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

hidden layer extracts and processes different image features, like edges, color,
and depth.

Biological Motivation

Motivation behind neural network is human brain. Human brain is called as the
best processor even though it works slower than other computers. Many
researchers thought to make a machine that would work in the prospective of the
human brain.

Human brain contains billion of neurons which are connected to many other
neurons to form a network so that if it sees any image, it recognizes the image
and processes the output.

• Dendrite receives signals from other neurons.

• Cell body sums the incoming signals to generate input.
• When the sum reaches a threshold value, neuron fires and the signal travels
down the axon to the other neurons.
• The amount of signal transmitted depend upon the strength of the
connections.
• Connections can be inhibitory, i.e., decreasing strength or excitatory, i.e.,
increasing strength in nature.

In the similar manner, it was thought to make artificial interconnected neurons

like biological neurons making up an Artificial Neural Network (ANN). Each
biological neuron is capable of taking a number of inputs and produce output.
Neurons in human brain are capable of making very complex decisions, so this
means they run many parallel processes for a particular task. One motivation for
ANN is that to work for a particular task identification through many parallel
processes.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Perceptron

The Perceptron - Simple Model of Neural Networks

The Perceptron is a linear model used for binary classification. The

perceptron is more widely known as a “single-layer perceptron” in neural network
research to distinguish it from its successor the “multilayer perceptron.” As a
basic linear classifier, we consider the single-layer perceptron to be the simplest
form of the family of feed-forward neural networks.

Definition of the Perceptron

The perceptron is a linear-model binary classifier with a simple input–

output relationship as depicted in Figure 2-3, which shows we’re summing n
number of inputs times their associated weights and then sending this “net input”
to a step function with a defined threshold. Typically, with perceptron, this is a
Heaviside step function with a threshold value of 0.5. This function will output a
real valued single binary value (0 or a 1), depending on the input.

We can model the decision boundary and the classification output in the Heaviside
step function equation, as follows:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

To produce the net input to the activation function (here, the Heaviside step
function) we take the dot product of the input and the connection weights. We
see this summation in the left half of Figure 2-3 as the input to the summation
function.

Table 2-1 provides an explanation of how the summation function is performed

as well as notes about the parameters involved in the summation function. The
output of the step function (activation function) is the output for the perceptron
and gives us a classification of the input values.

If the bias value is negative, it forces the learned weights sum to be a much
greater value to get a 1 classification output. The bias term in this capacity moves
the decision boundary around for the model. Input values do not affect the bias
term, but the bias term is learned through the perceptron learning algorithm.

History of the Perceptron

The perceptron was invented in 1957 at the Cornell Aeronautical

Laboratory by Frank Rosenblatt. Early versions were intended to be implemented
as a physical machine rather than a software program. The first software
implementation was for the IBM 704, and then later it was implemented in the
Mark I Perceptron machine. It also should be noted that McCulloch and Pitts
introduced the basic concept of analysing neural activity in 1943 based on
thresholds and weighted sums. These concepts were key in developing a model
for later variations like the perceptron.

Multi-layer Perceptron

It is mainly similar to a single-layer perceptron model but has more hidden layers.
In a multilayer perceptron’s a group of neurons will be organized in multiple
layers. Every single neuron present in the first layer will take the input signal and
send a response to the neurons in the second layer and so on. A multilayer
perceptron model has a greater processing power and can process linear and non-
linear patterns.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Forward Stage: From the input layer in the on stage, activation functions begin
and terminate on the output layer.

• Backward Stage: In the backward stage, weight and bias values are modified
per the model’s requirement. The backstage removed the error between the
actual output and demands originating backward on the output layer.

Primary Components of a Perceptron

1. Neurons - A neural network is made up of a collection of units or

nodes which are called neurons.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

2. Synapse - The getting neuron can obtain the sign, process the same,
and sign the subsequent one. A neuron can send information or
signals through the synapse to another adjacent neuron. It processes
it and signals the subsequent one. This process in the perceptron
algorithm continues until an output signal is generated.
3. Input Nodes or Input Layer - This is the primary component of
Perceptron which accepts the initial data into the system for further
processing. Each input node contains a real numerical value. All the
Features of the model we want to train the neural network are taken
as inputs in the perceptron algorithm. Inputs are denoted as x1, x2,
x3, x4, … xn – ‘x’ in these inputs indicates the feature value and ‘n’
the total occurrences of these features.
4. Weight - Weight parameter represents the strength of the
connection between units. This is another most important parameter
of Perceptron components. These are values that are calculated
during the training of the model. Initially, we have to pass some
random values as values to the weights and these values get
automatically updated after each training error that is the values are
generated during the training of the model. In some cases, weights
can also be called as weight coefficients that occurs during hidden
layers which is donated w1, w2, w3, w4, ... wn. Weight is directly
proportional to the strength of the associated input neuron in deciding
the output.
5. Bias – Bias is a special input type which allows the classifier to move
the decision boundary around from its original position. The objective
of the bias is to shift each point in a particular direction for a specified
distance. Bias allows for higher quality and faster model training.

If you notice, we have passed value one as input in the starting and
W0 in the weights section. Bias is an element that adjusts the boundary away
from origin to move the activation function left, right, up or down. Since we want
this to be independent of the input features, we add constant one in the statement
so that the features will not get affected by this and this value is known as Bias.

6. Weighted Summation - The multiplication of every feature or input

value (xi) associated with corresponding weight values (wi) gives us
a sum of values that are called weighted summation. This weighted
sum is passed on to the so-called activation function

Weights sum = ∑Wi * Xi (from i=1 to i=n) + (W0 * 1)

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

7. Activation/Step Function – Activation function applies step rule

which converts the numerical value to 0 or 1 so that it will be easy
for data set to classify. This is a process of reaching to result or
outcome that help to determine whether the neuron will fire or not.

Activation Function can be considered primarily as a step function.

Types of Activation functions:

• Sign function

• Step function, and

• Sigmoid function

Based on the type of value we need as output we can change the activation
function. We can use the step function depending on the value required. Sigmoid
function and sign functions can be used for values between 0 and 1 and 1 and -
1, respectively. The sign function is a hyperbolic tangent function which is a zero
centered function making it easy the multi-layer neural networks. Rectified Linear
Unit (ReLu) is another step function that is highly computational and can be used
for values approaching zero – value more less than or more than zero.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

The data scientist uses the activation function to take a subjective decision based
on various problem statements and forms the desired outputs. Activation function
may differ (e.g., Sign, Step, and Sigmoid) in perceptron models by checking
whether the learning process is slow or has vanishing or exploding gradients.

Feed Forward Network

A Feed Forward Neural Network is an artificial Neural Network in which

the nodes are connected circularly. A feed-forward neural network, in which
some routes are cycled, is the polar opposite of a Recurrent Neural Network. The
feed-forward model is the basic type of neural network because the input is only
processed in one direction. The data always flows in one direction and never
backwards/opposite.

In its most basic form, a Feed-Forward Neural Network is a single layer

perceptron. A sequence of inputs enters the layer and are multiplied by
the weights in this model. The weighted input values are then summed
together to form a total. If the sum of the values is more than a predetermined
threshold, which is normally set at zero, the output value is usually 1, and if the
sum is less than the threshold, the output value is usually -1. The single-layer
perceptron is a popular feed-forward neural network model that is frequently used
for classification. Single-layer perceptron can also contain machine learning
features.

The neural network can compare the outputs of its nodes with the
desired values using a property known as the delta rule, allowing the
network to alter its weights through training to create more accurate

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

output values. This training and learning procedure results in gradient descent.
The technique of updating weights in multi-layered perceptron is virtually the
same, however, the process is referred to as back-propagation. In such
circumstances, the output values provided by the final layer are used to alter each
hidden layer inside the network.

Backpropagation

Backpropagation is the essence of neural network training. It is the method of

fine-tuning the weights of a neural network based on the error rate obtained in
the previous epoch (i.e., iteration). Proper tuning of the weights allows you to
reduce error rates and make the model reliable by increasing its generalization.

Backpropagation in neural network is a short form for “backward propagation of

errors.” It is a standard method of training artificial neural networks. This method
helps calculate the gradient of a loss function with respect to all the weights in
the network.

How Backpropagation Algorithm Works

The Back propagation algorithm in neural network computes the gradient of the
loss function for a single weight by the chain rule. It efficiently computes one
layer at a time, unlike a native direct computation. It computes the gradient, but
it does not define how the gradient is used. It generalizes the computation in the
delta rule.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Consider the above Back propagation neural network example diagram to

understand:

1. Inputs X, arrive through the preconnected path

2. Input is modeled using real weights W. The weights are usually randomly
selected.
3. Calculate the output for every neuron from the input layer, to the hidden
layers, to the output layer.
4. Calculate the error in the outputs

ErrorB= Actual Output – Desired Output

5. Travel back from the output layer to the hidden layer to adjust the weights
such that the error is decreased.

Keep repeating the process until the desired output is achieved.

Why We Need Backpropagation?

Most prominent advantages of Backpropagation are:

• Backpropagation is fast, simple and easy to program

• It has no parameters to tune apart from the numbers of input
• It is a flexible method as it does not require prior knowledge about the
network
• It is a standard method that generally works well
• It does not need any special mention of the features of the function to be
learned.

Activation and Loss Functions

Activation Function

The activation function of a neuron defines its output given its inputs. The
activation function activates the neuron that is required for the desired output,
converts linear input to non-linear output. In neural networks, activation
functions, also known as transfer functions, define how the weighted sum of the
input can be transformed into output via nodes in a layer of networks. They are
treated as a crucial part of neural networks’ design.

In hidden layers, the selection of activation function controls how perfectly a

network model works to learn the training dataset while in the output layer, it
determines the types of predictions a model can generate.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

1. Sigmoid Function:

Description: Takes a real-valued number and scales it between 0 and 1. Large

negative numbers become 0 and large positive numbers become 1. Range: (0,1)

Pros: As its range is between 0 and 1, it is ideal for situations where we need to
predict the probability of an event as an output.

Cons: The gradient values are significant for range -3 and 3 but become much
closer to zero beyond this range which almost kills the impact of the neuron on
the final output. Also, sigmoid outputs are not zero-centered (it is centred around
0.5) which leads to undesirable zig-zagging dynamics in the gradient updates for
the weights

Plot:

2. Tanh Function:

Description: Similar to sigmoid but takes a real-valued number and scales it

between -1 and 1. It is better than sigmoid as it is centred around 0 which leads
to better convergence. Range: (-1,1)

Pros: The derivatives of the tanh are larger than the derivatives of the sigmoid
which help us minimize the cost function faster

Cons: Similar to sigmoid, the gradient values become close to zero for wide range
of values (this is known as vanishing gradient problem). Thus, the network
refuses to learn or keeps learning at a very small rate.

Plot:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

3. Softmax Function:

Description: Softmax function can be imagined as a combination of multiple

sigmoids which can returns the probability for a datapoint belonging to each
individual class in a multiclass classification problem. Range: (0,1), sum of output
=1

Pros: Can handle multiple classes and give the probability of belonging to each
class

Cons: Should not be used in hidden layers as we want the neurons to be

independent. If we apply it then they will be linearly dependent.

4. ReLU Function:

Description: The rectified linear activation function or ReLU for short is a piecewise
linear function that will output the input directly if it is positive, otherwise, it will
output zero. This is the default function but modifying default parameters allows
us to use non-zero thresholds and to use a non-zero multiple of the input for
values below the threshold (called Leaky ReLU). Range: (0,inf)

Pros: Although RELU looks and acts like a linear function, it is a nonlinear function
allowing complex relationships to be learned and is able to allow learning through
all the hidden layers in a deep network by having large derivatives.

Cons: It should not be used as the final output layer for either
classification/regression tasks

Plot:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Loss Functions

The other key aspect in setting up the neural network infrastructure is selecting
the right loss functions. With neural networks, we seek to minimize the error
(difference between actual and predicted value) which is calculated by the loss
function.

1. Mean Squared Error, L2 Loss

Description: MSE loss is used for regression tasks. As the name suggests, this
loss is calculated by taking the mean of squared differences between
actual(target) and predicted values. Range: (0, inf)

Formula:

Pros: Preferred loss function if the distribution of the target variable is Gaussian
as it has good derivatives and helps the model converge quickly

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Cons: Is not robust to outliers in the data (unlike loss functions like Mean Absolute
Error) and penalizes high and low predictions exponentially (unlike loss functions
like Mean Squared Logarithmic Error Loss)

2. Binary Cross Entropy

Description: BCE loss is the default loss function used for the binary classification
tasks. It requires one output layer to classify the data into two classes and the
range of output is (0–1) i.e. should use the sigmoid function. Range: (0, inf)

Formula:

where y is the actual label, ŷ is the classifier’s predicted probability distributions

for predicting one class and m is the number of records.

Pros: The continuous nature of the loss function helps the training process
converged well

Cons: Can only be used with sigmoid activation function. Other loss functions like
Hinge or Squared Hinge Loss can work with tanh activation function

3. Categorical Cross Entropy

Description: It is the default loss function when we have a multi-class

classification task. It requires the same number of output nodes as the classes
with the final layer going through a SoftMax activation so that each output node
has a probability value between (0–1). Range: (0, inf)

Formula:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

where y is the actual label and p is the classifier’s predicted probability

distributions for predicting the class j

Pros: Similar to Binary Cross Entropy, the continuous nature of the loss function
helps the training process converged well

Cons: May require a one hot encoded vector with many zero values if there many
classes, requiring significant memory (should use Sparse Categorical Cross
entropy in this case)

Limitations of the Machine Learning

Nothing is perfect in the world. Machine Learning has some serious limitations,
which are bigger than human errors.

1. Data Acquisition

The whole concept of machine learning is about identifying useful data. The
outcome will be incorrect if a credible data source is not provided. The quality of
the data is also significant. If the user or institution needs more quality data, wait
for it. It will cause delays in providing the output. So, machine learning
significantly depends on the data and its quality.

2. Time and Resources

The data that machines process remains huge in quantity and differs greatly.
Machines require time so that their algorithm can adjust to the environment and
learn it. Trials runs are held to check the accuracy and reliability of the machine.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

It requires massive and expensive resources and high-quality expertise to set up

that quality of infrastructure. Trials runs are costly as they would cost in terms of
time and expenses.

3. Results Interpretations

One of the biggest advantages of Machine learning is that interpreted data that
we get from the cannot be hundred percent accurate. It will have some degree of
inaccuracy. For a high degree of accuracy, algorithms should be developed so that
they give reliable results.

4. High Error Chances

The error committed during the initial stages is huge, and if not corrected at that
time, it creates havoc. Biasness and wrongness have to be dealt with separately;
they are not interconnected. Machine learning depends on two factors, i.e., data
and algorithm. All the errors are dependent on the two variables. Any
incorrectness in any variables would have huge repercussions on the output.

5. Social Changes

Machine learning is bringing numerous social changes in society. The role of

machine learning-based technology in society has increased multifold. It is
influencing the thought process of society and creating unwanted problems in
society. Character assassination and sensitive details are disturbing the social
fabric of society.

6. Elimination of Human Interface

Automation, Artificial Intelligence, and Machine Learning have eliminated human

interface from some work. It has eliminated employment opportunities. Now, all
those works are conducted with the help of artificial intelligence and machine
learning.

7. Changing Nature of Jobs

With the advancement of machine learning, the nature of the job is changing.
Now, all the work are done by machine, and it is eating up the jobs for human
which were done earlier by them. It is difficult for those without technical
education to adjust to these changes.

8. Highly Expensive

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

This software is highly expensive, and not everybody can own it. Government
agencies, big private firms, and enterprises mostly own it. It needs to be made
accessible to everybody for wide use.

9. Privacy Concern

As we know that one of the pillars of machine learning is data. The collection of
data has raised the fundamental question of privacy. The way data is collected
and used for commercial purposes has always been a contentious issue. In
India, the Supreme court of India has declared privacy a fundamental right of
Indians. Without the user's permission, data cannot be collected, used, or stored.
However, many cases have come up that big firms collect the data without the
user's knowledge and using it for their commercial gains.

10. Research and Innovations

Machine learning is evolving concept. This area has not seen any major
developments yet that fully revolutionized any economic sector. The area requires
continuous research and innovation.

Deep Learning

What is Deep Learning (DL)?

Deep learning is a specific subfield of machine learning: a new take on learning

representations from data that puts an emphasis on learning successive layers of
increasingly meaningful representations. Other appropriate names for the field
could have been layered representations learning and hierarchical representations
learning.

"Deep" in Deep Learning

The deep in deep learning isn’t a reference to any kind of deeper understanding
achieved by the approach; rather, it stands for this idea of successive layers of
representations.

Depth of the model - How many layers contribute to a model of the data is
called the depth of the model.

No. of layers

Modern deep learning often involves tens or even hundreds of successive layers
of representations— and they’re all learned automatically from exposure to

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

training data. Meanwhile, other approaches to machine learning tend to focus on

learning only one or two layers of representations of the data; hence, they’re
sometimes called shallow learning.

How layers learn?

In deep learning, these layered representations are (almost always) learned via
models called neural networks, structured in literal layers stacked on top of each
other. The term neural network is a reference to neurobiology, but although some
of the central concepts in deep learning were developed in part by drawing
inspiration from our understanding of the brain, deep-learning models are not
models of the brain. There’s no evidence that the brain implements anything like
the learning mechanisms used in modern deep-learning models. For our
purposes, deep learning is a mathematical framework for learning representations
from data.

Working of Neural networks with Example - Digit Classification

What do the representations learned by a deep-learning algorithm look like? Let’s

examine how a network several layers deep (see figure 1.5) transform an image
of a digit in order to recognize what digit it is.

As you can see in figure 1.6, the network transforms the digit image into
representations that are increasingly different from the original image and
increasingly informative about the final result.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

A deep network as a multistage information-distillation operation, where

information goes through successive filters and comes out increasingly purified
(that is, useful with regard to some task). So that’s what deep learning is,
technically: a multistage way to learn data representations.

How this learning happens?

Machine learning is about mapping inputs (such as images) to targets

(such as the label “cat”), which is done by observing many examples of input and
targets. Deep neural networks do this input-to-target mapping via a deep
sequence of simple data transformations (layers) and that these data
transformations are learned by exposure to examples.

Weights AKA Parameters

The specification of what a layer does to its input data is stored in the layer’s
weights, which in essence are a bunch of numbers. In technical terms, we’d say
that the transformation implemented by a layer is parameterized by its weights
(see figure 1.7). (Weights are also sometimes called the parameters of a layer.)

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

In this context, learning means finding a set of values for the weights of all layers
in a network, such that the network will correctly map example inputs to their
associated targets. But here’s the thing: a deep neural network can contain tens
of millions of parameters. Finding the correct value for all of them may seem like
a daunting task, especially given that modifying the value of one parameter will
affect the behaviour of all the others!

Loss function AKA Objective function

To control something, first you need to be able to observe it. To control the output
of a neural network, you need to be able to measure how far this output is from
what you expected. This is the job of the loss function of the network, also called
the objective function. The loss function takes the predictions of the network and
the true target (what you wanted the network to output) and computes a distance
score, capturing how well the network has done on this specific example (see
figure 1.8).

Optimizer

The fundamental trick in deep learning is to use this score as a feedback signal
to adjust the value of the weights a little, in a direction that will lower the loss
score for the current example (see figure 1.9). This adjustment is the job of the
optimizer, which implements what’s called the Backpropagation algorithm: the
central algorithm in deep learning.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Trained Network

Initially, the weights of the network are assigned random values, so the network
merely implements a series of random transformations. Naturally, its output is far
from what it should ideally be, and the loss score is accordingly very high. But
with every example the network processes, the weights are adjusted a little in
the correct direction, and the loss score decreases. This is the training loop,
which, repeated a sufficient number of times (typically tens of iterations over
thousands of examples), yields weight values that minimize the loss function. A
network with a minimal loss is one for which the outputs are as close as they can
be to the targets: a trained network.

DL achieved so far?

Although deep learning is a fairly old subfield of machine learning, it

only rose to prominence in the early 2010s. In the few years since, it has achieved
nothing short of a revolution in the field, with remarkable results on perceptual
problems such as seeing and hearing—problems involving skills that seem natural
and intuitive to humans but have long been elusive for machines.

In particular, deep learning has achieved the following breakthroughs,

all in historically difficult areas of machine learning:

✓ Near-human-level image classification

✓ Near-human-level speech recognition
✓ Near-human-level handwriting transcription
✓ Improved machine translation
✓ Improved text-to-speech conversion
✓ Digital assistants such as Google Now and Amazon Alexa
✓ Near-human-level autonomous driving

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

✓ Improved ad targeting, as used by Google, Baidu, and Bing

✓ Improved search results on the web
✓ Ability to answer natural-language questions
✓ Superhuman Go playing

Convolution Neural Networks

Definition of CNN

Convolutional neural networks also known as CNN or ConvNet are a specialized

type of artificial neural networks that use a mathematical operation called
convolution in place of general matrix multiplication in at least one of their layers.

They are specifically designed to process pixel data and are used in image
recognition and processing. CNN specializes in processing data that has a grid-
like topology, such as an image. A digital image is a binary representation of
visual data. It contains a series of pixels arranged in a grid-like fashion that
contains pixel values to denote how bright and what color each pixel should be.

Convolutional Neural Network (CNN) is the extended version of artificial neural

networks (ANN) which is predominantly used to extract the feature from the grid-
like matrix dataset. For example, visual datasets like images or videos where data
patterns play an extensive role.

CNN architecture

Convolutional Neural Network consists of multiple layers like the input layer,
Convolutional layer, Pooling layer, and fully connected layers.

Simple CNN architecture

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

The Convolutional layer applies filters to the input image to extract features, the
Pooling layer down samples the image to reduce computation, and the fully
connected layer makes the final prediction. The network learns the optimal filters
through backpropagation and gradient descent.

How Convolutional Layers works?

Convolution Neural Networks or covnets are neural networks that share their
parameters. Imagine you have an image. It can be represented as a cuboid
having its length, width (dimension of the image), and height (i.e the channel as
images generally has red, green, and blue channels).

Now imagine taking a small patch of this image and running a small neural
network, called a filter or kernel on it, with say, K outputs and representing them
vertically. Now slide that neural network across the whole image, as a result, we
will get another image with different widths, heights, and depths. Instead of just
R, G, and B channels now we have more channels but lesser width and height.
This operation is called Convolution. If the patch size is the same as that of the
image it will be a regular neural network. Because of this small patch, we have
fewer weights.

Now let’s talk about a bit of mathematics that is involved in the whole convolution
process.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Convolution layers consist of a set of learnable filters (or kernels) having

small widths and heights and the same depth as that of input volume (3 if
the input layer is image input).
• For example, if we have to run convolution on an image with dimensions
34x34x3. The possible size of filters can be axax3, where ‘a’ can be
anything like 3, 5, or 7 but smaller as compared to the image dimension.
• During the forward pass, we slide each filter across the whole input volume
step by step where each step is called stride (which can have a value of 2,
3, or even 4 for high-dimensional images) and compute the dot product
between the kernel weights and patch from input volume.
• As we slide our filters, we’ll get a 2-D output for each filter and we’ll stack
them together as a result, we’ll get output volume having a depth equal to
the number of filters. The network will learn all the filters.

Layers used to build ConvNets

A complete Convolution Neural Networks architecture is also known as covnets.

A covnets is a sequence of layers, and every layer transforms one volume to
another through a differentiable function.

Types of layers: datasets

Let’s take an example by running a covnets on of image of dimension 32 x 32 x

3

• Input Layers: It’s the layer in which we give input to our model. In CNN,
Generally, the input will be an image or a sequence of images. This layer
holds the raw input of the image with width 32, height 32, and depth 3.
• Convolutional Layers: This is the layer, which is used to extract the
feature from the input dataset. It applies a set of learnable filters known as
the kernels to the input images. The filters/kernels are smaller matrices
usually 2×2, 3×3, or 5×5 shape. it slides over the input image data and
computes the dot product between kernel weight and the corresponding
input image patch. The output of this layer is referred ad feature maps.
Suppose we use a total of 12 filters for this layer we’ll get an output volume
of dimension 32 x 32 x 12.
• Activation Layer: By adding an activation function to the output of the
preceding layer, activation layers add nonlinearity to the network. it will
apply an element-wise activation function to the output of the convolution
layer. Some common activation functions are RELU: max(0,
x), Tanh, Leaky RELU, etc. The volume remains unchanged hence output
volume will have dimensions 32 x 32 x 12.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

• Pooling layer: This layer is periodically inserted in the covnets and its
main function is to reduce the size of volume which makes the computation
fast reduces memory and also prevents overfitting. Two common types of
pooling layers are max pooling and average pooling. If we use a max
pool with 2 x 2 filters and stride 2, the resultant volume will be of dimension
16x16x12.

• Flattening: The resulting feature maps are flattened into a one-

dimensional vector after the convolution and pooling layers so they can be
passed into a completely linked layer for categorization or regression.
• Fully Connected Layers: It takes the input from the previous layer and
computes the final classification or regression task.

• Output Layer: The output from the fully connected layers is then fed into
a logistic function for classification tasks like sigmoid or SoftMax which
converts the output of each class into the probability score of each class.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

Recurrent Neural Networks

Recurrent Neural Network (RNN) is a type of Neural Network where the output
from the previous step is fed as input to the current step. In traditional neural
networks, all the inputs and outputs are independent of each other, but in cases
when it is required to predict the next word of a sentence, the previous words are
required and hence there is a need to remember the previous words. Thus, RNN
came into existence, which solved this issue with the help of a Hidden Layer. The
main and most important feature of RNN is its Hidden state, which remembers
some information about a sequence. The state is also referred to as Memory State
since it remembers the previous input to the network. It uses the same
parameters for each input as it performs the same task on all the inputs or hidden
layers to produce the output. This reduces the complexity of parameters, unlike
other neural networks.

The Recurrent Neural Network consists of multiple fixed activation function units,
one for each time step. Each unit has an internal state which is called the hidden
state of the unit. This hidden state signifies the past knowledge that the network
currently holds at a given time step. This hidden state is updated at every time
step to signify the change in the knowledge of the network about the past. The
hidden state is updated using the following recurrence relation: -

The formula for calculating the current state:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

where:

ht -> current state

ht-1 -> previous state

xt -> input state

Formula for applying Activation function(tanh):

where:

whh -> weight at recurrent neuron

wxh -> weight at input neuron

The formula for calculating output:

Yt -> output

Why -> weight at output layer

These parameters are updated using Backpropagation. However, since RNN works
on sequential data here we use an updated backpropagation which is known as
Backpropagation through time.

Training through RNN

1. A single-time step of the input is provided to the network.

2. Then calculate its current state using a set of current input and the previous
state.
3. The current ht becomes ht-1 for the next time step.

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

4. One can go as many time steps according to the problem and join the
information from all the previous states.
5. Once all the time steps are completed the final current state is used to
calculate the output.
6. The output is then compared to the actual output i.e the target output and
the error is generated.
7. The error is then back-propagated to the network to update the weights
and hence the network (RNN) is trained using Backpropagation through
time.

Advantages of Recurrent Neural Network

1. An RNN remembers each and every piece of information through time. It is

useful in time series prediction only because of the feature to remember
previous inputs as well. This is called Long Short Term Memory.
2. Recurrent neural networks are even used with convolutional layers to
extend the effective pixel neighborhood.

Disadvantages of Recurrent Neural Network

1. Gradient vanishing and exploding problems.

2. Training an RNN is a very difficult task.
3. It cannot process very long sequences if using tanh or relu as an activation
function.

Applications of Recurrent Neural Network

1. Language Modelling and Generating Text

2. Speech Recognition
3. Machine Translation
4. Image Recognition, Face detection
5. Time series Forecasting

Variation Of Recurrent Neural Network (RNN)

To overcome the problems like vanishing gradient and exploding gradient descent
several new advanced versions of RNNs are formed some of these areas ;

o Bidirectional Neural Network (BiNN)

o Long Short-Term Memory (LSTM)

Bidirectional Neural Network (BiNN)

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

A BiNN is a variation of a Recurrent Neural Network in which the input information

flows in both direction and then the output of both directions are combined to
produce the input. BiNN is useful in situations when the context of the input is
more important such as Nlp tasks and Time-series analysis problems.

Long Short-Term Memory (LSTM)

Long Short-Term Memory works on the read-write-and-forget principle where

given the input information network reads and writes the most useful information
from the data and it forgets about the information which is not important in
predicting the output. For doing these three new gates are introduced in the RNN.
In this way, only the selected information is passed through the network.

Use Cases

1. Machine Translation:

RNN can be used to build a deep learning model that can translate text from one
language to another without the need for human intervention. You can, for
example, translate a text from your native language to English.

2. Text Creation:

Downloaded by Karthick M ([email protected])

 lOMoARcPSD|43637711

RNNs can also be used to build a deep learning model for text generation. Based
on the previous sequence of words/characters used in the text, a trained model
learns the likelihood of occurrence of a word/character. A model can be trained
at the character, n-gram, sentence, or paragraph level.

3. Captioning of images:

The process of creating text that describes the content of an image is known as
image captioning. The image's content can depict the object as well as the action
of the object on the image. In the image below, for example, the trained deep
learning model using RNN can describe the image as "A lady in a green coat is
reading a book under a tree.”

4. Recognition of Speech:

This is also known as Automatic Speech Recognition (ASR), and it is capable of

converting human speech into written or text format. Don't mix up speech
recognition and voice recognition; speech recognition primarily focuses on
converting voice data into text, whereas voice recognition identifies the user's
voice.

Speech recognition technologies that are used on a daily basis by various users
include Alexa, Cortana, Google Assistant, and Siri.

5. Forecasting of Time Series:

After being trained on historical time-stamped data, an RNN can be used to create
a time series prediction model that predicts the future outcome. The stock market
is a good example.

You can use stock market data to build a machine learning model that can forecast
future stock prices based on what the model learns from historical data. This can
assist investors in making data-driven investment decisions.

Downloaded by Karthick M ([email protected])