Institute of Engineering & Technology

Bundelkhand University, Jhansi

Lab Report
Of

Software Engineering Lab

Submitted to Department of Computer Science & Engineering

Session 2019-2020

Submitted To: Submitted By:

Er. Akhilesh sir Tanisha Trivedi
Professor 181381030051

I.E.T.,B.U.,Jhansi I.E.T.,B.U.,Jhansi
 CONTENTS

S.No Practical Name Page No.

01 To study about Software Characteristics. 3
02 To study about various kinds of software applications. 6
03 Explains various Software myths. 8
04 To study about various kinds of risks 11
05 To study about Risk Assessment 13
06 To study about Risk mitigation(RMMM) 16
07 To study about requirement specification 20
08 To study about Requirement Engineering 23
09 To study about System Modeling 26
10 To study about architecture of analysis 30
11 To study about Software Design. 33
12 To study about various kinds of testing techniques. 37
13 To study about object oriented analysis and design. 43
 Practical -01
AIM:-
To study about software characteristics.
THEORY:-
Functionality: It refers to the degree of performance of the
software against its intended purpose. It basically means are
the required functions.

Reliability:A set of attribute that Bear on the capability of

software to maintain its level of performances understated
conditions for a stated period of time.

Efficiency: It refers to the ability of the software to use

System Resources in the most Effective and Efficient Manner.
The software should make effective use of storage space and
executive commands as per desired timing requirement.

Usability: It refers to the extent to which the software can

be used with ease. Or the amount of effort or time required
to learn how to use the software should be less.

Maintainability: Refers to the ease with which the

modifications can be made in a software system to extend its
functionality, improvement, performance or correct errors.

Portability: A set of attributes that bears on the ability of

the software to be transferred from one environment to
 another, without or minimum changes.

Robustness and integrity are also important:

Robustness: It refers to the degree to which the software

can keep on functioning in spite of being provided with
invalid data.

Integrity: It refers to the degree to which Unauthorized

Access to the software data can be prevented.

RESULT
Various types of software characteristics are studied.
 Practical – 02
AIM:-
To study about the various kinds of application of various software.

THEORY:-
There are various kind of softwares and each have their own uses.But mainly
there are 3 categories which is further subcategories.

1.SYSTEM SOFTWARE
System software is a type of computer program that is designed to run a
computer’s hardware and application programs. If we think of the computer
system as a layered model, the system software is the interface between the
hardware and user applications.
It is a software that provides plateform to other softwares,Some of the are
operating system , disk formatting softwares , computer language translators
,compiler etc.

Features:-
1.Closeness to the system.
2.Fast speed.
3.Different to manipulate.
4.Written in low-level language.
5.Different to design.

1.1EMBEDDED SOFTWARES
Embedded software is computer software, written to control machines or
devices that are not typically thought of as computers, commonly known
as embedded systems. It is typically specialized for the particular hardware that it
runs on and has time and memory constraints. This term is sometimes used
interchangeably with firmware.
2.APPLICATION SOFTWARE
These are the basic softwares used to run to accomplish a particular action and
task .These are dedicated softwares designed to perform simple and single task.

2.1 GENERAL PURPOSE APPLICATION SOFTWARE

These application softwares come inbuilt with packages for general uses and are
every easy to use.
Example :-
(a). Multimedia players e.g VLC , KM , Tiger Player
(b). Adobe Photoshop.
(c). Microsoft office e.g : Word , Powerpoint , Exel e.t.c.
(d).Web based software e.g. Mozilla firefox ,Chrome e.t.c

2.2 SPECIFIC PURPOSE APPLICATION SOFTWARE

These are the application softwares that customizable and mostly used in real
time , or business environment.
(a).Ticket Rservation System.
(b). Healthcare Management System.
(c). Hotel Management System.
(d). Payroll Management System.

RESULT
Various types of softwares applications and its examples are studied.
 Practical:-03
AIM:-
To study various software myths.
THEORY:-

Myth I: Remote developers are worse than in-house developers

Some clients believe that if developers are out of their sight, they‟re
unmotivated, uncontrollable, and unaccountable. This is hardly true,
having modern project management practices, excellent communication
opportunities, and project management systems.

Myth II: Software development is a predictable linear

process

Most people believe that software creation is similar to manufacturing or

building a house from a blueprint. The team just has to stick to the plan.
For better or worse, this isn‟t entirely true.

Myth III: Adding/changing features is a piece of cake

This myth is the opposite of the previous. Some clients believe that a brief
list of generic requirements is enough to start development: details can
be added in due course. Some misinterpret Agile as “no more planning
and no more documentation.” Others equate changing things to changing
a few lines of code.
Myth IV: There is a silver bullet technology/methodology

The latest or most popular technology or SDLC methodology is desirable

because it seems to guarantee success. Unfortunately, teams have to
consider more factors to that end and primarily focus on the client‟s
needs and essential tasks of the software. There‟s no need to go overboard
if something simpler or cheaper can work just as well.

Myth V: More people/man-hours = faster software development

It‟s one of the project management myths. Some clients and

