software build history dossier for development and...

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.24 Class Diagram of the Business Logic Layer-Part 1 . . . . . . . 54









5.33 Class Diagram of the Data Access Layer-Part 1 . . . . . . . . 63






5.47 Message Sequence Diagram of the Admin: Creating Repository 69

5.39 Class Diagram of the User Interface Layer-Part 1 . . . . . . . 70


LIST OF FIGURES x







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


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


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.


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-


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.


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,


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


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-


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


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


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:


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


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


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


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.


(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.


(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


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.


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.


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.


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.


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.


Figure 5.4: Use Case Diagram of Role Management


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.


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.


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.


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.


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.


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.


Figure 5.11: Use Case Diagram of Certificates


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


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


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


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


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.


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.


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.


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.


Fig

ure

5.20

:E

nti

tyR

elat

ionsh

ipD

iagr

amof

the

syst

em-P

art

1


Fig

ure

5.21

:E

nti

tyR

elat

ionsh

ipD

iagr

amof

the

syst

em-P

art

2


Fig

ure

5.22

:E

nti

tyR

elat

ionsh

ipD

iagr

amof

the

syst

em-P

art

3


Fig

ure

5.23

:E

nti

tyR

elat

ionsh

ipD

iagr

amof

the

syst

em-P

art

4


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


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:


Figure 5.24: Class Diagram of the Business Logic Layer-Part 1



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 :


Fig

ure

5.33

:C

lass

Dia

gram

ofth

eD

ata

Acc

ess

Lay

er-P

art

1


Fig

ure

5.34

:C

lass

Dia

gram

ofth

eD

ata

Acc

ess

Lay

er-P

art

2


Fig

ure

5.35

:C

lass

Dia

gram

ofth

eD

ata

Acc

ess

Lay

er-P

art

3


Fig

ure

5.36

:C

lass

Dia

gram

ofth

eD

ata

Acc

ess

Lay

er-P

art

4


Fig

ure

5.37

:C

lass

Dia

gram

ofth

eD

ata

Acc

ess

Lay

er-P

art

5


Fig

ure

5.38

:C

lass

Dia

gram

ofth

eD

ata

Acc

ess

Lay

er-P

art

6


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


Fig

ure

5.39

:C

lass

Dia

gram

ofth

eU

ser

Inte

rfac

eL

ayer

-Par

t1


Fig

ure

5.40

:C

lass

Dia

gram

ofth

eU

ser

Inte

rfac

eL

ayer

-Par

t2


Fig

ure

5.41

:C

lass

Dia

gram

ofth

eU

ser

Inte

rfac

eL

ayer

-Par

t3


Fig

ure

5.42

:C

lass

Dia

gram

ofth

eU

ser

Inte

rfac

eL

ayer

-Par

t4


Fig

ure

5.43

:C

lass

Dia

gram

ofth

eU

ser

Inte

rfac

eL

ayer

-Par

t5


Fig

ure

5.44

:C

lass

Dia

gram

ofth

eU

ser

Inte

rfac

eL

ayer

-Par

t6


Fig

ure

5.45

:C

lass

Dia

gram

ofth

eU

ser

Inte

rfac

eL

ayer

-Par

t7


Fig

ure

5.46

:C

lass

Dia

gram

ofth

eU

ser

Inte

rfac

eL

ayer

-Par

t8


Figure 5.48: Message Sequence Diagram of the Admin: User Management


Figure 5.49: Message Sequence Diagram of the Admin: Reporting Depart-ment


Figure 5.50: Message Sequence Diagram of the Admin: Designers


Figure 5.51: Message Sequence Diagram of the Admin: JobTypes-TestCases-SubTests


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,:


Figure 5.52: Message Sequence Diagram of the Project Director: Project


Figure 5.53: Message Sequence Diagram of the Project Director: Message


Figure 5.54: Message Sequence Diagram of the Project Director: Version


Figure 5.55: Message Sequence Diagram of the Project Director: Certificates

Figure 5.56: Message Sequence Diagram of the Project Director: Letters


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:


Figure 5.58: Message Sequence Diagram of the Project Manager: Job


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


Figure 5.60: Message Sequence Diagram of the Employee: Result Submission


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


Figure 5.62: System Sequence Diagram of the Admin: User Management-1


Figure 5.63: System Sequence Diagram of the Admin: User Management-2


Figure 5.64: System Sequence Diagram of the Admin: ReportingDepartment-1


Figure 5.65: System Sequence Diagram of the Admin: ReportingDepartment-2


Figure 5.66: System Sequence Diagram of the Admin: Designers-1


Figure 5.67: System Sequence Diagram of the Admin: Designers-2


Figure 5.68: System Sequence Diagram of the Admin: JobTypes-TestCases-SubTests-1


Figure 5.69: System Sequence Diagram of the Admin: JobTypes-TestCases-SubTests-2


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,:


Figure 5.70: System Sequence Diagram of the Project Director: Project-1


Figure 5.71: System Sequence Diagram of the Project Director: Project-2


Figure 5.72: System Sequence Diagram of the Project Director: System-1


Figure 5.73: System Sequence Diagram of the Project Director: System-2


Figure 5.74: System Sequence Diagram of the Project Director: Version-1


Figure 5.75: System Sequence Diagram of the Project Director: Version-2


Figure 5.76: System Sequence Diagram of the Project Director: Certificates


Figure 5.77: System Sequence Diagram of the Project Director: Letters


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:


Figure 5.79: System Sequence Diagram of the Project Manager: Job-1


Figure 5.80: System Sequence Diagram of the Project Manager: Job-2


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


Figure 5.82: System Sequence Diagram of the Employee: Job-2


Figure 5.83: System Sequence Diagram of the Employee: Result Submission-1


Figure 5.84: System Sequence Diagram of the Employee: Result Submission-2


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:


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


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


• 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-


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


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.