You are on page 1of 32

AN ANALYSIS AND DESIGN OF SOFTWARE VALIDATION SCHEME

USING SERVICE ORIENTED ARCHITECTURE

BAKTAVATCHALAM.G (08MW03)

MASTER OF ENGINEERING

Branch: SOFTWARE ENGINEERING

of Anna University

November 2008

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING


PSG COLLEGE OF TECHNOLOGY
(Autonomous Institution)
COIMBATORE – 641 004
Contents

CONTENTS

CHAPTER Page No.

Acknowledgement (i)
Synopsis (ii)
List of Figures (iii)
1. INTRODUCTION 1
1.1. Problem Definition 1
1.2. Objective of the Project 1
1.3. Significance of the Project 1
1.4. Outline of the Project 2
2. SYSTEM STUDY 3
2.1. Proposed System 3
3. SYSTEM ANALYSIS 5
3.1 Requirement Analysis 5
3.2 Feasibility Study 5
3.3 Technology Overview 6
4. SYSTEM DESIGN 8
4.1 Use case Diagram 8
4.2 Sequence Diagram 9
4.3 Collaboration Diagram 10
4.4 Activity Diagram 11
4.5 State chart Diagram 12
5. SYSTEM IMPLEMENTATION 13
5.1 Development 13
5.2 Implementation 15
6. TESTING 16
6.1 Unit Testing 16
6.2 Integration Testing 18
6.3 Sample Test Cases 19

7. SNAPSHOT 20
7.1 The GUI for sid input 20

iii
Contents

7.2 Accepted Software 21


7.3 SQA Details Update 22
7.4 Testing a query 25
CONCLUSION 26
FUTURE ENHANCEMENTS 27
BIBLIOGRAPHY 28

iv
Synopsis

SYNOPSIS

In this project, we do analysis and design of how the software validation is


done according to the given specifications. Here we store all the Standard Software
Specifications into some Database. Whenever the software Development Team finished
their development work, that software specifications are given to the Analyst.

The Analyst then gets Standard Specifications from Database as per that
Software Business & Problem Domain. Then he will do the validation of the Software
Specifications using Standard Specifications.

If the developed Software Specifications meet the Standard Specifications


then that Software is accepted otherwise it will sent to Development Team for Re-
Design.

Some of the Specifications includes Software Quality Metrics like CC,


LOC, FPA, Bugs Per LOC, Code Coverage, Cohesion, Coupling, … we can use any of
these or all of these.

ii
Future Enhancements

FUTURE ENHANCEMENTS

Currently, in the system developed with some minimal number of Quality


Attributes for the comparison, in future it comprises all the Attributes are included to give
the Software Quality Assurance.

27
List of Figures

LIST OF FIGURES

FIGURE NO LIST OF FIGURES PAGE NO.

Fig: 2.1 System Architecture 4

Fig: 4.1 Use case diagram 8

Fig: 4.2 Sequence diagram 9

Fig:4.3 Collaboration diagram 10

Fig:4.4 Activity diagram 11

Fig 4.5 State chart diagram 12

iii
Acknowledgement

ACKNOWLEDGEMENT
I wish to express our sincere gratitude to our respected Principal Dr. R.
Rudramoorthy for having given me the opportunity to undertake our project.

I also wish to express my sincere thanks to Dr. S. N. Sivanandam, Professor


and Head of the Department of Computer Science and Engineering, for his
encouragement and support that he extends towards the project work.

I extend my sincere thanks to our internal guide, Ms.Uma Maheswari, Lecturer,


Department of Computer Science and Engineering, for her guidance and help
rendered for the successful completion of the project.

Finally, I would like to thank all my friends without whom this project work would
not have been completed successfully.

i
Introduction Chapter 1

CHAPTER 1

INTRODUCTION

This chapter provides a brief overview of the Software Quality Assurance


System, objectives and significance of the project and an outline of the report.

1.1 PROBLEM DEFINITION


The Software Quality Assurance System validates the given software quality
attributes values and compare all with Standard quality attributes which are in Database.
So we conclude the developed software is had enough quality using this system.

1.2 OBJECTIVE OF THE PROJECT


Most of the users (in the project the Analyst) are interested in the user friendly
and easy working with the application. Also this system automatically gives the status
about the given software quality attributes. According to this system output the user may
choose the appropriate actions for that software.

1.3 SIGNIFICANCE OF THE PROJECT


With the enormous growth in Software validation, the Software is validated using
the given software quality attributes values and compare all with Standard quality
attributes which are in Database.

1
Introduction Chapter 1

1.4 OUTLINE OF THE PROJECT