inexperienced PMs apply economic principles to software engineering. If
they fail at planning and fall behind schedule, they think that adding
programmers to the team should help to meet the deadline.

Myth VI: You don’t need testing (or testers)

People that believe in this myth have many reasons for it. For example,
people outside the IT industry think that anyone can test software.
However, only QA experts understand the overall workings of the
software, what the dependencies are, and the impacts of one module on
another. Sometimes clients give up testing arguing that it‟s time-
consuming.

Myth VII: Software can be bug-free

A 100% bug-free product is an ideal worthy of pursuit, but hardly

possible, unless your software is very primitive, written immaculately,
and tested properly. In most cases, even testers with superb testing skills
can‟t claim with absolute certainty that the software is bug-free. All paths
may be tested, but comprehensive testing is never possible.

Myth VIII: Product must be perfect at the first attempt

It‟s an inherently false belief. Nobody knows what „perfect‟ looks like till
people start using the product. It‟s better to build a Minimum Viable
Product (MVP) with the essential functionality rather than require (and
wait for) the whole nine yards from the developers.

Myth IX: Release of the product = end of the project

The idea sounds convenient, but software products rather resemble living
organisms: they have their life cycles and are subject to change. Markets,
businesses, and technologies are evolving rapidly. End-users increasingly
demand functionalities and improvements.

Myth X. Successful development project = successful

product

The right specialists or outsourcing partner can organize a proper project

development process and ensure the quality of the resulting product.
They will deliver it on time and budget. However, they can‟t guarantee
the product‟s success in the market. For example, for a mobile
application, the right monetization strategy and promotion are only some
of the factors that are involved.
RESULT
Various types of software myths are studied.
 PRACTICAL – 04

AIM :- To study about various kinds of risks in a software Projects.

THEORY :-
In software projects , there are many risks given as below :
(1). Inherent Schedule Flows.
Software development given the intangible nature and uniqueness of software , is
inherently difficulty to estimate and schedule.
(2). Requirement Inflation
As the project progress more and more features that were not identified at the
beginning of the project emerge that threaten estimated and timelines.

(3). Employee Tumover

Key perssonel leave the project taking critical information with them significantly
delays or details the projects.
(4). Specification Breakdown
When coding and integration being incomplete or contains conflicting
requirement . Moreover developers may find that even the specification is
incomplete.

(5). Poor Productivity

Given long project timelines , the sense of urgency to the work in earnest is often
absent resulting to time lost in early project stages that can never be regained.

(6). Technical Risks

There is always a conflict between achieving maximum functionality of the
software and peak performance.
In order to compensatefor excessive buget and schedule overcome , companies
sometimes reduce the functionality of the software.

(7). Comprasing and Designs

In order to stuck into the next ‘real’ task , developers tend to rush the design –
process . This a waste of programming hours , as designing is the most critical
part of software development.

RESULT
Various kinds of risks in a software Projects are studied.
 Practical -05
AIM:-
To study about Risk Assessment.
THEORY:-
The risk assessment process is a careful examination of what
could cause harm and what could be harmed and how. It will
help you to determine what risk control measures are needed
and whether you are doing enough
There are three types of risk assessments, baseline, issue-
based and continuous risk assessments.
Baseline risk assessments:
The baseline risk assessment is done to determine the risk for
the first time, i.e. to establish a broad-based risk profile.
Depending on the results of the baseline risk assessment
specific aspects or issues will be highlighted. The baseline risk
assessment must be reviewed on regular intervals to re-
establish the baseline profile as to minimize the risks in the
organization.
Issue-based risk assessments:
This is when baseline risk assessments are assessed in far
more detail using the appropriate issue-based risk assessment
techniques such as HAZOP, FMEA, Fault Tree Analysis, etc.
An issue-based risk assessment will be performed due to
highlighted aspects or issues, new processes, new machines or
the risk assessments in an organization.
Continuous risk assessments:
These risk assessments are part of all forms formal and
informal inspections and observations that take place daily or
on regular intervals.
.

Risk assessment responsibility:

The PI and researchers need to take responsibility for all
assessments associated with their projects. Occasionally you
may need research workers or students to risk assess an
aspect of the work and you will need to check the assessments
are adequate and sign them off. To simplify this process you
can use the health and safety risk assessment templates, risk
estimation tool and guidance for all risks associated with your
research project.

Research risks:
Typical risks that need to be considered as part of research
ethics are:
 Social risks: disclosures that could affect participants
standing in the community, in their family, and their job.
 Legal risks: activities that could result in the participant,
researchers and / or University committing an offence;
activities that might lead to a participant disclosing criminal
activity to a researcher which would necessitate reporting to
enforcement authorities; activities that could result in a civil
claim for compensation.
 Economic harm: financial harm to participant, researcher
and / or University through disclosure or other event.
 Reputational risk: damage to public perception of University
or the University/researchers’ reputation in the eyes of
funders, the research community and / or the general public.
 Safeguarding risks: Risk to young people, vulnerable
