Practical-1 Aim: - Study and Usage of Openproj or Similar Software To Draft A Project Plan. Introduction
Practical-1 Aim: - Study and Usage of Openproj or Similar Software To Draft A Project Plan. Introduction
Practical-1
Aim: - Study and usage of OpenProj or similar software to draft a project
plan.
Introduction: - Project managers can use OpenProj, a free task tracking application, when
creating effective plans. OpenProj delivers functionality that rivals the capabilities of
commercial software. This can save thousands of dollars in startup costs. Of course, saving a
lot of money can be foolish if the required tasks can't be done. This is not the case with
OpenProj. Luckily the OpenProj application gives managers a full set of tools that are
typically used to track projects. Useful aids such as critical path analysis, resource tracking
and task comments are all present in OpenProj. The tool is ideal for simple project
management but is capable of larger efforts as well.
Fig no: -1
For the purposes of the example project plan, the following assumptions are made:
-The OpenProj software has already been installed and correctly configured on a workstation
with an attached printer
- The goal is to launch a new marketing effort in 6 months, called "Anganwadi"
- There are three full-time staff resources, including the manager
- Budget is not a consideration
- Schedule is the primary consideration
- The target implementation date is 6 months away but is not an absolute fixed date
www.ahirlabs.com 1
Software Engineering Lab/BTCS606
Fig no: -2
Fig no: -3
www.ahirlabs.com 2
Software Engineering Lab/BTCS606
are based on the values previously seen for similar tasks. There is no ordering of tasks or
dependencies. The raw Gantt list is below.
Notice that the task "Application Development" is shown with a red duration bar while all
other tasks have blue bars. This task is identified as the project critical path. It is the longest
running task in the project. Since all tasks default to the start date of the project, the analysis
of the critical path is quite premature at this time. The project manager must now modify
dependencies.
Fig no: -4
www.ahirlabs.com 3
Software Engineering Lab/BTCS606
Fig no: -5
Step 6: Task elaboration
An important feature of project management applications is the ability to allow the manager
to split tasks into smaller sub-tasks. This can allow better accuracy in schedule estimating. It
also allows team members to be specified in a just-in-time fashion for their assignments. The
example project has some opportunities for task elaboration.
Fig no: -6
Step 7: Evaluate the project plan
With all of the tasks entered, and sub-tasks specified, the plan has really evolved. It now
shows a lot of information which can be useful in project reporting. The first item is the
critical path. This of the highest importance to the project manager and the organization.
Reports showing the tasks can be presented to company executives. An analysis of work
loads can be done. Task reports can be printed. In time, as completion percentages are entered
for tasks, the project manager can run status reports showing progress and schedule tracking.
www.ahirlabs.com 4
Software Engineering Lab/BTCS606
Practical-2
Aim: - Study and usage of Openproj to track the progress of a project.
Finding the right project management solution for your team can be very hard. Finding an
open source project management solution may be even harder. That's the mission of solution
that allows teams to collaborate throughout the project life cycle. Additionally, the project
aims to replace proprietary software like Microsoft Project Server or Jira.
Mission of OpenProject
The mission of OpenProject can be quickly summarized: we want to build excellent open
source project collaboration software. And when I say open source, I meant it. We strive to
make OpenProject a place to participate, collaborate, and get involved—with an active, open-
minded, transparent, and innovative community.
Companies have finally become aware of the importance of project management software
and also the big advantages of open source. But why is it that project teams still tend to
switch to old-fashioned ways of creating project plans, task lists, or status reports with Excel,
PowerPoint, or Word—or having other expensive proprietary project management software
in use? We want to offer a real open source alternative for companies: free, secure, and easy
to use.
www.ahirlabs.com 5
Software Engineering Lab/BTCS606
www.ahirlabs.com 6
Software Engineering Lab/BTCS606
www.ahirlabs.com 7
Software Engineering Lab/BTCS606
Practical: - 3
Aim: - Preparation of Software Requirement Specification Document,
Design Documents and Testing Phase related documents for some
problems.
SRS: - An SRS minimizes the time and effort required by developers to achieve desired goals
and also minimizes the development cost. A good SRS defines how an application will
interact with system hardware, other programs and human users in a wide variety of real-
world situations. Parameters such as operating speed, response time, availability, portability,
maintainability, footprint, security and speed of recovery from adverse events are evaluated.
Methods of defining an SRS are described by the IEEE (Institute of Electrical and Electronics
Engineers) specification 830-1998.
Qualities of SRS: -
Correct
Unambiguous
Complete
Consistent
Ranked for importance and/or stability
Verifiable
Modifiable
Traceable
The below diagram depicts the various types of requirements that are captured during SRS.
www.ahirlabs.com 8
Software Engineering Lab/BTCS606
ABSTRACT
"Blog" is an abbreviated version of "weblog," which is a term used to describe websites that
maintain an ongoing chronicle of information. A blog features diary-type commentary and
links to articles on other websites, usually presented as a list of entries in reverse
chronological order.
www.ahirlabs.com 9
Software Engineering Lab/BTCS606
4. Blogs can make money. Along with your product or service, blogs can generate income from
other options, such as advertising and affiliate products.
Project Introduction
Project is based on transaction and its management .The objectives of project are to maintain
transaction management and concurrency control .Basically project is based on real world
problem which is related to banking and transaction .It also provide security features related
to database like only authenticated accountant or user can access the database or perform the
transaction .
It is based on banking so it is related to accountant and customers which are the naïve users.
In this there are two types of GUI for different users and they provide different external views.
It holds the feature of database sharing. In this if two different users can perform concurrently
if they are authorized users and have the permissions to access the database .Basically it is
based on database sharing and transaction management of concurrency control.
Firstly accountant end work as the admin in this project. To add new user there any
accountant who add that account and person detail in the database and then there is key
generate to access the database with the password for the naïve users .With the help of that
key and password user can access the details and can perform the transaction on database
with very user friendly GUI.
On other end accountant has some more facilities like to update the details of the users .To
update any detail of the user then accountant is the person who can perform this task not the
naïve user. Accountant the person who can close the account of any customer who want to
close his or her account .After closing the detail of account is remain in database for some
period of time .With the trigger action after particular time period the data is automatically
deleted permanently.
www.ahirlabs.com 10
Software Engineering Lab/BTCS606
Project is based on transaction and its management .The objectives of project are to maintain
transaction management and concurrency control .Basically project is based on real world
problem which is related to banking and transaction .It also provide security features related
to database like only authenticated accountant or authenticated user can access the database
or perform the transaction..
NETBANK objectives
It ensures to provide transaction management and concurrency control.
It ensure to prevent the database problems like lost update, dirty read and unrepeatable read
etc.
It provide the concurrency control features.
This help to provide the security features like authentication ,authorization etc.
It ensures to provide different type of views at external level.
This project provides two different sides for two different types of users in the bank like
accountants and naïve users.
It provides very user friendly GUI for different type of users.
It provides the database sharing concept by using some networking concepts.
It ensures that the sharing of the database only between the authorized users.
www.ahirlabs.com 11
Software Engineering Lab/BTCS606
Overall Description
www.ahirlabs.com 12
Software Engineering Lab/BTCS606
We will use SDLC (System Development Life Cycle) approach to make project as it is
the easiest and most commonly method of making project. We will try to make a project
which will provide a convenient and interesting way for studying any subject. The main
objective of the system design is to make the system user friendly.
• The problem was analyzed and then design was prepared. Then we implemented this
design through coding and then testing is done. If any errors were found then we have
tried our best to remove them and then again testing was done so that we can remove all
the errors of our project. This project will be maintained and upgraded time to time so
that we can provide proper and latest notes to all the users of this tutorial.
www.ahirlabs.com 13
Software Engineering Lab/BTCS606
REQUIREMENTS SPECIFICATION
Prior to the software development efforts in any type of system it is very essential to
understand the requirements of the system and users. A complete specification of the
software is the 1st step in the analysis of system. Requirements analysis provides the designer
with the representation of function and procedures that can be translated into data,
architecture and procedural design. The goal of requirement analysis is to find out how
current system is working and of there are any areas where improvement is necessary and
possible.
INTERFACE REQUIREMENTS: -
1.) User Interface The packet must be user friendly and robust. It must prompt the user with
proper message boxes to help them perform various actions and how to precede further
the system must respond normally under any input conditions and display proper message
instead of turning up faults and errors
2.) Software Specification Software is a set of program, documents, and procedure, routines
associated with computer system. Software is an essential complement to hardware. It is
the computer programs, when executed operates the hardware.
SYSTEM DESIGN: -
System design is the process of developing specifications for a candidate system that meet the
criteria established in the system analysis. Major step in system design is the preparation of
the input forms and the output reports in a form applicable to the user. The main objective of
the system design is to make the system user friendly.
DATABASE DESIGN: -
The overall objective in the development of the database technology has been to treat data as
an organizational resource and as an integrated whole. Database management system allows
data to be protected and organize separately from other resources. Database is an integrated
collection of data. The most significant of data as seen by the programs and data as stored on
the direct storage access storage devices. This is the difference between logical and physical
data.
The organization of data in the database aims to achieve three major objectives:
• Data Integration
• Data Integrity
• Data Independence
www.ahirlabs.com 14
Software Engineering Lab/BTCS606
Methodology
The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements is
gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral. It’s one of
the software development models like Waterfall, V-Model.
www.ahirlabs.com 15
Software Engineering Lab/BTCS606
www.ahirlabs.com 16
Software Engineering Lab/BTCS606
FEASIBILITY ANALYSIS
A feasibility study is an analysis of how successfully a project can be completed, accounting
for factors that affect it such as economic, technological, legal and scheduling factors. Project
managers use feasibility studies to determine potential positive and negative outcomes of a
project before investing a considerable amount of time and money into it.
• ECONOMICAL: -
Keeping all these needs and demands of system in minimum budget we developed new
software which will not only lower their budget but also not require much cost to accept it.
Keeping all these needs and demands of system in minimum budget we developed new
software which will not only lower their budget but also not require much cost to accept it.
The new system will save the money, which they are investing on getting short codes, thus
keeping all these good qualities is an economic feasibility.
• OPERATIONAL : -
The basic question that you are trying to answer is “Is it possible to maintain and support this
application once it is in production?” we developed a system which does not require any
extra technical skill and training. It is developed using such environment, which are quite
familiar to most of the people concerned with the system. The new system will prove easy to
operate because it is developed in such a way so that it will prove user friendly. User will find
it quite familiar and easy to operate.
• BEHAVIOURAL : -
o Feasibility in terms of behavior of its employees.
o It reflects the behavior of the employees of an organization.
o Main focus is on teamwork and harmony among employees with no room for
discrimination and hatred.
Benefits of Conducting Feasibility Study: -
The importance of a feasibility study is based on organizational desire to “get it right”
before committing resources, time, or budget. A feasibility study might uncover new
ideas that could completely change a project’s scope. It’s best to make these
determinations in advance, rather than to jump in and learning that the project just
won’t work. Conducting a feasibility study is always beneficial to the project as it
gives you and other stakeholders a clear picture of the proposed project.
Below are some key benefits of conducting a feasibility study:
Improves project teams’ focus.
• Identifies new opportunities.
• Provides valuable information for a “go/no-go” decision.
www.ahirlabs.com 17
Software Engineering Lab/BTCS606
Schedule Of documents: -
www.ahirlabs.com 18
Software Engineering Lab/BTCS606
Design Documents: -
A software design document (SDD) is a written description of a software product, that a
software designer writes in order to give a software development team overall guidance to the
architecture of the software project. An SDD usually accompanies an architecture diagram
with pointers to detailed feature specifications of smaller pieces of the design. Practically, a
design document is required to coordinate a large team under a single vision.
A design document needs to be a stable reference, outlining all parts of the software and how
they will work. The document is commanded to give a fairly complete description, while
maintaining a high-level view of the software.
There are two kinds of design documents called HLDD (high-level design document) and
LLDD (low-level design document).
It includes description of the body and soul of the entire project, with all the details, and the
method by which each element will be implemented. It ensures that what is produced is what
you want to produce.
Disadvantages of DFDs: -
Modification to a data layout in DFDs may cause the entire layout to be changed. This is
because the specific changed data will bring different data to units that it accesses.
Therefore, evaluation of the possible of the effect of the modification must be considered
first.
The number of units in a DFD in a large application is high. Therefore, maintenance is
harder, more costly and error prone. This is because the ability to access the data is passed
explicitly from one component to the other. This is why changes are impractical to be
made on DFDs especially in large system.
DFDs are inappropriate to use in a large system because if changes are to be made on a
specific unit, there is a possibility that the whole DFD need to be changed. This is
www.ahirlabs.com 19
Software Engineering Lab/BTCS606
because the change may result in different data flow into the next unit. Therefore, the
whole application or system may need modification too.
LEVEL 0: -
The first thing we must do is model the main outputs and sources of data in the scenario
above. Then we draw the system box and name the system. Next we identify the information
that is flowing to the system and from the system.
LEVEL 1: -
The next stage is to create the Level 1 Data Flow Diagram. This highlights the main functions
carried out by the system as follows:
www.ahirlabs.com 20
Software Engineering Lab/BTCS606
LEVEL 2: -
We now create the Level 2 Data Flow Diagrams. First 'expand' the function boxes 1.1 and 1.2
so that we can fit the process boxes into them. Then position the data flows from Level 1 into
the correct process in Level 2 as follows:
www.ahirlabs.com 21
Software Engineering Lab/BTCS606
www.ahirlabs.com 22
Software Engineering Lab/BTCS606
The length of any function should not exceed 10 source lines: - A function that
is very lengthy is usually very difficult to understand as it probably carries out many different
functions. For the same reason, lengthy functions are likely to have disproportionately larger
number of bugs.
Do not use an identifier for multiple purposes: - Programmers often use the same
identifier to denote several temporary entities. For example programmers use a temporary
loop variable for computing and a storing the final result. The rationale that is usually given
by these programmers for such multiple uses of variables is memory efficiency, e.g. three
variables use up three memory locations, whereas the same variable used in three different
ways uses just one memory location. However, there are several things wrong with this
approach and hence should be avoided. Some of the problems caused by use of variables for
multiple purposes as follows:
• Each variable should be given a descriptive name indicating its purpose. This is not possible
if an identifier is used for multiple purposes. Use of a variable for multiple purposes can lead
to confusion and make it difficult for somebody trying to read and understand the code.
• Use of variables for multiple purposes usually makes future enhancements more difficult.
Do not use goto statements: - Use of go to statements makes a program unstructured
and makes it very difficult to understand.
Code review: - Code review for a model is carried out after the module is successfully
compiled and the all the syntax errors have been eliminated. Code reviews are extremely
cost-effective strategies for reduction in coding errors and to produce high quality code.
Normally, two types of reviews are carried out on the code of a module. These two types
code review techniques are code inspection and code walk through.
Code Walk Throughs: - Code walk through is an informal code analysis technique. In
this technique, after a module has been coded, successfully compiled and all syntax errors
eliminated. A few members of the development team are given the code few days before the
walk through meeting to read and understand code. Each member selects some test cases and
simulates execution of the code by hand (i.e. trace execution through each statement and
function execution). The main objectives of the walk through are to discover the algorithmic
and logical errors in the code. The members note down their findings to discuss these in a
walk through meeting where the coder of the module is present.
Even though a code walks through is an informal analysis technique, several guidelines have
evolved over the years for making this naïve but useful analysis technique more effective. Of
course, these guidelines are based on personal experience, common sense, and several
subjective factors. Therefore, these guidelines should be considered as examples rather than
accepted as rules to be applied dogmatically. Some of these guidelines are the following.
• The team performing code walk through should not be either too big or too small. Ideally,
it should consist of between three to seven members.
• Discussion should focus on discovery of errors and not on how to fix the discovered errors.
• In order to foster cooperation and to avoid the feeling among engineers that they are being
evaluated in the code walk through meeting, managers should not attend the walk through
meetings.
Code Inspection: - In contrast to code walk through, the aim of code inspection is to
discover some common types of errors caused due to oversight and improper programming.
In other words, during code inspection the code is examined for the presence of certain kinds
of errors, in contrast to the hand simulation of code execution done in code walk throughs.
For instance, consider the classical error of writing a procedure that modifies a formal
www.ahirlabs.com 23
Software Engineering Lab/BTCS606
parameter while the calling routine calls that procedure with a constant actual parameter. It is
more likely that such an error will be discovered by looking for these kinds of mistakes in the
code, rather than by simply hand simulating execution of the procedure. In addition to the
commonly made errors, adherence to coding standards is also checked during code inspection.
Good software development companies collect statistics regarding different types of errors
commonly committed by their engineers and identify the type of errors most frequently
committed. Such a list of commonly committed errors can be used during code inspection to
look out for possible errors.
Following is a list of some classical programming errors which can be checked during code
inspection:
Use of uninitialized variables.
Jumps into loops.
Non terminating loops.
Incompatible assignments.
Array indices out of bounds.
Improper storage allocation and deallocation.
Mismatches between actual and formal parameter in procedure calls
Use of incorrect logical operators or incorrect precedence among operators.
Improper modification of loop variables.
Comparison of equally of floating point variables, etc.
www.ahirlabs.com 24
Software Engineering Lab/BTCS606
Practical 4
Aim: - Preparation of the Software Configuration management and Risk
management related documents.
SCM is also known as software control management. SCM aims to control changes introduced to
large complex software systems through reliable version selection and version control.
The SCM system has the following advantages:
Reduced redundant work.
Effective management of simultaneous updates.
Avoids configuration-related problems.
Facilitates team coordination.
Helps in building management; managing tools used in builds.
Defect tracking: It ensures that every defect has traceability back to its source.
Benefits of Software Configuration Management
SCM provides significant benefits to all projects regardless of size, scope, and complexity.
Some of the most common benefits experienced by project teams applying the SCM
disciplines described in this guide are possible because the SCM system:
Organization
Being that Configuration Management is like the framework for greater information
management programs, it should go without saying that it is critical for greater
management and organization of information as a whole. With a well-ordered system in
place, a good IT worker should be able to see all of the past system implementations of
the business, and can better address future needs and changes to keep the system up to
date and running smoothly.
Reliability
Nothing is worse than an unreliable system that is constantly down and needing repairs
because a company’s configuration management team is lacking in organization and
pro-activeness. If the system is used correctly, it should run like the well-oiled machine
that it is, ensuring that every department in the company can get their jobs done
properly. Increased stability and efficiency of the system will trickle down into every
division of a company, including customer relations, as the ease and speed in which
their problems can be solved and information can be accessed will surely make a
positive impact.
Cost Reduction and Risks
Like anything else in business, a lack of maintenance and attention to details can have
greater risks and cost down the line, as opposed to proactive action before a problem
arises. Configuration Management saves money with the constant system maintenance,
record keeping, and checks and balances to prevent repetition and mistakes. The
organized record keeping of the system itself saves time for the IT department and
reduces wasted money for the company with less money being spent on fixing recurring
or nonsensical issues.
www.ahirlabs.com 25
Software Engineering Lab/BTCS606
SCM Process
The software configuration management process defines a series of tasks that have four primary
objectives:
1. To identify all the items that collectively defines the software configuration.
2. To manage changes to one or more of these items.
3. To facilitate the construction of different versions of an application.
4. To ensure that software quality is maintained as the configuration evolves over time.
www.ahirlabs.com 26
Software Engineering Lab/BTCS606
www.ahirlabs.com 27
Software Engineering Lab/BTCS606
Practical: - 5
Aim: - Study and usage of any Design phase CASE tool.
CASE Tools: -
CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools. CASE tools
are set of software application programs, which are used to automate the SDLC activities.
CASE tools are used by software project managers, analysts and engineers to develop
software system.
Reasons for using case tools:
• The primary reasons for using a CASE tool are:
– To increase productivity
– To help produce better quality software at lower cost
– To decrease the development time and cost.
• Various tools are incorporated in CASE and are called CASE tools, which are used to
support different stages and milestones in a software development lifecycle.
Architecture Of CASE tools: -
Figure: - 5.1
• Layer 1 is the user interface whose function is to help the user to interact with core of
the system. It provides a graphical user interface to users using which interaction with the
system become easy.
• Layer 2 depicts tool management system (TMS) which constitutes multiple tools of
different category using which automation of the development process can be done. TMS
may include some tools to draw diagrams or to generate test cases.
• Layer 3 represents object management system (OMS) which represents the set of objects
generated by the users. Group of design notations, set of test cases (test suite) are treated
as the objects.
• Layer 4 represents a repository which stores the objects developed by the user. Layer 4 is
nothing but a database which stores automation files.
Components of CASE Tools: - CASE tools can be broadly divided into the following
parts based on their use at a particular SDLC stage:
www.ahirlabs.com 28
Software Engineering Lab/BTCS606
Central Repository - CASE tools require a central repository, which can serve as a
source of common, integrated and consistent information. Central repository is a central
place of storage where product specifications, requirement documents, related reports and
diagrams, other useful information regarding management are stored. Central repository
also serves as data dictionary.
Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages
of SDLC.
Lower Case Tools - Lower CASE tools are used in the implementation, testing and
maintenance stages.
Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and documentation.
Figure: - 5.2
www.ahirlabs.com 29
Software Engineering Lab/BTCS606
analysis. By its very nature, a CASE tool provides the vehicle for managing more
effectively the development activities of a project.
2. System Quality is improved: CASE tools promote standards within a development
environment. The use of graphical tools to specify the requirements of a system can also
help remove the ambiguities that often lead to poorly defined systems. Therefore, if used
correctly, a CASE tool can help improve the quality of the specification, the subsequent
design and the eventual working system.
3. Consistency checking is automated: Large amounts of information about a business
area and its requirement are gathered during the analysis phase of an information systems
development project. Using a manual system to record and cross reference this
information is both time-consuming and inefficient. One of the advantages of using
CASE tool is that all data definitions and other relevant information can be stored in a
central repository that can then be used to cross check the consistency of the different
views being modelled.
4. Productivity is increased: One of the most obvious benefits of a CASE tool is that it
may increase the productivity of the analysis team. If used properly, the CASE tool will
provide a support environment enabling analysts to share information and resources,
manage the project effectively and produce supporting documentation quickly.
5. The maintenance effort is better supported: It has been argued that CASE tools help
reduce the maintenance effort required to support the system once it is operational. CASE
tools can be used to provide comprehensive and up-to-date documentation – this is
obviously a critical requirement for any maintenance effort. CASE tools should result in
better systems being developed in the first place.
www.ahirlabs.com 30
Software Engineering Lab/BTCS606
Practical: - 6
Aim: -To perform unit testing and integration testing.
Unit Testing:- Unit testing, a testing technique using which individual modules are tested
to determine if there are any issues by the developer himself. It is concerned with functional
correctness of the standalone modules. The main aim is to isolate each unit of the system to
identify, analyze and fix the defects.
Figure: - 6.1
www.ahirlabs.com 31
Software Engineering Lab/BTCS606
Not all errors can be detected, since every module it tested separately and later
different integration bugs may appear.
Testing will not catch every error in the program, because it cannot evaluate every
execution path in any but the most trivial programs. This problem is a superset of
the halting problem, which is un decidable.
The same is true for unit testing. Additionally, unit testing by definition only tests
the functionality of the units themselves. Therefore, it will not catch integration
errors or broader system-level errors (such as functions performed across multiple
units, or non-functional test areas such as performance).
Unit testing should be done in conjunction with other software testing activities, as
they can only show the presence or absence of particular errors; they cannot prove a
complete absence of errors.
To guarantee correct behaviour for every execution path and every possible input,
and ensure the absence of errors, other techniques are required, namely the
application of formal methods to proving that a software component has no
unexpected behaviour.
Unit Testing Techniques:
1. Black Box Testing - Using which the user interface, input and output are tested.
2. White Box Testing - used to test each one of those functions behavior is tested.
3. Gray Box Testing - Used to execute tests, risks and assessment methods.
Integration Testing:- It tests integration or interfaces between components, interactions
to different parts of the system such as an operating system, file system and hardware or
interfaces between systems.
Also after integrating two different components together we do the integration testing.
As displayed in the image below when two different modules ‘Module A’ and
‘Module B’ are integrated then the integration testing is done.
www.ahirlabs.com 32
Software Engineering Lab/BTCS606
.
Fig 6.4
Advantage: Big Bang testing has the advantage that everything is finished before
integration testing starts.
Disadvantage: The major disadvantage is that in general it is time consuming and difficult
to trace the cause of failures because of this late integration.
2. Top-down integration testing: Testing takes place from top to bottom, following
the control flow or architectural structure (e.g. starting from the GUI or main menu).
Components or systems are substituted by stubs. Below is the diagram of ‘Top down
Approach”
Fig 6.5
Advantages of Top-Down approach:
The tested product is very consistent because the integration testing is basically
performed in an environment that almost similar to that of reality
Stubs can be written with lesser time because when compared to the drivers then Stubs
are simpler to author.
www.ahirlabs.com 33
Software Engineering Lab/BTCS606
Fig 6.6
Advantage of Bottom-Up approach:
In this approach development and testing can be done together so that the product or
application will be efficient and as per the customer specifications.
System Testing: - System Testing (ST) is a black box testing technique performed to
evaluate the complete system the system's compliance against specified requirements. In
System testing, the functionalities of the system are tested from an end-to-end perspective.
System Testing is usually carried out by a team that is independent of the development team
in order to measure the quality of the system unbiased. It includes both functional and Non-
Functional testing.
Fig 6.7
www.ahirlabs.com 34
Software Engineering Lab/BTCS606
Practical No. 07
Aim: - To perform various white box and black box testing techniques.
White Box Testing: -
White Box Testing is the testing of a software solution's internal coding and infrastructure. It
focuses primarily on strengthening security, the flow of inputs and outputs through the
application, and improving design and usability. White box testing is also known as Clear
Box testing, Open Box testing, Structural testing, Transparent Box testing, Code-Based
testing, and Glass Box testing.
It is one of two parts of the "box testing" approach of software testing. Its counter-part,
black box testing, involves testing from an external or end-user type perspective. On the other
hand, White box testing is based on the inner workings of an application and revolves around
internal testing.
The term "white box" was used because of the see-through box concept. The clear box or
white box name symbolizes the ability to see through the software's outer shell (or "box")
into its inner workings. Likewise, the "black box" in "Black Box Testing" symbolizes not
being able to see the inner workings of the software so that only the end-user experience can
be tested.
www.ahirlabs.com 35
Software Engineering Lab/BTCS606
www.ahirlabs.com 36
Software Engineering Lab/BTCS606
Unit Testing: It is often the first type of testing done on an application. Unit testing is
performed on each unit or block of code as it is developed. Unit Testing is essentially done by
the programmer. As a software developer, you develop a few lines of code, a single function
or an object and test it to make sure it works before continuing. Unit testing helps identify
majority of bugs, early in the software development lifecycle. Bugs identified in this stage are
cheaper and easy to fix.
Testing for Memory Leaks: - Memory leaks are the most important causes of slower
running applications. A QA specialist who is experienced at detecting memory leaks is
essential in cases where you have a slow running software application. There are many tools
available to assist developers/testers with memory leak testing, example, Rational Purify for
windows application. Apart from above a few testing types are part of both black box and
white box testing. They are listed as below:
White Box Penetration Testing: In this testing, the tester/developer has full information of
the application's source code, detailed network information, IP addresses involved and all
server information the application runs on. The aim is to attack the code from several angles
to expose security threats
White Box Mutation Testing: Mutation testing is often used to discover the best coding
techniques to use for expanding a software solution.
Integration Testing: - Integration testing is a level of software testing where individual units
are combined and tested as a group. The purpose of this level of testing is to expose faults in
the interaction between integrated units. Test drivers and test stubs are used to assist in
Integration Testing.
Advantages of White Box Testing: -
Code optimization by finding hidden errors.
White box tests cases can be easily automated.
Testing is more thorough as all code paths are usually covered.
Testing can start early in SDLC even if GUI is not available.
Disadvantages of White Box Testing: -
White box testing can be quite complex and expensive.
Developers who usually execute white box test cases detest it. The white box testing by
developers is not detailed can lead to production errors.
www.ahirlabs.com 37
Software Engineering Lab/BTCS606
www.ahirlabs.com 38
Software Engineering Lab/BTCS606
or not. It is very useful in reducing the number of test cases. It is mostly suitable for the
systems where input is within certain ranges.
Decision Table Testing: A decision table puts causes and their effects in a matrix. There
is unique combination in each column.
www.ahirlabs.com 39