The rest of the report is structures as follows. Chapter 2 provides a detailed study
of the existing system and the basic ideas of the proposed system. Chapter 3 discusses
the requirements for the development of the system and an analysis on the feasibility of
the system. Chapter 4 presents the overall design of the system. Chapter 5 discusses
the implementation details. Chapter 6 explains various testing procedures conducted on
the system. Chapter 7 contains the snapshot of various forms in our system. The last
section summarizes the project.

2
System Study Chapter 2

CHAPTER 2

SYSTEM STUDY
This chapter elucidates the existing system and a brief description of the
proposed system.

2.1 PROPOSED SYSTEM


In our system we do analysis and design of how the software validation is
done according to the given specifications. Here we store all the Standard Software
Specifications into some Database. Whenever the software Development Team finished
their development work, that software specifications are given to the Analyst. The
Analyst then gets Standard Specifications from Database as per that Software Business
& Problem Domain. Then he will do the validation of the Software Specifications using
Standard Specifications. If the developed Software Specifications meet the Standard
Specifications then that Software is accepted otherwise it will sent to Development Team
for Re-Design. Some of the Specifications includes Software Quality Metrics like CC,
LOC, FPA, Bugs Per LOC, Code Coverage, Cohesion, Coupling, … we can use any of
these or all of these.
Figure 2.1

Compare Quality
SQA Attributes
Database System

Display Results

Standard
Specifications Developed
Software
Specifications

3
System Analysis Chapter 3

CHAPTER 3

SYSTEM ANALYSIS
This section describes the hardware and software specifications for the
development of the system and an analysis on the feasibility of the system.

3.1 REQUIREMENT ANALYSIS


3.1.1 Software Requirements
After experimenting with various commercial software’s and analyzing the Pros
and Cons of the software, the following are chosen.
• Operating System – Platform Independent
• BPM developer – Cordys Studio
• Server – Microsoft SQL Server Group ( Enterprise Edition)

3.1.2 Hardware Requirements


The Hardware requirements of the proposed system are as follows:
• Pentium-III machine & above
• RAM-256 MB
• Hard Disk with a Capacity of 10 GB

3.2 FEASIBILITY ANALYSIS


Feasibility deals with step-by-step analysis of the system. Analysis showed that
this project was feasible in all respects. Three kinds of feasibility factors are considered:

• Economic Feasibility

• Technical Feasibility

• Operational Feasibility

5
System Analysis Chapter 3

3.2.1 Economic Feasibility

The system is developed only using those softwares that are very well used in
the market, so there is no need for installation of new softwares. Hence, the cost
incurred towards this project is negligible

3.2.2 Technical Feasibility

3.2.2.1 Maintaining
The main aim of our project is to maintain a book shop management database
system which could help a commercial user in his/her day to day business activities.
3.2.2 Operational Feasibility
The functions needed to be performed by the system are all valid and without
any conflicts. All functions and constraints specified in the requirements are completely
operational. The requirements stated are realistically testable.
The requirements are adaptable to changes with out any large-scale effects on
other system requirements. The system is capable of accommodating future
requirements if they arise.

3.3 TECHNOLOGY OVERVIEW

3.3.1 CORDYS STUDIO

The Business Process Management (BPM) is one of the main components of the
Cordys Business Operations Platform. Successful businesses need to be built-to-
change. However, many organizations are hindered by IT landscapes that are built-to-
last. Cordys closes this gap through a powerful, next generation BPM product that
enables organizations to change in real-time.
Cordys Business Process Management (BPM) puts business in direct control of their
processes, resulting in:
• Near zero lag time between an executive decision making and implementation
• Faster response to rapidly changing business conditions
• Continuous process improvement for higher efficiency and effectiveness
• Low risk leave-and-layer approach that repurposes existing applications and
systems

6
System Analysis Chapter 3

Cordys BPM embraces the Middle-Out design paradigm where business and IT
collaboratively define the backbone of a solution: the business process Cordys BPM
takes advantage of some of the latest internet innovations and standards. The result is a
100% browser-based process suite with a graphical and highly responsive user
interface. In addition, Cordys BPM offers enterprise-grade scalability, reliability, security
and standards support.

3.3.2 SQL Server Group

Microsoft SQL Server is a relational database management system (RDBMS)


produced by Microsoft. Its primary query languages are MS-SQL and T-SQL. SQL
Server Enterprise Edition is the full-featured version of SQL Server, including both the
core database engine and add-on services, while including a range of tools for creating
and managing a SQL Server cluster

7
System Design Chapter 4

CHAPTER 4

SYSTEM DESIGN

This chapter describes the functional decomposition of the system and illustrates
the movement of data between external entities, the processes and the data stores
within the system, with the help of UML diagrams.

4.1 USE CASE DIAGRAM

Software Standards

Software Database
Development Team

Software Documentation

Re-Design Standard Specifications

Decision Making Analyst

8
System Design Chapter 4