adults and / or researcher from improper behaviour, abuse or
exploitation. Risk to researcher of being in a comprising
situation, in which there might be accusations of
improper behaviour.
 Health and safety risks: risks of harm to health, physical
injury or psychological harm to participants or the
researcher.

RESULT
Various kinds of risk assessments in a software Projects are studied.
 Practical -06
AIM:-
To study about Risk mitigation (RMMM).
THEORY:-
Risk analysis support the project team in constructing a strategy to deal
with risks.

There are three important issues considered in developing an effective

strategy:

 Risk avoidance or mitigation - It is the primary strategy which is

fulfilled through a plan.
 Risk monitoring - The project manager monitors the factors and gives
an indication whether the risk is becoming more or less.
 Risk management and planning - It assumes that the mitigation effort
failed and the risk is a reality.

RMMM Plan:

 It is a part of the software development plan or a separate document.

 The RMMM plan documents all work executed as a part of risk
analysis and used by the project manager as a part of the overall
project plan.
 The risk mitigation and monitoring starts after the project is started
and the documentation of RMMM is completed.
a) Mitigation:-
i. General strategy
1. Carefully watch and maintain all factors that influence the risk.
2. Remove extra methods that make the project look nice but are
not essential, to recover some lost time.
3. Ensure documentations is maintained up to date the length of the
project.
4. Maintain a good lines of communication with the customer and
pass along any time concerns.
5. Maintain backup procedures.
6. Remain diligent in peer reviews and other quality issues to
prevent further break downs.
ii. Specific steps to mitigate the risk
1. Remove Staff limitation as an input variable and associated
methods.
2. Remove teacher request as an input variable and associated
methods.
3. Remove elective request as an input variable and associated
methods.
4. Communicate with the customer your time concerns.
b) Monitoring:-
Risk monitoring is the process which tracks and evaluates the levels of
risk in an organisation. As well as monitoring the risk itself, the
discipline tracks and evaluates the effectiveness of risk management
strategies. The findings which are produced by risk monitoring
processes can be used to help to create new strategies and update older
strategies which may have proved to be ineffective.
What are the different types of Risk monitoring?
Voluntary – these risk monitoring strategies are not required by law,
but are carried out by companies to help them to learn from events
which have occurred in the past.
Obligatory – These risk monitoring strategies are required by law for
some organisations, to ensure that proper risk monitoring and
management methods are used.
Reassessment – Secondary or tertiary assessments of risk and risk
management strategies.
Continual – Monitoring which is always going on.
i. Factors to be monitored
1. Lines of code as methods are written
2. Function point complexity values
ii. Monitoring approach

1. Teamwork, peer reviews, and communication comes first.

c) Risk Management:-
Risk management is the process of identifying, assessing and controlling
threats to an organization's capital and earnings. These threats, or risks,
could stem from a wide variety of sources, including financial
uncertainty, legal liabilities, strategic management errors, accidents and
natural disasters. IT security threats and data-related risks, and the risk
management strategies to alleviate them, have become a top priority for
digitized companies.
As a result, a risk management plan increasingly includes companies'
processes for identifying and controlling threats to its digital assets,
including proprietary corporate data, a customer's personally
identifiable information and intellectual property.
Risk Management Process:-
The process should create value for the organization.
It should be an integral part of the overall organizational process.
It should factor into the company's overall decision-making process.
It must explicitly address any uncertainty.
It should be systematic and structured.
It should be based on the best available information.
It should be tailored to the project.
It must take into account human factors, including potential errors.
It should be transparent and all-inclusive.
It should be adaptable to change.

RESULT
Various kinds of risk mitigation (RMMM) in a software Projects are
studied.
 Practical -07
AIM:-
To study about requirement
specification.
THEORY:-
SRS (Software Requirement Specification) is a document created by
system analyst after the requirements are collected from various
stakeholders.
SRS defines how the intended software will interact with hardware,
external interfaces, speed of operation, response time of system,
portability of software across various platforms, maintainability, speed
of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language.
It is the responsibility of system analyst to document the requirements
in technical language so that they can be comprehended and useful by
the software development team.
SRS should come up with following features:

 User Requirements are expressed in natural language.

 Technical requirements are expressed in structured language,
which is used inside the organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.
A complete Software Requirement Specifications must be:

 Clear
 Correct
  Consistent
 Coherent
 Comprehensible
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source
Functional Requirements:
Requirements, which are related to functional aspect of software fall
into this category.
They define functions and functionality within and from the software
system.
Examples -

 Search option given to user to search from various invoices.

 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given
separate rights.
 Should comply business rules and administrative functions.
 Software is developed keeping downward compatibility intact.
Non-Functional Requirements:
Requirements, which are not related to functional aspect of software,
fall into this category. They are implicit or expected characteristics of
software, which users make assumption of.
Non-functional requirements include -

 Security
 Logging
  Storage
 Configuration
 Performance
 Cost
 Interoperability
 Flexibility
 Disaster recovery
 Accessibility

User Interface requirements:

UI is an important part of any software or hardware or hybrid system.

