software build history dossier for development and...
TRANSCRIPT
Software Build History Dossier forDevelopment and Testing
By
Muhammad Nouman
NUST201260828MSEECS63012F
Supervisor
Dr. Osman Hasan
Department of Electrical Engineering
A thesis submitted in partial fulfillment of the requirements for the degree
of Masters in Computer and Communication Security (MS CCS)
In
School of Electrical Engineering and Computer Science,
National University of Sciences and Technology (NUST),
Islamabad, Pakistan.
(July 2016)
Approval
It is certified that the contents and form of the thesis entitled “Software
Build History Dossier for Development and Testing” submitted by
Muhammad Nouman have been found satisfactory for the requirement of
the degree.
Advisor: Dr. Osman Hasan
Signature:
Date:
Committee Member 1: Dr. Kashif Saghar
Signature:
Date:
Committee Member 2: Dr. Adnan Khalid
Signature:
Date:
Committee Member 3: Mr. Taufique ur Rahman
Signature:
Date:
i
Abstract
Project management is an organized approach to planning and guiding project
processes from the beginning to the end. It determines the success of a par-
ticular project and only through good management it becomes possible to
accomplish deadlines and final objectives. Software development life cycle
activity encompasses, requirement analysis, design, implementation, test-
ing and evolution and, like every other project execution, required formal
management. Software project management ensures that all the phases of
software development life cycle (SDLC) have been applied as per standards.
To facilitate software project management, this paper presents a software
tool called the Software Build History Dossier (SBHD), which covers all the
requirements of SDLC. The main task of the proposed tool is to ensure
completeness and organization of software build related documents in an
organizational setup.
ii
Dedication
I dedicate this thesis to my parents.
iii
Certificate of Originality
I hereby declare that this submission is my own work and to the best of my
knowledge it contains no materials previously published or written by another
person, nor material which to a substantial extent has been accepted for the
award of any degree or diploma at NUST SEECS or at any other educational
institute, except where due acknowledgement has been made in the thesis.
Any contribution made to the research by others, with whom I have worked
at NUST SEECS or elsewhere, is explicitly acknowledged in the thesis.
I also declare that the intellectual content of this thesis is the product
of my own work, except for the assistance from others in the project’s de-
sign and conception or in style, presentation and linguistics which has been
acknowledged.
Author Name: Muhammad Nouman
Signature:
iv
Acknowledgment
First of all I am thankful to Almighty Allah for giving me strength and
courage to complete this challenging task. I am grateful to my family and
especially parents who always stand with me through thick and thin of this
prolonged task.
I am really thankful to Dr. Osman Hassan, for his valuable suggestion
and continuous guidance throughout the thesis. I am grateful to Dr. Adnan
Khalid, Dr. Taufique-ur-Rahman and NESCOM team, especially Dr. Kashif
Saghar, Ainan, Asim and Daniyal for their help and positive criticism to
make the software better and as per expectations. Without their guidance
it won’t be possible to complete it within strict time constraints. I am really
thankful to Iqra for her continuous support especially in the beginning of
designing and implementation afterwards.
Last but not least I am thankful to all the SAVE lab members who keeps
me motivated throughout thesis.
v
Table of Contents
1 Introduction 1
1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . 3
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Proposed Approach . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Literature Review 9
3 Comparison 14
4 Functionality of Software Build History Dossier 16
4.1 Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Project Director . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Project Manager . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Employee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Software Development Life Cycle 23
5.1 Requirement Specification . . . . . . . . . . . . . . . . . . . . 23
5.1.1 Functional Requirements . . . . . . . . . . . . . . . . . 23
5.2 Use Case Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1 Use Case Diagrams of the system . . . . . . . . . . . . 28
vi
TABLE OF CONTENTS vii
5.2.2 Use Case Diagrams for Admins . . . . . . . . . . . . . 29
5.2.3 Use Case Diagrams for Project Director . . . . . . . . 35
5.2.4 Use Case Diagrams for Project Manager . . . . . . . . 42
5.2.5 Use Case Diagrams for Employee . . . . . . . . . . . . 43
5.2.6 Entity Relationship Diagram of the System . . . . . . . 47
5.2.7 Non-Functional Requirements . . . . . . . . . . . . . . 47
5.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1 Structural Design: Class Diagram . . . . . . . . . . . . 53
5.3.2 Behavioral design: Message Sequence Diagrams . . . . 69
5.3.3 Behavioral design: System Sequence Diagrams . . . . . 91
5.3.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.3.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . 119
5.3.6 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . 119
5.3.7 Technology Used . . . . . . . . . . . . . . . . . . . . . 121
6 Conclusions 122
6.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
List of Figures
2.1 Software Quality Assurance Attirbutes . . . . . . . . . . . . . 11
4.1 Windows Form for Admin . . . . . . . . . . . . . . . . . . . . 18
4.2 Windows Form for Project Director . . . . . . . . . . . . . . . 19
4.3 Windows Form for Project Manager . . . . . . . . . . . . . . . 20
4.4 Windows Form for Employee . . . . . . . . . . . . . . . . . . . 21
5.1 Use Case Diagram of system . . . . . . . . . . . . . . . . . . . 29
5.2 Use Case Diagram of Creating Repository . . . . . . . . . . . 30
5.3 Use Case Diagram of User Management . . . . . . . . . . . . . 31
5.4 Use Case Diagram of Role Management . . . . . . . . . . . . . 32
5.5 Use Case Diagram of Reporting Department . . . . . . . . . . 33
5.6 Use Case Diagram of Designers . . . . . . . . . . . . . . . . . 34
5.7 Use Case Diagram of Job Types- Test Cases- Sub Tests . . . . 35
5.8 Use Case Diagram of Project . . . . . . . . . . . . . . . . . . 36
5.9 Use Case Diagram of System . . . . . . . . . . . . . . . . . . . 37
5.10 Use Case Diagram of Version . . . . . . . . . . . . . . . . . . 38
5.11 Use Case Diagram of Certificates . . . . . . . . . . . . . . . . 39
5.12 Use Case Diagram of Letters . . . . . . . . . . . . . . . . . . . 40
5.13 Use Case Diagram of Document . . . . . . . . . . . . . . . . . 41
5.14 Use Case Diagram of Job . . . . . . . . . . . . . . . . . . . . . 42
viii
LIST OF FIGURES ix
5.15 Use Case Diagram of Job Display . . . . . . . . . . . . . . . . 43
5.16 Use Case Diagram of Starting a Job . . . . . . . . . . . . . . . 44
5.17 Use Case Diagram of Submitting a Job . . . . . . . . . . . . . 45
5.18 Use Case Diagram of Submitting job result . . . . . . . . . . . 46
5.19 Use Case Diagram of Employee Reports . . . . . . . . . . . . 47
5.20 Entity Relationship Diagram of the system-Part 1 . . . . . . . 48
5.21 Entity Relationship Diagram of the system-Part 2 . . . . . . . 49
5.22 Entity Relationship Diagram of the system-Part 3 . . . . . . . 50
5.23 Entity Relationship Diagram of the system-Part 4 . . . . . . . 51
5.24 Class Diagram of the Business Logic Layer-Part 1 . . . . . . . 54
5.25 Class Diagram of the Business Logic Layer-Part 2 . . . . . . . 55
5.26 Class Diagram of the Business Logic Layer-Part 3 . . . . . . . 56
5.27 Class Diagram of the Business Logic Layer-Part 4 . . . . . . . 57
5.28 Class Diagram of the Business Logic Layer-Part 5 . . . . . . . 58
5.29 Class Diagram of the Business Logic Layer-Part 6 . . . . . . . 59
5.30 Class Diagram of the Business Logic Layer-Part 7 . . . . . . . 60
5.31 Class Diagram of the Business Logic Layer-Part 8 . . . . . . . 61
5.32 Class Diagram of the Business Logic Layer-Part 9 . . . . . . . 62
5.33 Class Diagram of the Data Access Layer-Part 1 . . . . . . . . 63
5.34 Class Diagram of the Data Access Layer-Part 2 . . . . . . . . 64
5.35 Class Diagram of the Data Access Layer-Part 3 . . . . . . . . 65
5.36 Class Diagram of the Data Access Layer-Part 4 . . . . . . . . 66
5.37 Class Diagram of the Data Access Layer-Part 5 . . . . . . . . 67
5.38 Class Diagram of the Data Access Layer-Part 6 . . . . . . . . 68
5.47 Message Sequence Diagram of the Admin: Creating Repository 69
5.39 Class Diagram of the User Interface Layer-Part 1 . . . . . . . 70
5.40 Class Diagram of the User Interface Layer-Part 2 . . . . . . . 71
LIST OF FIGURES x
5.41 Class Diagram of the User Interface Layer-Part 3 . . . . . . . 72
5.42 Class Diagram of the User Interface Layer-Part 4 . . . . . . . 73
5.43 Class Diagram of the User Interface Layer-Part 5 . . . . . . . 74
5.44 Class Diagram of the User Interface Layer-Part 6 . . . . . . . 75
5.45 Class Diagram of the User Interface Layer-Part 7 . . . . . . . 76
5.46 Class Diagram of the User Interface Layer-Part 8 . . . . . . . 77
5.48 Message Sequence Diagram of the Admin: User Management . 78
5.49 Message Sequence Diagram of the Admin: Reporting Depart-
ment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.50 Message Sequence Diagram of the Admin: Designers . . . . . 80
5.51 Message Sequence Diagram of the Admin: JobTypes-TestCases-
SubTests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.52 Message Sequence Diagram of the Project Director: Project . 83
5.53 Message Sequence Diagram of the Project Director: Message . 84
5.54 Message Sequence Diagram of the Project Director: Version . 85
5.55 Message Sequence Diagram of the Project Director: Certificates 86
5.56 Message Sequence Diagram of the Project Director: Letters . . 86
5.57 Message Sequence Diagram of the Project Director: Document 87
5.58 Message Sequence Diagram of the Project Manager: Job . . . 88
5.59 Message Sequence Diagram of the Employee: Job . . . . . . . 89
5.60 Message Sequence Diagram of the Employee: Result Submission 90
5.61 System Sequence Diagram of the Admin: Creating Repository 91
5.62 System Sequence Diagram of the Admin: User Management-1 92
5.63 System Sequence Diagram of the Admin: User Management-2 93
5.64 System Sequence Diagram of the Admin: Reporting Department-
1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
LIST OF FIGURES xi
5.65 System Sequence Diagram of the Admin: Reporting Department-
2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.66 System Sequence Diagram of the Admin: Designers-1 . . . . . 96
5.67 System Sequence Diagram of the Admin: Designers-2 . . . . . 97
5.68 System Sequence Diagram of the Admin: JobTypes-TestCases-
SubTests-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.69 System Sequence Diagram of the Admin: JobTypes-TestCases-
SubTests-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.70 System Sequence Diagram of the Project Director: Project-1 . 101
5.71 System Sequence Diagram of the Project Director: Project-2 . 102
5.72 System Sequence Diagram of the Project Director: System-1 . 103
5.73 System Sequence Diagram of the Project Director: System-2 . 104
5.74 System Sequence Diagram of the Project Director: Version-1 . 105
5.75 System Sequence Diagram of the Project Director: Version-2 . 106
5.76 System Sequence Diagram of the Project Director: Certificates 107
5.77 System Sequence Diagram of the Project Director: Letters . . 108
5.78 System Sequence Diagram of the Project Director: Document 109
5.79 System Sequence Diagram of the Project Manager: Job-1 . . . 110
5.80 System Sequence Diagram of the Project Manager: Job-2 . . . 111
5.81 System Sequence Diagram of the Employee: Job-1 . . . . . . . 112
5.82 System Sequence Diagram of the Employee: Job-2 . . . . . . . 113
5.83 System Sequence Diagram of the Employee: Result Submission-
1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.84 System Sequence Diagram of the Employee: Result Submission-
2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.85 Bug Statistics Graph . . . . . . . . . . . . . . . . . . . . . . . 118
5.86 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . 119
List of Tables
3.1 Comparison of tools . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Testing Result Description . . . . . . . . . . . . . . . . . . . . 116
5.2 Bug Statistics Result Description . . . . . . . . . . . . . . . . 117
xii
Chapter 1
Introduction
With the increasing complexity of software engineering projects and involve-
ment of several teams per project, management tasks are becoming more
and more difficult due to the dependency of project timelines and tasks on
many factors [3], involving different departments and their corresponding
outcomes. Project management software tools have been found to be really
useful in this context as they allow visualizing the progress of the project and
thus foreseeing the dependency of tasks on different resources, and predicting
and mitigating delays.
Automatic project management tools provide a promising solution to this
problem and thus have become an essential resource of the present-age indus-
trial organizations. They allow higher management to micro manage projects
from beginning till end, while allowing the employees at all levels to have
their valuable input to ensure the successful completion of a project. These
tools facilitate the upper management to know about the resources (physical
and financial) allocated to a specific task and thus allow them to effectively
reallocate and reschedule resources as per the work domain. Project manage-
ment tools have been found to be quite useful in setting and meeting project
1
CHAPTER 1. INTRODUCTION 2
deadlines as well by incorporating the uncertainties in different estimations
before the start of project. Moreover, project management tools help in
managing multiple simultaneous projects while ensuring minimal wastage of
human resources and finances.
Developing a general purpose software management tool can be quite
challenging mainly due to the varying technical, organization and legal re-
quirements. The software management tool usually contains very sensitive
data so preserving the security and privacy of such a tool becomes quite chal-
lenging especially in the large-scale distributed environment of a corporate
sector, where essential data sources are distributed throughout the corporate
sector. So ensuring the availability of data for necessary operational work
and the protection of data from unauthorized use simultaneously becomes
quite challenging. Beside such requirements, there are many other organiza-
tional specific requirements as per organizational own way of work. Hence,
it becomes more cumbersome to come up with a general tool and thus most
of the organizations have to build a tool as per their own specifications or
introduce new modules as per their requirement.
In the light of challenges mentioned above, software project management
has always been considered a tough task and coming up with a software tool
to automate it is not a straightforward task. Many open source and propriety
tools are in the industry for this purpose. For example, Bugzilla [13] is an
open source software project management tool built and used by the software
developers at Firefox. Firefox developers faced a lot of challenges while de-
veloping their open source web browser and thus built their own management
tool and later on declared it open source. So initially it was more focused
towards managing the development related to the Firefox browser but later
on, due to contributions from community, it become a general tool and is
CHAPTER 1. INTRODUCTION 3
widely used for any software development project. Bugzilla, allows develop-
ers and testers to report bugs, search, track and edit existing bugs. However
Bugzilla fails to provide an overall view of the system and hence the project
managers cannot determine the exact progress of development, which is one
of the greatest requirement in software development as mentioned above.
Moreover, project managers and directors cannot assign tasks to test engi-
neers and developers as per the project requirements. ITracker [12] is another
famous tool for software project management. It almost provides the same
functionality as Bugzilla but the main difference is its platform and database
independence. One of the main limitations of Bugzilla and ITracker is that
there is a lot of manual efforts in tracking a bug and test engineers cannot use
any automatic code analyzers to facilitate their job. SCRUB [4](Source Code
Review User Browser) is another widely acclaimed tool for managing a soft-
ware project.SCRUB not only allows manual bug reporting but also allows
incorporating a bunch of automatic code analyzers at a single platform thus
making the job of software test engineer quite easy. However, none of the
above-mentioned tools allow to automate the whole process of software devel-
opment. Keeping in mind all those deficiencies, we have developed a software
project management tool, i.e., Software Build History Dossier (SBHD) that
addresses most of these issues. It allows automating most of the processes of
software development and significantly improves the automation of software
development life cycle.
1.1 Background and Motivation
Software project management tools usually contain sensitive as well less sen-
sitive data. Access to such data should be properly authorized and proper
CHAPTER 1. INTRODUCTION 4
access control must be implemented before accessing such data. Without
proper access control, possession and manipulation of sensitive data may
lead to severe damaged to the organization. It is the responsibility of the top
level managers to implement such laws, so that such access can be controlled.
Moreover sensitive data must only be provided to the allocated user for op-
eration of the organization.Some of the important preliminaries of software
project management processes includes inspection and verification complete-
ness, consistency, access control, dossier organization, interaction with user
and protection of data.
Checking the completeness of data is one of the most vital part of a soft-
ware project management tool [14]. It means that we should determine which
type of testing should be performed on each module. Checking for the data
consistency [14] is another important aspect of a software project manage-
ment tool. It actually means to ensure that the data provided to one user,
say project manager, is the same as the one provided to the software tester.
By ensuring these consistencies, it becomes easier to follow on the current
progress of software development and react accordingly. Proper access con-
trol of data is another vital part of such a tool. Proper login and security
barriers must be maintained to ensure that an individual can access the data
that he is eligible for only. As a security measure, meta-data, e.g. logs, must
be incorporated to the critical operations of the system making sure that all
such operations would be logged and can be checked as per requirements.
Proper back up of such data is another important requirement of creating
a software management tool. Regular back ups must be maintained making
sure that updated data must be maintained in case of any mishap.
CHAPTER 1. INTRODUCTION 5
1.2 Problem Statement
The software industry grew at much faster pace as enterprises realized the
huge cost difference software and hardware production. To manage this rela-
tively new software production efforts, traditional project management meth-
ods were used at first but softwares keeps on skipping deadlines and failing
customer satisfaction during test runs. Developing a general purpose software
management tool can be quite challenging mainly due to the varying tech-
nical, organization and legal requirements. The software management tool
usually contain very sensitive data so preserving the security and privacy of
such tool becomes quite challenging especially in a large-scale distributed en-
vironment of a corporate sector, where essential data sources are distributed
throughout the corporate sector. So ensuring the availability of data for nec-
essary operational work and the protection of data from unauthorized use
simultaneously becomes quite challenging. Beside such requirements, there
are many more requirements as per organizational own way of work. Hence,
it becomes more cumbersome to come up with a general tool and most of
the organization build a tool as per their own specifications or introduce new
modules as per their requirement.
Moreover, in a specific software development company, it becomes more
and more difficult to arrange and complete day to day activities. In a typical
software development company, from project directors to project mangers
and from Administrators to Employees, a proper system is required which
would help them in the completion of their tasks. Lets say, Project Director
has been assigned a software project which needs to be completed. As per
a typical software project, it would start from Requirement Analysis. So,
Project Director along with his team would conduct meetings with the cus-
CHAPTER 1. INTRODUCTION 6
tomers to find out the requirements of the system. At this critical stage we
needs to document the whole process and there needs a software development
management tool. Moving on to next Design stage of the project, designers
would design the software as per the requirements find out in previous stage.
Once the design of the software has been approved by the customers, develop-
ers would implement the code as per designs. Once design has been finalized,
Test engineers would be required test the software and report bugs. Once,
all the reported bugs has been patched by the developers, It got deployed
or delivered to the customers. After that a non-ending stage of maintenance
starts.
Hence, keeping in mind all above requirements and challenges, A soft-
ware project management tool is highly essential to automate and
document this whole process of software development. In this thesis
I am going to take care of this part and came up with a tool to automate
this whole process of software development.
1.3 Proposed Approach
In this paper we have proposed and implemented a conceptual framework
for the development of software build history dossier. SBHD automates the
whole life cycle of software development. There was a great chance of im-
provement in already existing tools. A comprehensive comparison with ex-
isting tools is presented in tabular form. We have implemented all those
improvements and really improves and automates the whole life cycle of
software development. One of main advantage of SBHD is that beside bug-
reporting it allow the higher authorities in decision making based on the
previous results.
CHAPTER 1. INTRODUCTION 7
As per the problems we identified in the software development life cy-
cle, I have designed and implemented a software project management tool
under the name of Software Build History Dossier. The main purpose of
this tool is to automate the most part of software development life cycle and
let the Project Directors and Project Managers to have an overall look of
the system. Thus Project Directors and Project Managers would be able to
monitor the progress of whole system and thus can take future decisions ac-
cordingly. Moreover, beside accommodating Project Director and Mangers,
it would equally allows the Administrations to add the resources in the sys-
tems accordingly, making job of managers much easier. Also, SBHD allows
developers and test engineers to develop and test the software in most au-
tomate fashion. Once a Project Director has been assigned a task, it would
further distribute it to Project Mangers using SBHD. Project Mangers would
distribute to developers as per the demands of the system and as per the rec-
ommendations by SBHD. Once developers develop the project as per design
and customers requirements, it would be forwarded to test engineers using
SBHD. Test engineers would get all the tests which are necessary for the
particular software by project managers. It is the duty of test engineers to
test the data as per the job requirements, defined by project managers. Test
engineers would run different manual and automated tests on the system to
tests as per demands. Once testing has been done, all the bugs and errors
would be forwarded to Project Managers using SHD for necessary actions.
Its time for project managers to reassign the tasks to developers to fix the
bugs. Once software passes all the necessary requirements, software would
get certificates from project directors. Once achieved, software is ready to
be deployed and then the maintenance stage of software get started. During
all these stages SBHD plays a major role by assigning different certificates,
CHAPTER 1. INTRODUCTION 8
documents and letters throughout the software development life cycle.
1.4 Contributions
Organization of this thesis is as follows.
Chapter 2 describes different preliminaries of creating such tool. Chapter
3 compares the proposed SBHD tool with some of the already existed tools.
Chapter 4 explain various functionalities, supported by the proposed SBHD.
Finally we would conclude the paper and elaborate the future venues of the
research in chapter 6.
Chapter 2
Literature Review
Over the past couple of decades, dependance of humans on computers, hence
software, has not only increased many folds but nowadays computers almost
encompass every aspect of our life, ranging from domestic applications to
safety-critical applications. For software applications, which require high
quality and maximum reliability, software quality management is an essen-
tial task. A slight negligence in this aspect can even result in the loss of
human lives. For example, a software bug in the Therac-25 cancer therapy
machine was primarily responsible for three deaths and three severe injuries
during the mid-80s. Similarly, the computer software that controls the aero-
nautic navigation of an aeroplane or the one which keeps the pilot updated of
the surroundings by communicating from the flight service station requires
a rigorous analysis before deployment in the domain. Besides putting life
at risk, software failures can also lead to dire financial consequences while
dealing with inter-bank transactions or stock-exchange markets. According
to a study conducted by NIST in 2002 [11], it has been revealed that software
bugs cause a huge loss to U.S economy. The total loss accumulates up to
about $595 billion per annum.
9
CHAPTER 2. LITERATURE REVIEW 10
Software development is an exercise to solve out real life problems. As
with any problem solving technique, surety of solution is a vital part of
whole process. Software testing and evaluation does this for software, as it
is a composed of a series of processes which not only makes sure that a piece
of code is doing exactly what it was supposed to do but also that it does not
do anything that was unplanned. Software testing can be formally defined
in a number of ways and some commonly used definitions are as follows [2]:
“Testing is the activity or process which shows or demonstrates that a
program or system performs all intended functions correctly”
“Testing is the activity of establishing the necessary confidence that a
program or system does what it is supposed to do, based on the set of re-
quirements that the user has specified”
“Testing is the process of executing a program/system with the intent of
finding errors”
“Testing is any activity aimed at evaluating an attribute or capability of
a program or system and determining that it meets its required results”
It is commonly believed that the earlier a software bug is found the
cheaper it is to fix it. It is reported that by using an efficient software
testing tool at first place more than one third of the $595 billion per annum
cost of software bugs cost could be evaded [11].
Software testing is quite closely tied to software quality, which is primar-
ily composed of several attributes, depicted in an hierarchical fashion with
their respective characterization in Figure 2.1 [1]. For example, one of the
fundamental quality attributes of software is being reliable, which in turn has
characterization of being adequate and robust at same time, where adequate
software has, in turn, is further characterized by being correct, complete and
consistent. These quality attributes are much more qualitative instead of
CHAPTER 2. LITERATURE REVIEW 11
Software Qualities
Usable
Efficient
Reliable
Adequate
Robust
Correct
Complete
Consistent
Transportable
Testable
Maintainable
Understandable
Measureable
Structured
Concise
Self-descriptive
Accessible
Quantifiable
Figure 2.1: Software Quality Assurance Attirbutes
being quantitative.
Besides reliability, other software quality attributes, as show in Figure 2.1,
include usability, efficiency, transportability, testability and maintainability.
However in practical scenarios it has been observed that efficiency and other
quality attributes often conflict with each other. For example, a highly criti-
cal chip demands assembly level programming for higher efficiency but doing
so would highly decrease its transportability to other platforms. Because
of these reasons, each software development team, must first categorize the
relative importance of quality attributes.
In this survey, we have explained software testing, verification and valida-
tion (V&V) techniques that are applied throughout the life cycle of software
development. One of the main problems associated with verification is con-
finement of verification techniques to the last stages of development [6]. Such
practices can result in heavy financial losses, as the cost of fixing a bug is
highly dependant on the time it is caught. The authors in [5] point out
the same mistake of delaying the activity of testing and verification process
until last stages of software development, which may result in disastrous con-
CHAPTER 2. LITERATURE REVIEW 12
sequences. Thus, with highest quality and minimum possible cost as final
goals, testing and verification must be applied throughout the life cycle of
software development.
Software verification and validation mainly consist of processes, which
confirm that the software is validating all of its specifications and complying
with its intended purpose.
The software verification process can be described as a question,
Either we are building the product in the right way?
It checks whether the software and its associated processes are complying
with the following rules:
• Does the software satisfy the requirements?
• Does the software conform to the practices and conventions?
• Before moving to next cycle, does it satisfy previous life cycle activity?
Similarly, the software validation process can also be described as a ques-
tion,
Either we are building the product which was demanded?
It checks whether software and its associated processes are complying
with the following rules:
• Does the software use the same resources which were allocated at each
life cycle?
• Does the software solve the problem which it was supposed to solve?
• Does the software perform as per users expectations?
Various testing approach (e.g., citetesting,testing1,testing3) have been
proposed but White-box and Black-box are considered to be the most widely
CHAPTER 2. LITERATURE REVIEW 13
used ones. The white-box testing allows deep analysis and identify bugs in
the internal structure of the program and helps the user to optimize the
program to the maximum extent. On the other hand, the black-box testing
approach checks the dynamic behaviour of the program and is generally faster
and easier to perform than the white-box testing. This paper is primarily
surveys these testing approaches for C programs.
The main motivation for choosing C programming for this survey is its
wide acceptance [8] due to its many unique features, including portability
of the compilers, ready access to the hardware, a user friendly syntax with
interactive environment, powerful and varied repertoire of operators, built-
in standard libraries. C is also a foundational block for many other user
friendly languages like C++, C#, java etc. Initially C was used only for sys-
tem development work, but later on, due to its versatile benefits, its usage
increased rapidly in other development as well, Examples include develop-
ment of compilers for other languages, assemblers, text editors, language
interpreters, network drivers, printing spoolers, data bases, modern applica-
tions development etc. Programming in C is found everywhere in the world
such as, development of embedded systems, avionic software systems, med-
ical software systems, communication systems, games, custom applications,
commercial softwares etc. Due to the large scale applications of C program-
ming, the question of its quality assurance and validation has always been
an important one [9, 10].
Chapter 3
Comparison
Software project management has always been a hot area in software de-
velopment and many software companies uses a range of open source and
proprietary software for this purpose. Here we would compare our tool with
some of the most famous open source software tools, Bugzilla, Itracker and
SCRUB. Bugzilla [12] was initially developed by Firefox, one of the largest
open source tool for web browsing. At the time of development of Firefox,
its developers need a bug reporting mechanism so the developing team built
their own and the Bugzilla keeps on improving after that by open source
community. ITracker [12] is another issue-tracking tool developed by Jason
Carroll in 2002. ITracker is somehow very much same to Bugzilla and has
been one of the most widely used tool. However, the main differene is that
it’s not only independent of plateform but also independent of database as
well. SCRUB [7](Source Code Review User Browser) is a tool, developed
to perform code review process. The tool is equally effective for large scale
software development process but can also be used by small teams as well for
smaller projects. The main advantage of this tool is that beside using classic
peer review process for code they also incorporated and integrated a range
14
CHAPTER 3. COMPARISON 15
of code analyzers. So their effort is more towards developing a tool which
would automates code reviewing process.
Table 3.1: Comparison of tools
Sr. # Features Bugzilla [12] ITracker [12] SCRUB [7] SBHD1 Plateform Linux Independent Linux Windows2 Database MYSQL Independent Proprietary MYSQL3 Customizable Low Medium,New fields can be added Medium,More code analyzers can be added High4 No of users unlimited unlimited unlimited unlimited5 Distributed teams Yes Yes Yes Yes6 Bug reporting Yes Yes Yes Yes7 Automates whole SDLC No No No Yes8 Overall progress monitoring by Managers No No No Yes
Chapter 4
Functionality of Software Build
History Dossier
According to our scenario, software development team would be responsi-
ble for the development and necessary amendment of the software. After
each successful development, code would be handed over to the testing team
by the project managers. Project managers would allocate all the neces-
sary testing scenarios, to the testing team through the use of software build
history dossier. Different testing includes unit testing, integration testing,
formal verification, documentation etc. After the successful completion of
testing from testing team, all the necessary observation/modifications would
be handed back to the software developers also through software build history
dossier. In this way it would automatically documents the overall progress
of the processes and would let the respective project directors to know about
the status and eventually the successful completion of project.
SBHD has been built to automate the whole process of Software Develop-
ment Life Cycle (SDLC). Whenever a user wants to login the application he
has to provide the username and password. After successful login he would
16
CHAPTER 4. FUNCTIONALITY OF SOFTWARE BUILD HISTORYDOSSIER17
be allowed to interact with system as per his role/roles. The four main users
of this system are as under:
1. Admin
2. Project Director
3. Project Manager
4. Employee
Starting with Admin, all roles would be explained one by one.
4.1 Admin
Admin is the user who has the most responsibilities in the system. After
deploying the SBHD system, admin must be the first user who should login
in the system. Main responsibilities of the admin are stated below and can
also be visualized by the attached Figure # 4.1:
• User Management i.e Adding new users, Updating and Deleting user
records
• Role Management i.e Adding new roles in the System, Updating and
Deleting user’s role
• Reporting Department Management. There are many department in
a software development institute like, developers, testers and so on. It
would be admin’s responsibility to maintain all the department in the
organization
• Role Management i.e Adding new roles in the System, Updating and
Deleting user’s role
CHAPTER 4. FUNCTIONALITY OF SOFTWARE BUILD HISTORYDOSSIER18
Figure 4.1: Windows Form for Admin
• Job Types/Test Case Management. Here admin would to manage all
the test case and job types that a user can be assigned by his//her
supervisor to perform
• Beside that admin would have to perform some miscellaneous duties
like database management and other trivial settings
4.2 Project Director
Project Director is the most senior authority in SBHD. The Project Director
form let the project directors do perform their duties. Most of these duties
are related to management of different projects. In this particular scenario,
each software comes in a hierarchal structure of project,system and version,
i.e. each project has many systems and subsequently each system has many
versions. Main responsibilities of the Project Director are stated below and
can also be visualized by the attached Figure # 4.2:
CHAPTER 4. FUNCTIONALITY OF SOFTWARE BUILD HISTORYDOSSIER19
Figure 4.2: Windows Form for Project Director
• Project Management i.e Adding new Projects, Updating and Deleting
project records
• System Management i.e Adding new System under a specific project,
Updating and Deleting systems accordingly
• Version Management i.e Adding new Version under a specific system,
Updating and Deleting versions accordingly
• Letters: Project Director can issue Letters to any other user for effective
communication
• Certificates: Project Director can issue certificates once a piece of code
has been thoroughly tested and performed as per expectations
• Documents: To keep a record of all of the activities performed on a spe-
cific project, Project Director can generate relevant documents. These
documents would be stored in database and can be easily retrieved if
CHAPTER 4. FUNCTIONALITY OF SOFTWARE BUILD HISTORYDOSSIER20
Figure 4.3: Windows Form for Project Manager
felt necessary
4.3 Project Manager
Project Director is the second most senior authority in SBHD after Project
Director. The Project Manager form let the project managers do perform
their duties. Most of these duties are related to management of jobs. Main
responsibilities of the Project Manager are stated below and can also be
visualized by the attached Figure # 4.3:
• Job Management: Project Manger is such a resource in the system that
after creation of projects,systems and versions by Project Director, it
became the duty of Project Manager to assign the tasks to the testers
to test the code as per specification mentioned in Job Form. Through
this form, Project Managers can easily track the progress of each job,
allocate resource accordingly and can use this data to optimize the
CHAPTER 4. FUNCTIONALITY OF SOFTWARE BUILD HISTORYDOSSIER21
Figure 4.4: Windows Form for Employee
performance of team members accordingly.
4.4 Employee
Employees are the resource against which jobs are assigned by Project Man-
agers. The Employee form let the employees do perform their duties. Main
responsibilities of the employee are stated below and can also be visualized
by the attached Figure # 4.4:
• Jobs: Once a job has been assigned to an employee, it would be shown
up in his form.Any employee can see the job and its details assigned to
him and start the job accordingly
• Once a job got started, project Manager would be prompted against
that job
• After completing the job, employee can submit the job. Submitting the
CHAPTER 4. FUNCTIONALITY OF SOFTWARE BUILD HISTORYDOSSIER22
job would let the project manager know that job has been completed
• Once job got completed, its time to provide results of testing. Employee
would submit all of its finding about the testing and would specifically
mention all the tests which has been performed and either the piece of
code pass those test or not.
• Beside submitting results, employee is considered to submit reports as
well. The report tab in Employee Form let the employee to add the
reports and submit it in results.
Chapter 5
Software Development Life
Cycle
In this chapter, whole functionality of system and its implementation is de-
scribed.
5.1 Requirement Specification
5.1.1 Functional Requirements
The functional requirements of the systems are stated below:
1. Admin
(a) Set Repository
The administrator must be able to set the Repository path for the
system for the first time.
(b) Modify Repository
In case of changing Repository, administrator must be able to
modify it.
23
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 24
(c) Display all Users
Admin must be able to have a look at all users at one place.
(d) Add new Users
Admin must be able to add new users to the system.
(e) Edit Users
Admin must be able to edit user credentials.
(f) Delete Users
Admin must be able to delete the users as per needs.
(g) Display all Roles
Admin must be able to display all the possible roles assigned in
the system.
(h) Display all Reporting Departments
Admin must be able to display all the reporting departments in
the system.
(i) Add new Reporting Departments
Admin must be able to add new department in the system.
(j) Edit Reporting Departments
Admin must be able to edit existing departments.
(k) Delete Reporting Departments
Admin must be able to delete the departments.
(l) Display all Designers
Admin must be able to display all of the designers.
(m) Add new Designers
Admin must be able to add new designers.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 25
(n) Edit Designers
Admin must be able to edit the designers.
(o) Delete Designers
Admin must be able to delete designers.
(p) Display Job Types and Test Cases
Admin must be able to display job types and test cases.
(q) Add new Job Types and Test Cases
Admin must be able to add new job types and test cases.
(r) Edit Job Types and Test Cases
Admin must be able to edit job types and test cases.
(s) Delete Job Types and Test Cases
Admin must be able to delete job types and test cases.
2. Project Director
(a) Display Projects
Project Director must be able to display projects.
(b) Add new Projects
Project Director must be able to add new projects.
(c) Edit Projects
Project Director must be able to edit projects.
(d) Delete Projects
Project Director must be able to delete projects.
(e) Display Systems
Project Director must be able to display systems.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 26
(f) Add new Systems
Project Director must be able to add new systems.
(g) Edit Systems
Project Director must be able to edit systems.
(h) Delete Systems
Project Director must be able to delete systems.
(i) Display Versions
Project Director must be able to display versions.
(j) Add new Versions
Project Director must be able to add new versions.
(k) Edit Versions
Project Director must be able to edit versions.
(l) Delete Versions
Project Director must be able to delete versions.
(m) Display all information about project,system and version
Project Director must be able to display all information about
project,system and version on a single page.
(n) Issuance of Letters
Project Director must be able to issue letters along with attach-
ments.
(o) Issuance of Certificates
Project Director must be able to issue certificates, like, Certificate
of Conformance as per SBHD doc no.
(p) Document generation
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 27
Project Director must be able to generate different documents like,
Project List Document and SBHD Document.
3. Project Manager
(a) Display Jobs
Project Manager must be able to display the jobs.
(b) Add new Jobs
Project Manager must be able to add new jobs.
(c) Edit Jobs
Project Manager must be able to edit the jobs.
(d) Delete Jobs
Project Manager must be able to delete the jobs.
4. Employee
(a) Display Jobs
Employee must be able to display the allocated jobs.
(b) Start a Job
Employee must be able to start a job.
(c) Submit a Job
Employee must be able to submit a job.
(d) Submit Job results
Employee must be able to to results of the job.
(e) Generate Reports
Employee must be able to generate different reports of the system,
like System Reports and Subsystem Reports.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 28
5.2 Use Case Diagrams
In this section, we have explained the Use Case Diagram of the system and
then Class Diagram afterwards.
5.2.1 Use Case Diagrams of the system
Use Case Diagrams of the system is shown in 5.1.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 29
Figure 5.1: Use Case Diagram of system
5.2.2 Use Case Diagrams for Admins
In this section we would explain the use case diagrams for Admins.
5.2.2.1 Use Case Diagrams for Creating Repository
Use Case Diagrams of creating repository is shown in 5.2.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 30
Figure 5.2: Use Case Diagram of Creating Repository
5.2.2.2 Use Case Diagrams for User Management
Use Case Diagrams of User Management is shown in 5.3.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 31
Figure 5.3: Use Case Diagram of User Management
5.2.2.3 Use Case Diagrams for Role Management
Use Case Diagrams of Role Management is shown in 5.4.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 32
Figure 5.4: Use Case Diagram of Role Management
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 33
5.2.2.4 Use Case Diagrams for Reporting Department
Use Case Diagrams of Reporting Department is shown in 5.5.
Figure 5.5: Use Case Diagram of Reporting Department
5.2.2.5 Use Case Diagrams for Designers
Use Case Diagrams of Designers is shown in 5.6.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 34
Figure 5.6: Use Case Diagram of Designers
5.2.2.6 Use Case Diagrams for Job Types- Test Cases- Sub Tests
Use Case Diagrams of Job Types- Test Cases- Sub Tests is shown in 5.7.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 35
Figure 5.7: Use Case Diagram of Job Types- Test Cases- Sub Tests
5.2.3 Use Case Diagrams for Project Director
In this section we would explain the use case diagrams for Project Director.
5.2.3.1 Use Case Diagrams for Project
Use Case Diagrams of Project is shown in 5.8.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 36
Figure 5.8: Use Case Diagram of Project
5.2.3.2 Use Case Diagrams for System
Use Case Diagrams of System is shown in 5.9.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 37
Figure 5.9: Use Case Diagram of System
5.2.3.3 Use Case Diagrams for Version
Use Case Diagrams of Version is shown in 5.10.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 38
Figure 5.10: Use Case Diagram of Version
5.2.3.4 Use Case Diagrams for Certificates
Use Case Diagrams of Certificates is shown in 5.11.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 39
Figure 5.11: Use Case Diagram of Certificates
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 40
5.2.3.5 Use Case Diagrams for Letters
Use Case Diagrams of Letters is shown in 5.12.
Figure 5.12: Use Case Diagram of Letters
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 41
5.2.3.6 Use Case Diagrams for Document
Use Case Diagrams of Document is shown in 5.13.
Figure 5.13: Use Case Diagram of Document
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 42
5.2.4 Use Case Diagrams for Project Manager
In this section we would explain the use case diagrams for Project Manager.
5.2.4.1 Use Case Diagrams for Job
Use Case Diagrams of Job is shown in 5.14.
Figure 5.14: Use Case Diagram of Job
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 43
5.2.5 Use Case Diagrams for Employee
In this section we would explain the use case diagrams for Employee.
5.2.5.1 Use Case Diagrams for Job Display
Use Case Diagrams of displaying a job is shown in 5.15.
Figure 5.15: Use Case Diagram of Job Display
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 44
5.2.5.2 Use Case Diagrams for Starting a Job
Use Case Diagrams of starting a job is shown in 5.16.
Figure 5.16: Use Case Diagram of Starting a Job
5.2.5.3 Use Case Diagrams for Submitting a Job
Use Case Diagrams of submitting a job is shown in 5.17.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 45
Figure 5.17: Use Case Diagram of Submitting a Job
5.2.5.4 Use Case Diagrams for Submitting job result
Use Case Diagrams of submitting job result is shown in 5.18.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 46
Figure 5.18: Use Case Diagram of Submitting job result
5.2.5.5 Use Case Diagrams for Employee Reports
Use Case Diagrams of Employee Reports is shown in 5.19.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 47
Figure 5.19: Use Case Diagram of Employee Reports
5.2.6 Entity Relationship Diagram of the System
Entity Relationship Diagram of the whole system is given Figures 5.20, 5.21,
5.22 and 5.23.
5.2.7 Non-Functional Requirements
5.2.7.1 Performance Requirements
Performance should not be an issue because all of our server queries involve
small pieces of data. Changing screens will require very little computation
and thus will occur very quickly.
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 48
Fig
ure
5.20
:E
nti
tyR
elat
ionsh
ipD
iagr
amof
the
syst
em-P
art
1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 49
Fig
ure
5.21
:E
nti
tyR
elat
ionsh
ipD
iagr
amof
the
syst
em-P
art
2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 50
Fig
ure
5.22
:E
nti
tyR
elat
ionsh
ipD
iagr
amof
the
syst
em-P
art
3
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 51
Fig
ure
5.23
:E
nti
tyR
elat
ionsh
ipD
iagr
amof
the
syst
em-P
art
4
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 52
5.2.7.2 Security Requirements
The server on which database of SBHD resides will have its own security
to prevent unauthorized write/delete access. There is no restriction on read
access. The PC on which SBHD resides will have its own security. Only the
authorized users will have physical access to the machine and the program
on it. There is no special protection built into this system other than to
provide the users with login access to the system.
5.2.7.3 Safety Requirements
SBHD will not affect data stored outside of its servers nor will it affect any
other applications installed on the users PC. It cannot cause any damage to
the PC or its internal components. SBHD should not be used while operating
a vehicle or in any other situation where the users attention must be focused
elsewhere.
5.2.7.4 Software Quality Attributes
The graphical user interface of SBHD is to be designed with usability as
the first priority. The software will be presented and organized in a manner
that is both visually appealing and easy for the user to navigate. There
will be feedbacks and visual cues such as notifications to inform users of
updates and pop-ups to provide users with instructions. To ensure reliability
and correctness, there will be zero tolerance for errors in the algorithm that
computes and distribute jobs between users. To maintain flexibility and
adaptability, the software will take into account situations in which a user
cannot establish a connection with the server. Overall, the software balances
both the ease of use and the ease of learning. The layout and UI of the
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 53
software will be simple enough that users will take no time to learn its features
and navigate through it with little difficulty.
5.2.7.5 User and human factors
Basic English language knowledge is must for user of systems. Moreover
having a basic knowledge of computers is also a requirement.
5.2.7.6 Documentation
Software comes with necessary documentation and manual, incase of any
ambiguity, please consider using those documents.
5.2.7.7 Quality assurance
Max down time for the system can be at max 1 hour. In case of any unavail-
ability, concerned department must be made aware of at earliest.
5.3 Design
5.3.1 Structural Design: Class Diagram
5.3.1.1 Class Diagram of Business Logic Layer
Class Diagrams of Business logic layer are attached as under in Figure 5.24,
5.25, 5.26, 5.27, 5.28, 5.29, 5.30, 5.31 and 5.32:
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 54
Figure 5.24: Class Diagram of the Business Logic Layer-Part 1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 55
Figure 5.25: Class Diagram of the Business Logic Layer-Part 2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 56
Figure 5.26: Class Diagram of the Business Logic Layer-Part 3
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 57
Figure 5.27: Class Diagram of the Business Logic Layer-Part 4
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 58
Figure 5.28: Class Diagram of the Business Logic Layer-Part 5
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 59
Figure 5.29: Class Diagram of the Business Logic Layer-Part 6
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 60
Figure 5.30: Class Diagram of the Business Logic Layer-Part 7
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 61
Figure 5.31: Class Diagram of the Business Logic Layer-Part 8
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 62
Figure 5.32: Class Diagram of the Business Logic Layer-Part 9
5.3.1.2 Class Diagram of Data Access layer
Class Diagrams of Data Access layer are attached as under in Figures 5.33,
5.34, 5.35, 5.36, 5.37 and 5.38 :
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 63
Fig
ure
5.33
:C
lass
Dia
gram
ofth
eD
ata
Acc
ess
Lay
er-P
art
1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 64
Fig
ure
5.34
:C
lass
Dia
gram
ofth
eD
ata
Acc
ess
Lay
er-P
art
2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 65
Fig
ure
5.35
:C
lass
Dia
gram
ofth
eD
ata
Acc
ess
Lay
er-P
art
3
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 66
Fig
ure
5.36
:C
lass
Dia
gram
ofth
eD
ata
Acc
ess
Lay
er-P
art
4
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 67
Fig
ure
5.37
:C
lass
Dia
gram
ofth
eD
ata
Acc
ess
Lay
er-P
art
5
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 68
Fig
ure
5.38
:C
lass
Dia
gram
ofth
eD
ata
Acc
ess
Lay
er-P
art
6
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 69
5.3.1.3 Class Diagram of User Interface layer
Class Diagrams of User Interface layer are attached as under in Figure 5.39,
5.40, 5.41, 5.42, 5.43, 5.44, 5.45 and 5.46 :
5.3.2 Behavioral design: Message Sequence Diagrams
5.3.2.1 Message Sequence Diagrams of Admin
Message Sequence Diagrams of Admin functionality can be observed in Fig-
ure 5.47, 5.47, 5.49, 5.50 and 5.51
Figure 5.47: Message Sequence Diagram of the Admin: Creating Repository
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 70
Fig
ure
5.39
:C
lass
Dia
gram
ofth
eU
ser
Inte
rfac
eL
ayer
-Par
t1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 71
Fig
ure
5.40
:C
lass
Dia
gram
ofth
eU
ser
Inte
rfac
eL
ayer
-Par
t2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 72
Fig
ure
5.41
:C
lass
Dia
gram
ofth
eU
ser
Inte
rfac
eL
ayer
-Par
t3
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 73
Fig
ure
5.42
:C
lass
Dia
gram
ofth
eU
ser
Inte
rfac
eL
ayer
-Par
t4
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 74
Fig
ure
5.43
:C
lass
Dia
gram
ofth
eU
ser
Inte
rfac
eL
ayer
-Par
t5
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 75
Fig
ure
5.44
:C
lass
Dia
gram
ofth
eU
ser
Inte
rfac
eL
ayer
-Par
t6
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 76
Fig
ure
5.45
:C
lass
Dia
gram
ofth
eU
ser
Inte
rfac
eL
ayer
-Par
t7
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 77
Fig
ure
5.46
:C
lass
Dia
gram
ofth
eU
ser
Inte
rfac
eL
ayer
-Par
t8
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 78
Figure 5.48: Message Sequence Diagram of the Admin: User Management
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 79
Figure 5.49: Message Sequence Diagram of the Admin: Reporting Depart-ment
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 80
Figure 5.50: Message Sequence Diagram of the Admin: Designers
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 81
Figure 5.51: Message Sequence Diagram of the Admin: JobTypes-TestCases-SubTests
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 82
5.3.2.2 Message Sequence Diagrams of Project Director
Message Sequence Diagrams of Project Director functionality can be observed
in Figure 5.52, 5.53, 5.54, 5.55, 5.56 and 5.57,:
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 83
Figure 5.52: Message Sequence Diagram of the Project Director: Project
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 84
Figure 5.53: Message Sequence Diagram of the Project Director: Message
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 85
Figure 5.54: Message Sequence Diagram of the Project Director: Version
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 86
Figure 5.55: Message Sequence Diagram of the Project Director: Certificates
Figure 5.56: Message Sequence Diagram of the Project Director: Letters
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 87
Figure 5.57: Message Sequence Diagram of the Project Director: Document
5.3.2.3 Message Sequence Diagrams of Project Manager
Message Sequence Diagrams of Project Manager functionality can be ob-
served in Figure 5.58:
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 88
Figure 5.58: Message Sequence Diagram of the Project Manager: Job
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 89
5.3.2.4 Message Sequence Diagrams of Employee
Message Sequence Diagrams of employee functionality can be observed in
Figure 5.59 and 5.60:
Figure 5.59: Message Sequence Diagram of the Employee: Job
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 90
Figure 5.60: Message Sequence Diagram of the Employee: Result Submission
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 91
5.3.3 Behavioral design: System Sequence Diagrams
5.3.3.1 System Sequence Diagrams of Admin
System Sequence Diagrams of Admin functionality can be observed in Figure
5.61, 5.61, 5.65, 5.67 and 5.69
Figure 5.61: System Sequence Diagram of the Admin: Creating Repository
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 92
Figure 5.62: System Sequence Diagram of the Admin: User Management-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 93
Figure 5.63: System Sequence Diagram of the Admin: User Management-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 94
Figure 5.64: System Sequence Diagram of the Admin: ReportingDepartment-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 95
Figure 5.65: System Sequence Diagram of the Admin: ReportingDepartment-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 96
Figure 5.66: System Sequence Diagram of the Admin: Designers-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 97
Figure 5.67: System Sequence Diagram of the Admin: Designers-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 98
Figure 5.68: System Sequence Diagram of the Admin: JobTypes-TestCases-SubTests-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 99
Figure 5.69: System Sequence Diagram of the Admin: JobTypes-TestCases-SubTests-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 100
5.3.3.2 System Sequence Diagrams of Project Director
System Sequence Diagrams of Project Director functionality can be observed
in Figure 5.71, 5.73, 5.75, 5.76, 5.77 and 5.78,:
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 101
Figure 5.70: System Sequence Diagram of the Project Director: Project-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 102
Figure 5.71: System Sequence Diagram of the Project Director: Project-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 103
Figure 5.72: System Sequence Diagram of the Project Director: System-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 104
Figure 5.73: System Sequence Diagram of the Project Director: System-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 105
Figure 5.74: System Sequence Diagram of the Project Director: Version-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 106
Figure 5.75: System Sequence Diagram of the Project Director: Version-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 107
Figure 5.76: System Sequence Diagram of the Project Director: Certificates
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 108
Figure 5.77: System Sequence Diagram of the Project Director: Letters
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 109
Figure 5.78: System Sequence Diagram of the Project Director: Document
5.3.3.3 System Sequence Diagrams of Project Manager
System Sequence Diagrams of Project Manager functionality can be observed
in Figure 5.80:
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 110
Figure 5.79: System Sequence Diagram of the Project Manager: Job-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 111
Figure 5.80: System Sequence Diagram of the Project Manager: Job-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 112
5.3.3.4 System Sequence Diagrams of Employee
System Sequence Diagrams of employee functionality can be observed in
Figure 5.82 and 5.84:
Figure 5.81: System Sequence Diagram of the Employee: Job-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 113
Figure 5.82: System Sequence Diagram of the Employee: Job-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 114
Figure 5.83: System Sequence Diagram of the Employee: Result Submission-1
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 115
Figure 5.84: System Sequence Diagram of the Employee: Result Submission-2
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 116
5.3.4 Testing
Following tests has been performed on the system and it found out that
system has passed all those test.
• Unit Testing
• Integration Testing
• Functional Testing
• Stress Testing
• Compatibility Testing
Testing results are summarised in the table 5.1:
Table 5.1: Testing Result Description
Sr. # Attributes Grade Remarks1 Conformity: To Standards 10 Nil2 Conformity: To Requirements 10 Nil3 Consistency 10 Nil4 Supports Concurrency 10 Nil5 Graphical User Interface 10 Nil6 Usability:Ease of use 10 Nil7 Usability:User Manual Help 10 Nil8 Usability:Ease of learning 10 Nil9 Performance:Query 10 Nil10 Performance:Data Capture 10 Nil11 Security 10 Nil12 Robustness 10 Nil13 Error Handling 10 Nil
Bug statistics are summarised in the table 5.2:
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 117
Table 5.2: Bug Statistics Result Description
Project Submission Total Bugs Rejected Bugs Rejection Ratio1 428 46 10.75%2 578 89 15.40%3 188 22 11.70%4 361 44 12.19%5 2161 298 13.79%6 35 0 07 113 18 15.93%8 2142 392 18.30%9 239 17 7.11%10 1043 154 14.77%11 171 8 4.68%12 109 11 10.09%13 1214 163 13.43%14 470 75 15.96%15 82 17 20.73%16 69 5 7.25%17 31 0 0
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 118
Bug statistics can be visualized in following graph 5.85:
0
500
1000
1500
2000
2500
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Bug Statistics
Project ID Total Bugs Rejected Bugs Bugs Corrected
Figure 5.85: Bug Statistics Graph
Unit, module, and system integration testing activities were performed
during the development of the system build or release. All testing activities
help a lot to bring the application to a certain level of acceptance. Especially
unit testing was quite helpful to test the individual units again and again. It
really help to make each unit error free.
In GUI testing following tests were incorporated: Manual Testing Tech-
niques:
• Heuristic Methods
• Guidelines
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 119
• Cognitive walkthrough
• Usability tests
5.3.5 Deployment
The system would be deployed on LAN and would make sure that all users
can access the system. The deployment can be observed in Figure 5.86
Figure 5.86: Deployment Diagram
5.3.6 Maintenance
NUST is in general responsible for corrective and adaptive maintenance to
address defects, potential defects and minor improvements found in run-
ning services in the production environments, based on requests for changes
(RfC) in the code of SBHD software components. Developers would defines
a change as the addition, modification or removal of authorized, planned or
supported service or service component and its associated documentation.
One of the main sources of RfCs are the incidents reported by users through
the support channels. IT support defines an incident as an unplanned inter-
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 120
ruption to an IT service or reduction in the quality of an IT service. Failure
of a component that has not yet affected service is also an incident. After
investigation by the different levels of support, an incident may be traced to
an actual problem in the code. IT support defines a problem as the cause of
one or more incidents . If that is the case, the problem is recorded into an
RfC tracker and further processed by the team responsible for the affected
component, usually leading to changes in the code.
Another major source of RfCs is the continuous stream of user require-
ments, notably from the quality assurance department and similar bodies.
Requirements are collected and processed by the QA team. They are main-
tained in a dedicated tracker. Finally, RfCs, both to fix defects and to
introduce improvements, can also be generated internally in the project or
even in the Product Team itself in charge of a given component.
Since NUST addresses only corrective and adaptive maintenance, it is
necessary to define how to select RfCs that qualify as corrective or adaptive.
The criterion for such classification is the priority of the RfC, where the
priority is the result of the composition of a number of factors:
• Severity: a measure of the degradation of the quality of service of the
affected component;
• Impact: a measure of the effect of the degradation of the quality of
service of the affected component;
• Urgency: a measure of how long it will be until the quality of service
of the affected component is not significantly degraded;
• Cost: a measure of the resources needed for the management of the
change, including the risks associated to the degradation of the quality
of the affected component in case the change is not fully successful. The
CHAPTER 5. SOFTWARE DEVELOPMENT LIFE CYCLE 121
evaluation of the priority of an RfC results in one of four possible logical
values. Each level implies a very specific behavior for the management
of that RfC.
The four priority levels and the corresponding behaviors are:
• Immediate: The RfC needs to be addressed as soon as possible, in all
affected EMI major releases. A release containing Immediate-priority
changes can contain only Immediate-priority changes. Multiple Immediate-
priority changes can be included in the same release, provided that any
change does not delay the release significantly. This constraint min-
imizes the risk of introducing new defects in the new release of the
affected component and allows the adoption of special accelerated pro-
cedures for its release. Moreover it will not force site administrators to
deploy lower-priority changes during an emergency update.
• High: The RfC will be addressed in a next release of the affected com-
ponent, in all affected component major releases.
• Medium: The RfC will be addressed in the release of the affected com-
ponent that will be shipped with the next major release.
• Low: There is no target date for addressing the RfC.
5.3.7 Technology Used
We have used the following technology to implement the system.
• Dbfork for making ERD of the system.
• Microsoft Visual Studio to design and program different forms.
• MySQL for backend database.
Chapter 6
Conclusions
In this paper we have proposed and implemented a conceptual framework
for the development of software build history dossier. SBHD automates the
whole life cycle of software development. There was a great chance of im-
provement in already existing tools. A comprehensive comparison with ex-
isting tools is presented in tabular form. We have implemented all those
improvements and really improves and automates the whole life cycle of
software development. One of main advantage of SBHD is that beside bug-
reporting it allow the higher authorities in decision making based on the
previous results.
6.1 Future Work
In future work the requirement analysis stage of SDLC can be incorporated
in the tool. It will not only help to document the whole process of software
development but can significantly help in identifying the scope of software
under development. Beside that it can help in conflict resolution in last
stages of software delivery.
122
Bibliography
[1] W Richards Adrion, Martha A Branstad, and John C Cherniavsky. Val-
idation, verification, and testing of computer software. ACM Computing
Surveys (CSUR), 14(2):159–192, 1982.
[2] K. Akingbehin. Towards destructive software testing. In Computer
and Information Science, 2006 and 2006 1st IEEE/ACIS International
Workshop on Component-Based Software Engineering, Software Archi-
tecture and Reuse. ICIS-COMSAR 2006. 5th IEEE/ACIS International
Conference on, pages 374–377, July 2006.
[3] M. Apistola, Martijn Warnier, A. Oskamp, and Frances M. T. Brazier.
Towards a conceptual framework for digital dossier management in crim-
inal proceedings. In Law and Technology, 2007.
[4] C. Bird, T. Carnahan, and M. Greiler. Lessons learned from building
and deploying a code review analytics platform. In 2015 IEEE/ACM
12th Working Conference on Mining Software Repositories, pages 191–
201, 2015.
[5] B. W. Boehm. Seven basic prmci ples of software engmeering,” in Soft
ware engineering techniques, Infotech State of the Art Report, Infotech,
Lon don. 1977.
123
BIBLIOGRAPHY 124
[6] Corey Sandler Glenford J. Myers, Tom Badgett. The Art Of Software
Testing. 2012.
[7] G. J. Holzmann. Scrub: A tool for code reviews. Innov. Syst. Softw.
Eng., 6(4):311–318, December 2010.
[8] Brian W Kernighan, Dennis M Ritchie, and Per Ejeklint. The C pro-
gramming language, volume 2. prentice-Hall Englewood Cliffs, 1988.
[9] Huimei Liu and Huayu Xu. Research on code analysis and instrumen-
tation in software test [j]. Computer Engineering, 1:028, 2007.
[10] Chandrashekar Rajaraman and Michael R Lyu. Reliability and main-
tainability related software coupling metrics in c++ programs. In Soft-
ware Reliability Engineering, 1992. Proceedings., Third International
Symposium on, pages 303–311. IEEE, 1992.
[11] Social RTI Health and Economics Research Research Triangle Park. The
economic impacts of inadequate infrastructure for software testing final
report, May 2002.
[12] N. Serrano and I. Ciordia. Bugzilla, itracker, and other bug trackers.
IEEE Software, 22(2):11–13, March 2005.
[13] Lin Tan, Chen Liu, Zhenmin Li, Xuanhui Wang, Yuanyuan Zhou, and
Chengxiang Zhai. Bug characteristics in open source software. Empirical
Software Engineering, 19(6):1665–1705, 2014.
[14] M. Warnier, F. M. T. Brazier, M. Apistola, and A. Oskamp. Towards au-
tomatic identification of completeness and consistency in digital dossiers.
In The Proceedings the Eleventh International Conference on Artificial
Intelligence and Law, pages 177–182. ACM Press, 2007.