4.2 CLASS DIAGRAM

SDT Analyst_
pName : String
LOC : Long
verify()
Bugs : Long
getStds()
getProjSpec()
submit()
fix()

DB

storeProjSpec()
getProjSpec()
storeStdSpec()
getStdSpec()

4.2 SEQUENCE DIAGRAM

SDT Analyst DB
1: Developed Product

2: Req For Documentation

3: Doc and Specification

4: Process Doc

5: Retrieve Product Specifications

6: Req For STD Spec


7: Retrieve Spec

8: Spec Std's for that S/w

9: Compare Product Spec and Std Spec

10: If Re-Design Needed

11: Re-Design

9
System Design Chapter 4

4.3 COLLABORATION DIAGRAM

4: Process Doc
11: Re-Design 5: Retrieve Product Specifications
9: Compare Product Spec and Std Spec 7: Retrieve Spec

1: Developed Product
3: Doc and Specification 6: Req For STD Spec
SDT DB
Analyst

2: Req For Documentation 8: Spec Std's for that S/w


10: If Re-Design Needed

4. 4 ACTIVITY DIAGRAM

SDT Analyst DB

After SoftDev
No Get Standard
Spec
Std
Specification
Is Doc is
Ready ?
Validate Std Spec
Soft Spec
Documentation

Results ?

Re - Design Not Satisfied

OK. Fine

10
Implementation Chapter 5

CHAPTER 5

IMPLEMENTATION

This phase is broken up into two phases: Development and Implementation. The
individual system components are built during the development period.
During Implementation, the components built during development are put into
operational use.
In the development phase of our system, the following system components were
built.

5.1 DEVELOPMENT
The development of the library management system is as follows:

5.1.1 Database module


The module consists mainly creation of a database.
1. In Microsoft SQL Server group we created a new database named, lib
2. The required table, say sqa(sid,sdesc,cc,loc,fpa,r_cc,r_loc,r_fpa) is created.
3. In cordys studio, a new SOAP node is created under OLEDB metadata services.
4. This node is started.

5.1.2 Query Formulation


In the table we created a new method set. Inside the method set, we created a
set of methods with queries. A method is generated to display the sqa details, another to
update the table and one to display the software details. This method set is published to
runtime and imported to cordys studio.

13
Implementation Chapter 5

5.1.3 GUI module


In the repository of the cordys studio we created a new application model.
Xforms form its components. An Xform is created with a input box to input sid. A nother
Xform displays the sqa details. Then an Xform is created to input attributes required to
update the database. The updated details are displayed in another Xform. These xforms
are published to runtime and imported to the cordys studio.

5.1.4 BPM module


The flowchart is created with activity boxes. The Xforms and queries are mapped
to corresponding activities.

14
Implementation Chapter 5

5.2 IMPLEMENTATION

The BPM model is validated and published to runtime. It is then debugged to see
step wise execution. The figure below is a snapshot of the library BPM component.

15
Testing Chapter 6

CHAPTER 6

TESTING
This chapter explains the various testing procedures conducted on the system.
Testing is a process of executing a program with the intent of finding an error. A
successful test is one that uncovers an as yet undiscovered error. A testing process
cannot show the absence of defects but can only show that software errors are present.
It ensures that defined input will produce actual results that agree with the required
results. A good testing methodology should include
• Clearly define testing roles, responsibilities and procedures
• Establish consistent testing process
• Streamline testing requirements
• Overcome “requirements slow me down” mentality
• Common sense process approach
• Use some elements of existing Process
• Not an attempt to replace, rewrite or redefine Process
• To find defects early and to give good time to developers for bug fixes
• Independent perspective in testing

Some of the testing principles used in this project are:


• Unit Testing
• Integration Testing

6.1 UNIT TESTING


Unit testing is a strategy by which individual components, which make up the
system, are tested first to ensure that system works up to the desired extent. It focuses
on the verification effort on the smallest unit of the software design i.e. module. Various
modules of the system are tested to see whether they perform their intended functions.
Using procedural design description, important control paths are tested to uncover the

16
Testing Chapter 6

errors with in the boundary of the module. While accepting a connection using specified
functions we go for unit testing in their respective modules. The unit test is normally a
white box test (a testing method in which the control structure of the procedural design is
used to derive test cases).

6.1.1 Process Objectives


To test every unit of the software in isolation before integrating it with other units

6.1.2 Definition of Unit


A unit is a module as identified during size estimation process with a size
estimate that does not exceed 1000LOC.
For GUI applications each screen will be a unit.
If the size estimate for a unit exceeds 1000 LOC and it is not feasible to break it
into smaller logically independent units that can be tested in isolation, the project lead in
concurrence with the SQA can decide to define this as a unit.

6.1.3 Entry Criteria