A software is widely accepted if it is -

 easy to operate
 quick in response
 effectively handling operational errors
 providing simple yet consistent user interface

Constraints and Assumptions:

This section will outline any design constraints that have been imposed
on the design of the system by the customer, thereby removing certain
options from being considered by the developers. Also, this section
will contain any assumptions that have been made by the requirements
engineering team when gathering and analyzing the requirements. If
any of the assumptions are found to be false, the system requirements
specification would need to be re-evaluated to make sure that the
documented requirements are still valid.

RESULT
Various kinds of software requirement specifications in a software
Projects are studied.
 Practical – 08
AIM:-
To study about Requirement Engineering.

THEORY:-
Requirement engineering processes have been used for many years in software development. The
processes consist of four stages namely elicitation, analysis and negotiation, specification, and
validation. The appropriate use of the different stages for a given project, and tailoring the stages to
a specific requirement has been a challenge since requirement engineering varies from organization
to organization. Nowadays, more than ever, software development projects are geared towards
failures due to poor requirements. As resolution, solutions have been proposed to overcome the
difficulties encountered and to bridge the gaps resulting in enhanced requirement engineering and
potentially much better software.

The Requirements Engineering Specialist Group (RESG) of the British Computer Society defines
requirements engineering as “…a key activity in the development of software systems and is
concerned with the identification of the goals of stakeholders and their elaboration into precise
statements of desired services and behaviour.” [18] Requirement Engineering is one of the most
important tasks in software development. Requirements are the foundation of software and
requirement engineers come across numerous challenges to develop successful software [10]. Many
problems arise in software development due to wrongly defined requirements [5] which are:

 Schedule slippage

 Cost overruns

 Poor customer satisfaction

 Software does not meet expectations

 Errors in software lead to poor quality deliverable.

A. Requirement Elicitation
Requirements elicitation can be broken down into the activities of fact-finding, information
gathering, and integration [6]. Research has shown that the potential impact of poorly
formulated requirements is substantial. In a previous research, Boehm suggested that
requirements, specification and design errors are the most numerous in a system, averaging
 64% compared to 36% for coding errors [6]. Classification of key requirement elicitation
challenges .

1) Problems of scope: The boundary of the system is ill-defined whereby unnecessary information
may be given, or necessary information ignored. Huzooree et al., International Journal of Advanced
Research in Computer Science and Software Engineering

2) Stakeholder confusion: There are problems of understanding among stakeholders such as

incomplete understanding of needs that may also be conflicting and/or vaguely expressed.

3) Requirement volatility: Requirements evolve over time, either because of changing needs or
because of changing perceptions by the stakeholders. As a consequence, stakeholder expectations
might go unexpressed and unfulfilled.

4) Identification of stakeholder: Potential stakeholders need to be identified since they are directly
or indirectly affected by each phase of the project.

5) Lack of stakeholder’s involvement: Requirements are defined by an intermediary without directly

consulting or involving the key stakeholders who will eventually use the software being developed.

B. Requirement Analysis and Negotiation

Requirements analysis and negotiation is one of the most crucial process in requirements
engineering since it moulds the shape of the desired software end product. During this phase,
conflicts are inevitable since requirement engineers deal with many stakeholders who have their
own perspectives, concerns, priorities and responsibilities.

1) Vague requirements. Vague requirement is the great bugaboo in software requirement and can
have several meanings, incomplete or not sufficiently well defined. Consequently, software
development can diverged from real features and lead to expensive rework.

2) Time constraints. Due to lack of time to deliver the software, requirement engineers quickly
analyse the requirements and proceed to development under schedule pressure.

3) Communication problems. It is widely recognised that communication problems are a major

factor in the delay and failure of software projects. Knowledge acquisition and sharing is very
difficult between the stakeholders since misconception and conflicting views are rife.

4) Skill shortage. Due to lack of skills, requirement engineers fail to analyse and negotiate conflicting
requirements.

5) Risk assessment. Risks that can cause project failures are analysed and mitigating strategies are
evaluated. Due to lack of time, risks assessment are often skipped or scheduled for later.

C. Requirement Specification
Requirements and specifications are very important components in software development. When
requirements are clarified and documented, the corresponding specifications emerge commonly
known as the SRS (Software Requirement Specification) document.

1) Incorrect requirements. Change is ongoing during software development and failure to update the
requirement document often leads incorrect requirement.
2) Requirement maintenance. Requirements inevitably change over time; therefore need to be
maintained continuously through techniques such as software configuration management. Failure to
do so will result in different versions of requirement documents.

3) Requirement definition. Defining requirements is the only process to define the meaning of the
software developed. Improper requirement definitions will lead to ambiguity in the software
development process.

D. Requirement Validation
Validating requirements means ensuring that (1) the set of requirements is correct, complete, and
consistent, (2) a model that satisfies the requirements can be created, and (3) a real-world solution
can be built and tested to prove that it satisfies the requirements.

1) Incomplete and ambiguous requirements. Software requirements tend to suffer from uncertainty
thus leading to incomplete descriptions of the requirement.

