OOSE Notes 1 PDF
OOSE Notes 1 PDF
OOSE Notes
UNIT I
Process Models:
The term software engineering is the product of two words, software, and engineering.
Computer programs and related documentation such as requirements, design models and
user manuals.
Today, software takes on a dual role. It is a product and, at the same time, the vehicle for
delivering a product. As a product, it delivers the computing potential embodied by
computer hardware or, more broadly, a network of computers that are accessible by local
hardware. Whether it resides within a cellular phone or operates inside a mainframe
computer, software is an information transformer—producing, managing, acquiring,
modifying, displaying, or transmitting information that can be as simple as a single bit or as
complex as a multimedia presentation.
As the vehicle used to deliver the product, software acts as the basis for the control of the
computer (operating systems), the communication of information (networks), and the
creation and control of other programs (software tools and environments). Software
delivers the most important product of our time—information.
Software transforms personal data (e.g., an individual’s financial transactions) so that the
data can be more useful in a local context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information networks (e.g., Internet)
and provides the means for acquiring information in all of its forms.
The role of computer software has undergone significant change over a time span of little
more than 50 years. Dramatic improvements in hardware performance, profound changes
in computing architectures, vast increases in memory and storage capacity, and a wide
variety of exotic input and output options have all precipitated more sophisticated and
complex computer-based systems. The lone programmer of an earlier era has been
replaced by a team of software specialists, each focusing on one part of the technology
required to deliver a complex application.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
1. System software: Infrastructure software come under this category like compilers,
operating systems, editors, drivers, etc. Basically system software is a collection of
programs to provide service to other programs.
2. Real time software: These software are used to monitor, control and analyze real world
events as they occur. An example may be software required for weather forecasting. Such
software will gather and process the status of temperature, humidity and other
environmental parameters to forcast the weather.
4. Business software : This is the largest application area. The software designed to
process business applications is called business software. Business software could be
payroll, file monitoring system, employee management, account management. It may also
be a data warehousing tool which helps us to take decisions based on available data.
Management information system, enterprise resource planning (ERP) and such other
software are popular examples of business software.
5. Personal computer software: The software used in personal computers are covered in
this category. Examples are word processors, computer graphics, multimedia and
animating tools, database management, computer games etc. This is a very upcoming area
and many big organisations are concentrating their effort here due to large customer base.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
7. Web based software: The software related to web applications come under this
category. Examples are CGI, HTML, Java, Perl, DHTML etc.
LEGACY SOFTWARE:
Legacy software is software that has been around a long time and still fulfills a business
need. It is mission critical and tied to a particular version of an operating system or
hardware model (vendor lock-in) that has gone end-of-life. Generally the lifespan of the
hardware is shorter than that of the software.
PROCESS MODELS:
Waterfall Model
The waterfall model is a breakdown of project activities into linear sequential phases,
where each phase depends on the deliverables of the previous one and corresponds to a
specialisation of tasks. The approach is typical for certain areas of engineering design.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
V Model
The V-model represents a development process that may be considered an extension of
the waterfall model and is an example of the more general V-model. Instead of moving
down in a linear way, the process steps are bent upwards after the coding phase, to form
the typical V shape. The V-Model demonstrates the relationships between each phase of
the development life cycle and its associated phase of testing. The horizontal and vertical
axes represent time or project completeness (left-to-right) and level of abstraction
(coarsest-grain abstraction uppermost), respectively.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Incremental model
The incremental build model is a method of software development where the model is
designed, implemented and tested incrementally (a little more is added each time) until
the product is finished. It involves both development and maintenance. The product is
defined as finished when it satisfies all of its requirements. Each iteration passes through
the requirements, design, coding and testing phases. And each subsequent release of the
system adds function to the previous release until all designed functionally has been
implemented. This model combines the elements of the waterfall model with the iterative
philosophy of prototyping.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Iterative Model
An iterative life cycle model does not attempt to start with a full specification of
requirements by first focusing on an initial, simplified set user features, which then
progressively gains more complexity and a broader set of features until the targeted
system is complete. When adopting the iterative approach, the philosophy of incremental
development will also often be used liberally and interchangeably.
In other words, the iterative approach begins by specifying and implementing just part of
the software, which can then be reviewed and prioritized in order to identify further
requirements. This iterative process is then repeated by delivering a new version of the
software for each iteration. In a light-weight iterative project the code may represent the
major source of documentation of the system; however, in a critical iterative project a
formal software specification may also be required.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
RAD model
Rapid application development was a response to plan-driven waterfall processes,
developed in the 1970s and 1980s, such as the Structured Systems Analysis and Design
Method (SSADM). Rapid application development (RAD) is often referred as the adaptive
software development. RAD is an incremental prototyping approach to software
development that end users can produce better feedback when examining a live system,
as opposed to working strictly with documentation. It puts less emphasis on planning and
more emphasis on an adaptive process.
RAD may resulted in a lower level of rejection when the application is placed into
production, but this success most often comes at the expense of a dramatic overruns in
project costs and schedule. RAD approach is especially well suited for developing
software that is driven by user interface requirements. Thus, some GUI builders are often
called rapid application development tools.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Spiral model
The spiral model, first described by Barry Boehm in 1986, is a risk-driven software
development process model which was introduced for dealing with the shortcomings in
the traditional waterfall model. A spiral model looks like a spiral with many loops. The
exact number of loops of the spiral is unknown and can vary from project to project. This
model supports risk handling, and the project is delivered in loops. Each loop of the spiral
is called a Phase of the software development process.
The initial phase of the spiral model in the early stages of Waterfall Life Cycle that is
needed to develop a software product. The exact number of phases needed to develop the
product can be varied by the project manager depending upon the project risks. As the
project manager dynamically determines the number of phases, so the project manager
has an important role to develop a product using a spiral model.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Prototype is defined as first or preliminary form using which other forms are
copied or derived.
Prototype model is a set of general objectives for software.
It does not identify the requirements like detailed input, output.
It is software working model of limited functionality.
In this model, working programs are quickly produced.
1. Communication
In this phase, developer and customer meet and discuss the overall objectives of the
software.
2. Quick design
Quick design is implemented when requirements are known.
It includes only the important aspects like input and output format of the software.
It focuses on those aspects which are visible to the user rather than the detailed
plan.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
NOTE: The description of the phases of the spiral model is same as that of the process
model.
In spiral model, the software is produced early in the life cycle process.
Disadvantages of Spiral Model
It can be costly to develop a software model.
It is not used for small projects.
What is a Component?
Views of a Component
A component can have three different views − object-oriented view, conventional view,
and process-related view.
Object-oriented view
A component is viewed as a set of one or more cooperating classes. Each problem domain
class (analysis) and infrastructure class (design) are explained to identify all attributes
and operations that apply to its implementation. It also involves defining the interfaces
that enable classes to communicate and cooperate.
Conventional view
Process-related view
In this view, instead of creating each component from scratch, the system is building from
existing components maintained in a library. As the software architecture is formulated,
components are selected from the library and used to populate the architecture.
A user interface (UI) component includes grids, buttons referred as controls, and
utility components expose a specific subset of functions used in other components.
Other common types of components are those that are resource intensive, not
frequently accessed, and must be activated using the just-in-time (JIT) approach.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Characteristics of Components
Encapsulated − A A component depicts the interfaces, which allow the caller to use
its functionality, and do not expose details of the internal processes or any internal
variables or state.
Advantages Disadvantages
UNIT II
Requirements Engineering:
INTRODUCTION
The software requirements are description of features and functionalities of the target
system. Requirements convey the expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown, expected or unexpected from
client’s point of view.
Requirement Engineering
The process to gather the software requirements from client, analyze and document them
is known as requirement engineering.
Feasibility Study
Requirement Gathering
Feasibility study
When the client approaches the organization for getting the desired product developed, it
comes up with rough idea about what all functions the software must perform and which
all features are expected from the software.
Referencing to this information, the analysts does a detailed study about whether the
desired system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization. This study analyzes
whether the software product can be practically materialized in terms of implementation,
contribution of project to organization, cost constraints and as per values and objectives of
the organization. It explores technical aspects of the project and product such as usability,
maintainability, productivity and integration ability.
The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project
should be undertaken.
Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the
client and end-users to know their ideas on what the software should provide and which
features they want the software to include.
SRS 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
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
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.
Requirements gathering - The developers discuss with the client and end users
and know their expectations from the software.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements
are compromised reasonably.
Requirements Elicitation is the process to find out the requirements for an intended
software system by communicating with client, end users, system users and others who
have a stake in the software system development.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Interviews
Interviews are strong medium to collect requirements. Organization may conduct several
types of interviews such as:
Oral interviews
Written interviews
One-to-one interviews which are held between two persons across the table.
Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.
Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is handed
over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Task analysis
Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied
and requirements of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert people in the domain can be a
great help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded
for further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail functionality for user to
interpret the features of intended software product. It helps giving better idea of
requirements. If there is no software installed at client’s end for developer’s reference and
the client is not aware of its own requirements, the developer creates a prototype based
on initially mentioned requirements. The prototype is shown to the client and the
feedback is noted. The client feedback serves as an input for requirement gathering.
Observation
Team of experts visit the client’s organization or workplace. They observe the actual
working of the existing installed systems. They observe the workflow at client’s end and
how execution problems are dealt. The team itself draws some conclusions which aid to
form requirements expected from the software.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Credible source
Software Requirements
We should try to understand what sort of requirements may arise in the requirement
elicitation phase and what kinds of requirements are expected from the software system.
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.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Examples -
Users can be divided into groups and groups can be given separate rights.
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.
Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Disaster recovery
Accessibility
Could have : Software can still properly function with these requirements.
While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of
debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for
software updates.
easy to operate
quick in response
User acceptance majorly depends upon how user can use the software. UI is the only way
for users to perceive the system. A well performing software system must also be
equipped with attractive, clear, consistent and responsive user interface. Otherwise the
functionalities of software system can not be used in convenient way. A system is said be
good if it provides means to use it efficiently. User interface requirements are briefly
mentioned below -
Content presentation
Easy Navigation
Simple interface
Responsive
Consistent UI elements
Feedback mechanism
Default settings
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Purposeful layout
Validation of requirement
Software Metrics provide measures for various aspects of software process and software
product.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Software measures are fundamental requirement of software engineering. They not only
help to control the software development process but also aid to keep quality of ultimate
product excellent.
According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot
measure.” By his saying, it is very clear how important software measures are.
Quality Metrics - Defects, their types and causes, consequence, intensity of severity
and their implications define the quality of product.
Process Metrics - In various phases of SDLC, the methods and tools used, the
company standards and the performance of development are software process
metrics.
Resource Metrics - Effort, time and various resources used, represents metrics for
resource measurement.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Before we start working on any project, it is very important that we are very clear on what
we want to do and how do we want to do. In my last Blog, I discussed on how to write a good
SRS for your project and what is the advantage we get out of that. In this Blog, I’ll discuss Use
Cases and their advantage in our projects.
What are Use Cases?
In software and systems engineering, a use case is a list of actions or event steps, typically
defining the interactions between a role (known in the Unified Modeling Language as
an actor) and a system, to achieve a goal. The actor can be a human, an external system, or
time. In systems engineering, use cases are used at a higher level than within software
engineering, often representing missions or stakeholder goals. Another way to look at it is a
use case describes a way in which a real-world actor interacts with the system. In a system
use case you include high-level implementation decisions. System use cases can be written in
both an informal manner and a formal manner.
What is the importance of Use Cases?
Use cases have been used extensively over the past few decades. The advantages of Use cases
includes:
The list of goal names provides the shortest summary of what the system will offer
It gives an overview of the roles of each and every component in the system. It will
help us in defining the role of users, administrators etc.
It helps us in extensively defining the user’s need and exploring it as to how it will
work.
It provides solutions and answers to many questions that might pop up if we start a
project unplanned.
How to plan use case?
Following example will illustrate on how to plan use cases:
Use Case: What is the main objective of this use case. For eg. Adding a software component,
adding certain functionality etc.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Primary Actor: Who will have the access to this use case. In the above examples,
administrators will have the access.
Scope: Scope of the use case
Level: At what level the implementation of the use case be.
Flow: What will be the flow of the functionality that needs to be there. More precisely, the
work flow of the use case.
Use Case Diagram
Below is a sample use case diagram which I have prepared for reference purpose for a
sample project (much like Facebook). It would help us to understand the role of various
actors in our project. Various actors in the below use case diagram are: User and System.
The main use cases are in the system and the diagram illustrates on how the actors interact
with the use cases.For eg. During Sign Up, only users need to interact with the use case and
not the system whereas when it comes to categorizing posts, only system would be required.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Unit III
Estimation
1. Observation of Estimation
2. The Project Planning Process
3. Software scope and feasibility
4. Resources
5. Software Project Estimation
6. Decomposition Techniques
7. Empirical estimation model
8. Estimation for object oriented projects
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Estimation
Estimation is the process of finding an estimate, or
approximation, which is a value that can be used for some
purpose even if input data may be incomplete, uncertain, or
unstable.
Estimation determines how much money, effort, resources, and
time it will take to build a specific system or product.
Estimation is based on −
Past Data/Past Experience
Available Documents/Knowledge
Assumptions
Identified Risks
The four basic steps in Software Project Estimation are −
Estimate the size of the development product.
Estimate the effort in person-months or person-hours.
Estimate the schedule in calendar months.
Estimate the project cost in agreed currency.
1. Observations of Estimation
Estimation need not be a one-time task in a project
It can take place during −
Acquiring a Project.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Project size:
What’s going to be downside quality in terms of the trouble and time
needed to develop the product?
Cost:
What proportion is it reaching to value to develop the project?
Duration:
However long is it reaching to want complete development?
Effort:
What proportion effort would be required?
The effectiveness of the following designing activities relies on
the accuracy of those estimations.
planning force and alternative resources
workers organization and staffing plans
Risk identification, analysis, and abatement designing
Miscellaneous arranges like quality assurance plan,
configuration, management arrange, etc.
Precedence ordering among project planning activities:
The different project connected estimates done by a project
manager have already been mentioned.
The below diagram shows the order during which vital project
coming up with activities is also undertaken.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Resources
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
There are five tools and techniques for estimating activity resources:
The judgement of experts:
this means involving experts who have already performed this type
of work before and obtaining opinions on what resources are
needed.
Alternative analysis:
This means considering different options on how to allocate
resources.
This includes changing the number of resources and the type of
resources used.
Many times, there is more than one way to perform a task, and
alternative analysis helps you decide between different possibilities.
Published estimation data:
something that project managers in many industries use to
understand how many resources they need for a specific project.
These are based on articles, research and studies that collect,
analyze and publish data from other people and organizations’
projects.
Project management software: these often feature functions
designed to help project managers estimate resource needs and
constraints and find the best combination for the project in question.
The bottom-up estimate: this means splitting complex tasks into
simpler tasks and processing the resources needed for each small
step.
The need or cost of the resources of the individual tasks is then
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
The smaller and more detailed the task, the greater the accuracy of
this technique
Estimation of activities’ duration
Once you have finished estimating resources per activity, you
have everything you need to understand how long it will take
to complete each activity.
Estimating the duration of a task means starting with
information about that specific task and then working with the
project team to develop a time estimate.
Most of the time you will start with a rough estimate and then
refine it.
When you talk about estimating project time, you may have
already heard of effort.
If you’re interested in learning more about it, you can check
this article about effort and duration.
Here are the five tools and techniques to create more accurate
durability estimates:
The evaluation of the experts that will come from the members
of the project team who are familiar with the work that needs
to be done.
The equivalent estimate, i.e. when looking at similar activities
from previous projects and how much time they took.
Parametric Estimation, i.e. linking the project data into a
formula that provides an estimation.
The three-point estimate, i.e. when three numbers come up: a
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Assumptions
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Identified Risks
The four basic steps in Software Project Estimation are −
Estimate the size of the development product.
Estimate the effort in person-months or person-hours.
Estimate the schedule in calendar months.
Estimate the project cost in agreed currency.
6. Decomposition Techniques
General Project Estimation Approach
The Project Estimation Approach that is widely used is
Decomposition Technique.
Decomposition techniques take a divide and conquer approach.
Size, Effort and Cost estimation are performed in a stepwise
manner by breaking down a Project into major Functions or
related Software Engineering Activities.
Step 1 − Understand the scope of the software to be built.
Step 2 − Generate an estimate of the software size.
Start with the statement of scope.
Decompose the software into functions that can each be
estimated individually.
Calculate the size of each function.
Derive effort and cost estimates by applying the size values to
your baseline productivity metrics.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
UNIT IV
Unit Test :
Unit testing focuses verification effort on the smallest unit of software design—the software component
or module.
The unit test focuses on the internal processing logic and data structures within the boundaries of a
component.
This type of testing can be conducted in parallel for multiple components.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Integration Testing :
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Top-down testing
Modules are integrated by moving downward through the control hierarchy, beginning
with the main control module (main program).
Modules subordinate (and ultimately subordinate) to the main control module are
incorporated into the structure in either a depth-first or breadth-first manner.
Integration Testing
The integration process is performed in a series of five steps
1. The main control module is used as a test driver and stubs are substituted for all
components directly subordinate to the main control module.
2. Depending on the integration approach selected (i.e., depth or breadth first), subordinate
stubs are replaced one at a time with actual components.
4. On completion of each set of tests, another stub is replaced with the real component.
5. Regression testing (discussed later in this section) may be conducted to ensure that new
errors have not been introduced.
The process continues from step 2 until the entire program structure is built.
VALIDATION TESTING
The process of evaluating software during the development process or at the end of the
development process to determine whether it satisfies specified business requirements.
Validation Testing ensures that the product actually meets the client's needs. It can also be
defined as to demonstrate that the product fulfills its intended use when deployed on
appropriate environment.
It answers to the question, Are we building the right product?
Verification:
Verification is the process of checking that a software achieves its goal without any bugs. It is
the process to ensure whether the product that is developed is right or not. It verifies whether
the developed product fulfills the requirements that we have.
Verification Validation
The process just checks the design, code and It should evaluate the entire product including the code.
program.
Reviews, walkthroughs, inspections, and Functional and non functional methods of testing are involved .
desk- checking involved. In depth check of the product is done.
It checks the software with specification. It checks if the software meets the user needs.
Alpha Testing is performed by the Testers within the organization whereas Beta
Testing is performed by the end users.
Alpha Testing is performed at Developer's site whereas Beta Testing is performed at
Client's location.
Reliability and Security testing are not performed in-depth in Alpha Testing while
Reliability, Security and Robustness are checked during Beta Testing.
Alpha Testing involves both Whitebox and Blackbox testing whereas Beta Testing
mainly involves Blackbox testing.
Alpha Testing requires testing environment while Beta Testing doesn't require testing
environment.
Alpha Testing requires long execution cycle whereas Beta Testing requires only few
weeks of execution.
Critical issues and bugs are addressed and fixed immediately in Alpha Testing
whereas issues and bugs are collected from the end users and further implemented in
Beta Testing
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
SYSTEM TESTING
System Testing is a type of software testing that is performed on a complete integrated system
to evaluate the compliance of the system with the corresponding requirements.
In system testing, integration testing passed components are taken as input. The goal of
integration testing is to detect any irregularity between the units that are integrated together.
System testing detects defects within both the integrated units and the whole system. The result
of system testing is the observed behavior of a component or a system when it is tested.
System Testing is carried out on the whole system in the context of either system requirement
specifications or functional requirement specifications or in the context of both. System testing
tests the design and behavior of the system and also the expectations of the customer. It is
performed to test the system beyond the bounds mentioned in the software requirements
specification (SRS).
System Testing is basically performed by a testing team that is independent of the development
team that helps to test the quality of the system impartial. It has both functional and non-
functional testing.
System Testing is a black-box testing. It is actually a series of different tests whose primary
purpose is to fully exercise the computer based system.
Recovery Testing
Recovery Testing is software testing technique which verifies software's ability to recover
from failures like software/hardware crashes, network failures etc. The purpose of Recovery
Testing is to determine whether software operations can be continued after disaster or
integrity loss. Recovery testing involves reverting back software to the point where integrity
was known and reprocessing transactions to the failure point.
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.
Stress Testing
Stress testing is a software testing activity that determines the robustness of software by
testing beyond the limits of normal operation. Stress testing is particularly important for
"mission critical" software, but is used for all types of software. A most prominent use of stress
testing is to determine the limit, at which the system or software or hardware breaks.
Performance Testing
Performance Testing ensures software applications to perform properly under their expected
workload. It is a testing technique carried out to determine system performance in terms of
sensitivity, reactivity and stability under a particular workload.
Performance Testing is the process of analyzing the quality and capability of a product. It is a
testing method performed to determine the system performance in terms of speed, reliability
and stability under varying workload. Performance testing is also known as Perf Testing.
Deployment Testing
Testing a software project before and after deploying it on production is not that difficult.
But too often, major bugs appear on production server after the deployment process. To avoid
situations in which your production environment is threatened by these bugs, you should use a
streamlined deployment and testing flow.Generally speaking, this flow consists of three
phases: pre-deploy, deploy and post-deploy.
OBSERVABILITY
Observability: Software tests examine the outputs produced by the software for particular
inputs. .... This implies that software is more testable when the tester has the ability to easily
control the software in order to provide the test inputs.
CONTROLABILITY
Controllability: As just mentioned, software testing involves examining outputs for given inputs.
This means that the more easily we can provide inputs to the software, the more easily we
can test the software.
DECOMPOSABILITY
When software can be decomposed into independent modules, these modules can be
tested individually. When an error occurs in an individual module, the error is less likely to
require changes to be made in other modules, or for the tester to even examine multiple
modules.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
SIMPLICITY
Clearly, the simpler the software, the fewer errors it will have, and the easier it will be to
test. There are three forms of simplicity that software can demonstrate: functional
simplicity, in which the software does no more than is needed of it; structural
simplicity, in which the software is decomposed into small, simple units; and code
simplicity, in which the coding standards used be the software team allows for the easy
understanding of the code.
STABILITY
If changes need to be made to the software, then testing becomes easier if these
changes are always contained within independent modules (via, for instance,
decomposability), meaning that the code that needs to be tested remains small.
UNDERSTANDABILITY
Clearly, the more the testers understand the software, the easier it is to test. Much of this
relates to good software design, but also to the engineering culture of the developers:
communication between designers, developers and testers whenever changes occur in
the software is important, as is the ability for the testers and developers to easily access
good technical documentation related to the software (such as APIs for the libraries being
used and the software itself).
It is one of two parts of the Box Testing approach to software testing. Its counterpart,
Blackbox testing, involves testing from an external or end-user type perspective. On the other
hand, Whitebox testing is based on the inner workings of an application and revolves around
internal testing.
White box testing involves the testing of the software code for the following:
Expected output
The functionality of conditional loops
Testing of each statement, object, and function on an individual basis
Path testing is a structural testing method that involves using the source code of a
program in order to find every possible executable path. It helps to determine all faults
lying within a piece of code. This method is designed to execute all or selected path
through a computer program.
Any software program includes, multiple entry and exit points. Testing each of these
points is a challenging as well as time-consuming. In order to reduce the redundant
tests and to achieve maximum test coverage, basis path testing is used.
In software engineering, Basis path testing involves execution of all possible blocks in a
program and achieves maximum path coverage with the least number of test cases. It is a
hybrid method of branch testing and path testing methods.
Here we will take a simple example, to get a better idea what is basis path testing include
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
In the above example, we can see there are few conditional statements that is executed
depending on what condition it suffice. Here there are 3 paths or condition that need to be
tested to get the output,
Path 1: 1,2,3,5,6, 7
Path 2: 1,2,4,5,6, 7
Path 3: 1, 6, 7
1. Condition Testing :
Condition testing is a test cased design method, which ensures that the logical condition and
decision statements are free from errors. The errors present in logical conditions can be
incorrect boolean operators, missing parenthesis in a booleans expression, error in relational
operators, arithmetic expressions, and so on.
The common types of logical conditions that are tested using condition testing are-
1. A relation expression, like E1 op E2 where ‘E1’ and ‘E2’ are arithmetic expressions and
‘OP’ is an operator.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
2. A simple condition like any relational expression preceded by a NOT (~) operator.
For example, (~E1) where ‘E1’ is an arithmetic expression and ‘a’ denotes NOT
operator.
3. A compound condition consists of two or more simple conditions, Boolean operator, and
parenthesis.
For example, (E1 & E2)|(E2 & E3) where E1, E2, E3 denote arithmetic expression and
‘&’ and ‘|’ denote AND or OR operators.
4. A Boolean expression consists of operands and a Boolean operator like ‘AND’, OR,
NOT.
For example, ‘A|B’ is a Boolean expression where ‘A’ and ‘B’ denote operands and |
denotes OR operator.
loop construction.
Following are the types of loops.
1. Simple Loop – The following set of test can be applied to simple loops, where the
maximum allowable number through the loop is n.
1. Skip the entire loop.
2. Traverse the loop only once.
3. Traverse the loop two times.
4. Make p passes through the loop where p<n.
5. Traverse the loop n-1, n, n+1 times.
2. Concatenated Loops – If loops are not dependent on each other, contact loops can be
tested using the approach used in simple loops. if the loops are interdependent, the
steps are followed in nested loops.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
3. Nested Loops – Loops within loops are called as nested loops. when testing nested
loops, the number of tested increases as level nesting increases.
The following steps for testing nested loops are as follows-
1. Start with inner loop. set all other loops to minimum values.
2. Conduct simple loop testing on inner loop.
3. Work outwards.
4. Continue until all loops tested.
4. Unstructured loops – This type of loops should be redesigned, whenever possible, to
reflect the use of unstructured the structured programming constructs.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Functional testing - This black box testing type is related to the functional
requirements of a system; it is done by software testers.
Non-functional testing - This type of black box testing is not related to testing of
specific functionality, but non-functional requirements such as performance, scalability,
usability.
Regression testing - Regression Testing is done after code fixes, upgrades or any
other system maintenance to check the new code has not affected the existing code.
the main focus of black box testing is on the White Box Testing (Unit Testing) validates
validation of your functional requirements. internal structure and working of your software
code
Black box testing gives abstraction from code and To conduct White Box Testing, knowledge of
focuses on testing effort on the software system underlying programming language is essential.
behavior. Current day software systems use a variety of
programming languages and technologies and its
not possible to know all of them.
Black box testing facilitates testing White box testing does not facilitate testing
communication amongst modules communication amongst modules
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Unit V
METRICS FOR PROCESS AND PROJECTS
We’ll now take a closer look at the various types of the two
most important categories of metrics – Project Metrics, and
Process Metrics.
Schedule Variance: Any difference between the scheduled
completion of an activity and the actual completion is known
as Schedule Variance.
Schedule variance = ((Actual calendar days – Planned calendar
days) + Start variance)/ Planned calendar days x 100.
Effort Variance: Difference between the planned outlined effort
and the effort required to actually undertake the task is called
Effort variance.
Effort variance = (Actual Effort – Planned Effort)/ Planned
Effort x 100.
Size Variance: Difference between the estimated size of the
project and the actual size of the project (normally in KLOC or
FP).
Size variance = (Actual size – Estimated size)/ Estimated size x
100.
Requirement Stability Index: Provides visibility to the
magnitude and impact of requirements changes.
RSI = 1- ((Number of changed + Number of deleted + Number
of added) / Total number of initial requirements) x100.
Productivity (Project): Is a measure of output from a related
process for a unit of input.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Establishing a Baseline
By establishing a metrics baseline, benefits can be obtained at
the process, project, and product (technical) levels. Yet the
information that is collected need not be fundamentally
different.
The same metrics can serve many masters.
The metrics baseline consists of data collected from past
software development projects To be an effective aid in
process improvement and/or cost and effort estimation,
baseline data must have the following attributes:
data must be reasonably accurate—"guestimates" about past
projects are to be avoided;
data should be collected for as many projects as possible;
measures must be consistent, for example, a line of code must
be interpreted consistently across all projects for which data
are collected;
applications should be similar to work that is to be
estimated—it makes little sense to use a baseline for batch
information systems work to estimate a realtime, embedded
application.
Metrics Collection, Computation, and Evaluation
Ideally, data needed to establish a baseline has been collected
in an ongoing manner.
Sadly, this is rarely the case. Therefore, data collection requires
a historical investigation of past projects to reconstruct
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
It means “the services that are given, and the means by which
customers or consumers access these services ” are defined as a part
of the component interface.
Component Adaptation:
This activity ensures that the architecture defines the design
conditions for all component and identifying their modes of
connection.
In some of the cases, existing reusable components may not be
allowed to get used due to the architecture’s design rules and
conditions.
These components should adapt and meet the requirements of the
architecture or refused and replaced by other, more suitable
components.
Component Composition:
This activity ensures that the Architectural style of the system
integrates the software components and form a working system.
By identifying connection and coordination mechanisms of the
system, the architecture describes the composition of the end
product.
Component Update:
This activity ensures the updation of reusable components.
Sometimes, updates are complicated due to inclusion of third party
(the organization that developed the reusable component may be
outside the immediate control of the software engineering
organization accessing the component currently.)
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
6. TheCBSE process
CBSE processes are software processes that support
component-based software engineering.
They take into account the possibilities of reuse and the
different process activities involved in developing and using
reusable components.
There are two types of CBSE processes:
CBSE for reuse is concerned with developing components or
services that will be reused in other applications.
It usually involves generalizing existing components.
CBSE with reuse is the process of developing new applications
using existing components and services.
CBSE for reuse focuses on component and service development.
Components developed for a specific application usually have
to be generalised to make them reusable.
A component is most likely to be reusable if it associated with a
stable domain abstraction (business object).
For example, in a hospital stable domain abstractions are
associated with the fundamental purpose - nurses, patients,
treatments, etc.
Component reusability:
Should reflect stable domain abstractions;
Should hide state representation;
Should be as independent as possible;
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
7. Domain engineering
It's also called product line engineering, is the entire process of
reusing domain knowledge in the production of new software
systems.
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Minimized delivery:
Search in component catalogs
Recycling of pre-fabricated components
Improved efficiency:
Developers concentrate on application development
Improved quality:
Bachelor of Engineering (Computer Science & Engineering)
Course Code: CS107 Course Name: Object Oriented Software Engineering
Minimized expenditures
The specific routines of CBD are:
Component development
Component publishing
Component lookup as well as retrieval
Component analysis
Component assembly
Cost. The net cost savings for reuse are estimated by projecting
the cost of the project if it were developed from scratch, Cs, and
then subtracting the sum of the costs associated with reuse, Cr,
and the actual cost of the software as delivered,
Cd. Cs can be determined by applying one or more of the
estimation techniques The costs associated with reuse, Cr,
include