The entry criteria for this process are the following:
• Unit completed
• Unit peer reviewed

6.1.4 Exit Criteria


The exit criteria for this process are the following:
• Unit test cases executed
• Any defects that are identified during unit testing and that are not fixed before the
unit enters component testing is listed in the test report and verified
• 100% statement coverage
If unit will be tested before code review of unit, this must be identified in the
project plan. In these projects the developer will self-review (desk check) the code
before unit testing.
In cases of exception handling of error conditions that are difficult to generate,
thereby making it impossible to achieve 100% statement coverage, the code should be
formally reviewed with this additional criteria

17
Testing Chapter 6

6.2 INTEGRATION TESTING


The integration testing is a systematic technique for constructing the program
structure while conducting tests to uncover errors associated with interfacing. It is a type
of testing by which the individual modules of the system are combined and tested
whether they work properly as a whole. The objective is to take unit test modules and
build a program that has been dictated by the design. Integration testing can be either
‘Incremental’ or ‘Non-Incremental’.
The objective of the integration testing is to help engineers plan and execute the
component and Integration testing for their respective projects.
Integration testing should include the following objectives:
• Performed by the product group/Dev test team after feature complete
• Determines that all product components on a list of specific platforms function
successfully together (The List specified in Master test plan)
• Performed in a basic product / platform environment (Basic environment
specified in Master test plan)
• Tests the product functionality against the specification
• Tests functionality of fake languages with sample single and double byte
languages
• Tests scaling to an acceptable minimum level as called out in the master test
plan
• Tests performance, reliability to an acceptable level as called out in the master
test plan
• Final integration tests done after all components are integrated, with the build in
production format
The tasks of the project have been integrated and the functioning of the entire
system has been found to be satisfactory. The functionality of the entire system has
been subjected to a series of tests and all the modules have been found to interoperate
properly.
Finally the integration testing was performed on the integrated system and found
to work properly.

18
Testing Chapter 6

6.3 SAMPLE TEST CASES

The following are the some of the sample test cases employed along with the
test results have been described in the table below.

Table 6.1 Sample Test Cases

Test Description Result


Is DB Connectivity is Accessible? OK
Is the new Software info updated in database? OK
Is the SQA attributes are properly checked? OK
Is user could find the application manageable? OK

19
Snapshot Chapter 7

CHAPTER 7

SNAPSHOT
This chapter contains the snapshot of various forms in our system.

7.1 The GUI for student id input - XForm

20
Snapshot Chapter 7

7.2 Authorized student details XForm

21
Snapshot Chapter 7

7.3 Adding the issued book details to the database

22
Snapshot Chapter 7

7.4 The details of issued book displayed – Xform

23
Snapshot Chapter 7

7.5 The Updated database

24
Snapshot Chapter 7

7.6 Testing a query

25
Conclusion

CONCLUSION

Thus the analysis, design and implementation of SQA system is done


successfully so that the user be able to do addition of a set of files in a database and the
user be able to view the file in a database created in SQL Server. This system is very
useful for Analyst who is maintaining Software Quality. Also the system is very easy for
managing the files and end user could easily understand the process of the system.

26
Bibliography

BIBLIOGRAPHY

• Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language,
3rd ed., Addison-Wesley. ISBN 0-321-19368-7.

• Penker, Magnus; Hans-Erik Eriksson (2000). Business Modeling with UML. John Wiley &
Sons. ISBN 0-471-29551-5.

• Elmasri Navathe, Somayajulu Gupta. Fundamentals of database system. Pearson Education


ISBN 81-7758-476-6

Websites
http://www.cordys.com/

http://www.uml-forum.com/FAQ.htm

28
APPENDIX

Creating a BPM

1. Cordys studio -> repository ->business models -> business process


model ->create new folder(right click on BPM) -> right click folder and create new
business process model ->create flow chart using start icon, stop icon and
activity boxes.

Creating an xform

1. repository ->application models ->xforms -> right click and create new
xform ->design xform.
2. right click xform ->publish to runtime.

Creating database

1. Microsoft enterprise manager -> console root -> Microsoft SQL servers -> SQL
server group -> SOALAB-VM\PSGINSTANCE ->databases -> create new
database -> tables-> right click table and create new table
2. To insert values in table -> right click table -> return all rows (password-
s0aadm1n)

Create soapnode

1. cordys menu -> psgsoa13 -> psgsoaorg7 -> administrator ->admin tools ->
soapnodes -> right click -> new -> a browser will open.
2. tick oledb integrator -> name your soapnode -> select all oledb methodsets ->
click next until provide details of oledb connector -> database vendor (sql server)
-> default database(your database name) ->provider (SQL OLEDB) -> db user
(sa) -> machine name ( SOALAB-VM\PSGINSTANCE) -> password(s0aadm1n) -
> click next and finish.