2) Inconsistent requirements. Often, requirements engineers fail to write the requirements correctly
leading to inconsistent requirements. One apparent reason is the lack of training of requirements
engineers.

3) Unverifiable test results. A major cause of unverifiable test results is the use of ambiguous terms
in the requirements since they are subjective to interpretation.

RESULT
Various requirements of engineering are studied.
 Practical – 09
AIM:-
To study about System Modeling.

THEORY:-
System modeling is the process of developing abstract models of a system, with each
model presenting a different view or perspective of that system. It is about representing a
system using some kind of graphical notation, which is now almost always based on
notations in the Unified Modeling Language (UML). Models help the analyst to
understand the functionality of the system; they are used to communicate with customers.
Models can explain the system from different perspectives:

 An external perspective, where you model the context or environment of the

system.
 An interaction perspective, where you model the interactions between a system
and its environment, or between the components of a system.
 A structural perspective, where you model the organization of a system or the
structure of the data that is processed by the system.
 A behavioral perspective, where you model the dynamic behavior of the system
and how it responds to events.

Context and process models

 Context models are used to illustrate the operational context of a system - they
show what lies outside the system boundaries. Social and organizational concerns
may affect the decision on where to position system boundaries. Architectural
models show the system and its relationship with other systems.
The example below shows a UML activity diagram.
Interaction models
Types of interactions that can be represented in a model:

 Modeling user interaction is important as it helps to identify user requirements.

 Modeling system-to-system interaction highlights the communication
problems that may arise.
 Modeling component interaction helps us understand if a proposed system
structure is likely to deliver the required system performance and dependability.

Use cases were developed originally to support requirements elicitation and now
incorporated into the UML. Each use case represents a discrete task that involves external
interaction with a system. Actors in a use case may be people or other systems. Use cases
can be represented using a UML use case diagram and in a more detailed textual/tabular
format.
Structural models
Structural models of software display the organization of a system in terms of the
components that make up that system and their relationships. Structural models may
be static models, which show the structure of the system design, or dynamic models,
which show the organization of the system when it is executing. You create structural
models of a system when you are discussing and designing the system architecture.
UML class diagrams are used when developing an object-oriented system model to show
the classes in a system and the associations between these classes. An object class can be
thought of as a general definition of one kind of system object. An association is a link
between classes that indicates that there is some relationship between these classes.
Behavioral models
Behavioral models are models of the dynamic behavior of a system as it is executing.
They show what happens or what is supposed to happen when a system responds to a
stimulus from its environment. Two types of stimuli:

 Some data arrives that has to be processed by the system.

 Some event happens that triggers system processing. Events may have
associated data, although this is not always the case.

Many business systems are data-processing systems that are primarily driven by data. They
are controlled by the data input to the system, with relatively little external event
processing. Data-driven models show the sequence of actions involved in processing
input data and generating an associated output.

RESULT Various Software Models has been studied.

 Practical – 10
AIM:-
To study about Architecture of analysis.

THEORY:-
The architecture of a system describes its major components, their relationships
(structures), and how they interact with each other. Software architecture and
design includes several contributory factors such as Business strategy, quality
attributes, human dynamics, design, and IT environment.

We can segregate Software Architecture and Design into two distinct phases:
Software Architecture and Software Design. In Architecture, nonfunctional
decisions are cast and separated by the functional requirements. In Design,
functional requirements are accomplished.
Architecture serves as a blueprint for a system. It provides an abstraction to manage
the system complexity and establish a communication and coordination mechanism
among components.

Goals of Architecture
The primary goal of the architecture is to identify requirements that affect the
structure of the application. A well-laid architecture reduces the business risks
associated with building a technical solution and builds a bridge between business
and technical requirements.
Some of the other goals are as follows −
  Expose the structure of the system, but hide its implementation details.
 Realize all the use-cases and scenarios.
 Try to address the requirements of various stakeholders.
 Handle both functional and quality requirements.
 Reduce the goal of ownership and improve the organization’s market
position.

Role of Software Architect

A Software Architect provides a solution that the technical team can create and
design for the entire application. A software architect should have expertise in the
following areas-
Design Expertise
 Expert in software design, including diverse methods and approaches such
as object-oriented design, event-driven design, etc.
 Lead the development team and coordinate the development efforts for the
integrity of the design.
 Should be able to review design proposals and tradeoff among themselves.
Domain Expertise
 Expert on the system being developed and plan for software evolution.
 Assist in the requirement investigation process, assuring completeness and
consistency.
 Coordinate the definition of domain model for the system being developed.
Technology Expertise
 Expert on available technologies that helps in the implementation of the
system.
 Coordinate the selection of programming language, framework, platforms,
databases, etc.
Methodological Expertise
 Expert on software development methodologies that may be adopted during
SDLC (Software Development Life Cycle).
 Choose the appropriate approaches for development that helps the entire
team.
Hidden Role of Software Architect
 Facilitates the technical work among team members and reinforcing the trust
relationship in the team.
 Information specialist who shares knowledge and has vast experience.
 Protect the team members from external forces that would distract them and
bring less value to the project.
Quality Attributes
Quality is a measure of excellence or the state of being free from deficiencies or
defects. Quality attributes are the system properties that are separate from the
functionality of the system.
Static Quality Attributes
Reflect the structure of a system and organization, directly related to architecture,
design, and source code. They are invisible to end-user, but affect the development
and maintenance cost, e.g.: modularity, testability, maintainability, etc.
Dynamic Quality Attributes
Reflect the behavior of the system during its execution. They are directly related to
system’s architecture, design, source code, configuration, deployment parameters,
environment, and platform.

RESULT
Architecture of analysis has been studied.
 Practical – 11
AIM:-
To study about Software Design.
THEORY:-
Design is a meaningful engineering representation of something that is to be built.
It is essential to develop a design of a system before writing any software that will be
used to control the system or to interact with it. Designing the software is probably
the hardest part of any software. Producing good software designs requires a
considerable amount of practice, with a great deal of feedback on the quality of the
designs with the resulting software products influencing the design of the next
software system.
Following are some types of patterns that seem to repeatedly occur in software
development :
1. A menu-driven system, where the user must pass through several steps in a
hierarchy in order to perform his or her work. The menus may be of the pull-down
type such as is common on personal computers or may be entirely text based.
2. An event-driven system, where the user must select steps in order to perform his
or her work. The steps need not be taken in a hierarchical order. This pattern is most
commonly with control of concurrent processes where actions may be repeated
indefinitely, in contrast to pattern 3rd. It is also typical of a user interface that is
guided by selection of options from both menus and combinations of keystrokes,
such as in menus that may pop-up in response to user requests. In any case, there
is less of a hierarchy than in the previous pattern.
3. A system in which the actions taken depend on one of a small number of ―states‖
and a small set of optional actions that can be taken for each state. The optional
action taken depends on both the state and the value of an input ―token.‖ In this
pattern, the tokens are usually presented as a stream. Once a token is processed, it
is removed from the input stream.
4. A system in which a sequence of input tokens (usually in text format) is
processed, one token at a time. This pattern differs from the previous pattern in that
the decision about which action to take may depend on more information than is
available from just the pair consisting of the state and the input token. In this pattern,
the tokens may still remain in the input stream after being processed.
5. A system in which a large amount of information is searched for one or more
specific pieces of information. The searches may occur once or many times.
6. A system that can be used in a variety of applications but needs adjustments to
work properly in new settings.
7. A system in which everything is primarily guided by an algorithm, rather than
depending primarily on data.
8. A system that is distributed, with many relatively independent computational
actions taking place. Some of the computational actions may communicate with
other computational actions.

MODULARITY:
In software engineering, modularity refers to the extent to which a software/Web
application may be divided into smaller modules. Software modularity indicates that
the number of application modules are capable of serving a specified business
domain.
Modularity is successful because developers use prewritten code, which saves
resources. Overall, modularity provides greater software development manageability.
STRATEGY OF DESIGN:
There are many strategies or techniques for performing system design. They are:
1. Bottom-up approach:
The design starts with the lowest level components and subsystems.
By using these components, the next immediate higher level components and
subsystems are created or composed. The process is continued till all the
components and subsystems are composed into a single component, which is
considered as the complete system. The amount of abstraction grows high as the
design moves to more high levels.
By using the basic information existing system, when a new system needs to be
created, the bottom up strategy suits the purpose.

2. Top-down approach:
Each system is divided into several subsystems and components.
Each of the subsystem is further divided into set of subsystems and
components. This process of division facilitates in forming a system hierarchy
structure. The complete software system is considered as a single entity and in
relation to the characteristics, the system is split into sub-system and
component. The same is done with each of the sub-system.

This process is continued until the lowest level of the system is reached. The
design is started initially by defining the system as a whole and then keeps on
adding definitions of the subsystems and components. When all the definitions
are combined together, it turns out to be a complete system.
 For the solutions of the software need to be developed from the ground level,
top-down design best suits the purpose.

3. Hybrid Design:
It is a combination of both the top – down and bottom – up design
strategies. In this we can reuse the modules.

FUNCTION ORIENTED DESIGN:

Function Oriented Design is an approach to software design where the design is
decomposed into a set of interacting units where each unit has a clearly defined
function. Function Oriented Design Strategies are as follows:
1.Data Flow Diagram (DFD):
A data flow diagram (DFD) maps out the flow of information for any
process or system. It uses defined symbols like rectangles, circles and arrows,
plus short text labels, to show data inputs, outputs, storage points and the
routes between each destination.

2.Data Dictionaries:
Data dictionaries are simply repositories to store information about all
data items defined in DFDs. At the requirement stage, data dictionaries
contains data items. Data dictionaries include Name of the item, Aliases (Other
 names for items), Description / purpose, Related data items, Range of values,
Data structure definition / form.

3.Structure Charts:
It is the hierarchical representation of system which partitions the
system into black boxes (functionality is known to users but inner details are
unknown). Components are read from top to bottom and left to right. When a
module calls another, it views the called module as black box, passing required
parameters and receiving results.
Pseudo Code:
Pseudo Code is system description in short English like phrases
describing the function. It use keyword and indentation. Pseudo codes are used
as replacement for flow charts. It decreases the amount of documentation
required.

OBJECT ORIENTED DESIGN:

Object Oriented Design (OOD) is one approach of software design and is defined as
the process of planning a system of interacting objects for the purpose of solving a
software problem. The other characteristics of Object Oriented Design are as follow:
Objects are abstractions of the real-world or system entities and manage
themselves.

The objects are independent and in an encapsulated state and

representation information.

System functionality is expressed in terms of object services.

Shared data areas are eliminated.

Communication between objects is through message passing.

The objects may be distributed and may execute sequentially or in parallel.

DESIGN REVIEWS:
A major goal of a software manager is to predict risk in a software development
project. He or she would like to minimize risks entirely. Design reviews have much in
common with requirements reviews. They are extremely important to the success of
a project. They require considerable planning, and a large expenditure of time and
resources. For simplicity, we will only discuss design reviews that take place at a
single meeting location with all stakeholders present. A checklist for a design review
is given below:-
 1. The presentation should be rehearsed.
2. The time of the presentation should fall within allotted limits.
3. Sufficient time should be available for questions.
4. People who can answer technical questions should be in attendance.
5. All slides, transparencies, and multimedia materials must be checked for
accuracy.
6. All slides, transparencies, and multimedia materials must be checked for
spelling.
7. Paper copies of slides, transparencies, and multimedia materials should be
available to all participants.
8. Someone must verify that the meeting room has all necessary equipment:
microphones, overhead projector, slide projector, videotape player and
monitor, computer-monitor hookup, etc.
9. An attendance list with names, addresses, phone numbers, and affiliations
must be passed around, and all attendees must sign it.

RESULT
The software design has been studied.

Practical – 12
AIM:-
To study about various kinds of testing techniques.
THEORY:-
Testing is a process of executing a program with the aim of finding error. To make
our software perform well it should be error free.If testing is done successfully it will
remove all the errors from the software.

Various kinds of Testing Techniques:

Software testing is generally classified into two main broad categories: functional
testing and non-functional testing. There is also another general type of testing
called maintenance testing.

Functional Testing:

Functional testing involves the testing of the functional aspects of a software

application. There are several types of functional testing, such as:

1. Unit Testing: Testing each component or module of your software project is

known as unit testing. To perform this kind of testing, knowledge of programming is
necessary. So only programmers do this kind of tests, not testers.

2. Integration testing: After integrating the modules, you need to see if the
combined modules work together or not. This type of testing is known as integration
testing. You need to perform fewer integration tests than unit tests.

3. End-to-end Testing: End-to-end testing is the functional testing of the entire

software system. When you test the complete software system, such testing is called
end-to-end testing. You need to perform fewer end-to-end tests than integration
tests.

4. Regression testing: If you need to make changes in any component, module,

or function, you have to see if the whole system functions properly after those
modifications. Testing of the whole system after such modifications is known as
regression testing.

5. Black box testing: Performed by the QA team of a company, black box testing
is a testing technique that involves the checking of the application’s functionality
without having any technical knowledge of the application, like the knowledge of the
code’s logic, how the code works, knowledge of the internal structure, etc.
6. White box testing: Performed by the development team, white box testing is a
testing method that requires a good understanding of the application’s code. It
requires great knowledge of the app’s internal logic.

7. Acceptance testing: The client who will purchase your software will perform
acceptance testing (also known as User Acceptance Testing) to see if the software
can be accepted or not by checking whether your software meets all the client’s
requirements and preferences. If your software doesn’t meet all the requirements or
if your client doesn’t like something in the app, they may request you to make
changes before accepting the project.

7. User Interface Testing: User interface testing involves the testing of the
application’s user interface. The aim of UI tests is to check whether the user
interfaces have been developed according to what is described in the requirements
specifications document.

8. Smoke testing

9. Sanity testing

Non-functional Testing

Non-functional testing is the testing of non-functional aspects of an application, such

as performance, reliability, usability, security, and so on. Non-functional tests are
performed after the functional tests. There are several types of non-functional
testing, such as:

1. Accessibility testing: Testing whether your software is accessible to disabled

people or not is termed as accessible testing. For this type of tests, you need to
check if disabled people such as those who are color blind, blind, and deaf can use
your application.
2. Alpha testing: Alpha testing is a kind of testing to look for all the errors and
issues in the entire software. This kind of test is done at the last phase of app
development and is performed at the place of the developers, before launching the
product or before delivering it to the client to ensure that the user/client gets an error-
free software application.

3. Beta testing: As said earlier, beta testing takes place after alpha testing. Beta
testing is done before the launch of the product. It is carried out in a real user
environment by a limited number of actual customers or users, in order to be certain
that the software is completely error-free and it functions smoothly. After collecting
feedback and constructive criticism from those users, some changes are made to
make the software better.

4. Ad-hoc testing: As the name suggests, ad-hoc testing is a kind of testing that is
performed in an ad-hoc manner, without using any test cases, plans, documentation,
or systems. Unlike all other types of testing, this kind of testing is not carried out in a
systematic manner.

5. Compatibility testing: Compatibility testing involves compatibility checking of

the software with different operating systems, web browsers, network environments,
hardware, and so on. It checks whether the developed software application is
working fine with different configurations.

6. Backward compatibility testing: Backward compatibility testing is carried out

to test if a brand new or an updated version of an application is compatible with the
previous versions of the environments (such as operating systems and web
browsers) on which the software runs. Sometimes, some application is updated
specifically to match the standard and style of a newer, more modern environment.
In that case, support for backward compatibility is necessary.

7. Browser compatibility testing: As the name says, browser compatibility

testing checks a web application for browser compatibility. More specifically, it is
tested whether the web app can easily be accessed from all versions of the major
web browsers.
8. Performance testing: Performance tests are run to check if the software’s
performance is good or not. There are performance testing tools that analyze your
app’s performance and show you the performance issues. By fixing those issues,
you’ll be able to increase the performance of your software application.

9. Load testing: Load testing is one kind of performance testing that tests how
much load a system can take before the software performance begins to degrade.
By running load tests, we can know the capacity of taking load of a system.

10. Recovery testing: Recovery testing involves the checking of whether the
application can recover from crashes and how well it recovers. In this kind of tests,
testers observe how well the software can come back to the normal flow of
execution. Crashes can happen anytime. Even if your software is of exceptional
quality, crashes may happen. You don’t know when they may take place and annoy
the users.

11. Agile testing: Carried out by the QA team, Agile testing is a type of testing that
is conducted according to the rules of agile methodology. This kind of testing is done
from the actual customers’ viewpoint.

12. API testing: Just like unit testing, API testing is also a code-level testing type.
The basic difference between unit testing and API testing is that unit testing is
performed by the development team whereas API testing is handled by the QA team.

13. Security testing: Security tests are performed to ensure the security of your
application, in order that security breaches can be prevented. Security experts run
this kind of tests to see how much your software is secure from attacks and to find
security issues so that the app’s security can be strengthened.

14. Usability testing: Testing the user-friendliness of an app is known as usability

testing. It involves the checking of how much usable or user-friendly the app is. It is
tested whether any user can easily use your software without getting stuck.

15. Scalability testing: Scalability testing verifies whether the software is scalable
or not. In other words, it checks if your app performs well when the number of users,
amount of data, or the number of transactions increases significantly. A software
application that is not scalable may cause great business loss.
16. Reliability testing: Reliability testing is a type of software testing that verifies if
the software is reliable or not. In other words, it checks whether the software runs
error-free and that one can rely on it.

17. Failover testing

18. Volume testing

19. Stress testing

RESULT
The various kinds of testing has been studied.

Practical – 13
AIM:-
To study about Object Oriented analysis and design.

THEORY:-

Object-Oriented Analysis And Design (OOAD)

It’s a structured method for analyzing, designing a system by applying the object-
orientated concepts, and develop a set of graphical system models during the
development life cycle of the software.

OOAD In The SDLC

The software life cycle is typically divided up into stages going from abstract
descriptions of the problem to designs then to code and testing and finally to
deployment. The earliest stages of this process are analysis (requirements) and
design. The distinction between analysis and design is often described as ―what Vs
how‖.

In analysis developers work with users and domain experts to define what the

system is supposed to do. Implementation details are supposed to be mostly or

totally ignored at this phase. The goal of the analysis phase is to create a model of

the system regardless of constraints such as appropriate technology. This is typically

done via use cases and definition of the most important objects using conceptual
model.

The design phase refines the analysis model and applies the needed technology and

other implementation constrains. It focuses on describing the objects, their attributes,

behavior, and interactions. The design model should have all the details required so
that programmers can implement the design in code.

Object-Oriented Analysis

In the object-oriented analysis, we …

 1.Elicit: Define what does the software need to do, and what’s the problem the
software trying to solve.
2.Specify: Describe the requirements, usually, using use cases (and
scenarios) or user stories.
3.Conceptual: Identify the important objects, refine them, and define their
relationships and behavior and draw them in a simple diagram.

Object-Oriented Design

The analysis phase identifies the objects, their relationship, and behavior using the
conceptual model (a definition for the objects).

While in design phase, we describe these objects (by creating class diagram from

conceptual diagram — usually mapping conceptual model to class diagram), their

attributes, behavior, and interactions.

In addition to applying the software design principles and patterns which will be
covered in later tutorials.

The input for object-oriented design is provided by the output of object-oriented

analysis. But, analysis and design may occur in parallel, and the results of one
activity can be used by the other.

In the object-oriented design, we …

 1.Describe the classes and their relationships using class diagram.
2.Describe the interaction between the objects using sequence diagram.
3.Apply software design principles and design patterns.
A class diagram gives a visual representation of the classes you need. And here is

where you get to be really specific about object-oriented principles like inheritance
and polymorphism.

RESULT

Object Oriented analysis and design has been studied.