TNPProjectReport (APril 19)

A Report on
TRAINING AND PLACEMENT PORTAL

Submitted for partial fulfillment of award of
BACHELOR OF TECHNOLOGY
Degree
In
Computer Science & Engineering
By
Himanshi Goel
(1103010068)
Under the guidance of
Dr Pooja Tripathi
MENTOR
(Professor)
Mr. Devbrat Upadhyay
SUPERVISOR
(Software Engineer)
INDERPRASTHA ENGINEERING COLLEGE, GHAZIABAD

UPTU, LUCKNOW
April, 2015
Certificate
Certified that Himanshi Goel has carried out the project work
presented in this report entitled Training and Placement Portal for the
award of Bachelor of Technology from Inderprastha Engineering College,
Ghaziabad, under my supervision. The report embodies result of original
work and studies carried out by Student himself and the contents of the
report do not form the basis for the award of any other degree to the
candidate or to anybody else.
Mentor: Dr. Pooja Tripathi

(Professor)
Supervisor: Mr. Devbrat Upadhyay
(Software Engineer)
Date: April 11,2015
TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD
Abstract
Training and Placement Portal aims at providing the facility to automate and simplify the process
of registration and list generation of eligible students for placement activities. This system
provide facility to the Training and Placement Officer to do all their work that deals with
Placements like Collecting and analyzing Student records, posting Job Posts for various
companies visiting campus and thereby filtering Students as per companys requirements.
The Training and Placement Officer can also update details of students, if requested. TPO can
analyze the placements statistics, i.e. he/she can analyze number of placed and unplaced students
with respect to various criterions like batch wise, course wise, stream wise. TPO can also post
various notices related with jobs. The whole work is automated and is available on the Intranet.
ii
Acknowledgement
We take this opportunity to thank our teachers and friends who helped us
throughout the project.
First and foremost I would like to thank my guide for the project (Dr. Pooja
Tripathi, Professor, Computer Science Department and Mr. Devbrat
Upadhyay, Software Engineer) for her valuable advice and time during
development of project.
We would also like to thank (Prof. Ram Gopal, Computer Science Department)
for his constant support during the development of the project.
Name: Himanshi Goel

Roll No.: 1103010068
Signature:
iii
DECLARATION
I hereby declare that this submission is my own work and that, to the best of
my knowledge and belief, it contains no material previously published or
written by another person nor material which to a substantial extent has
been accepted for the award of any other degree or diploma of the university
or other institute of higher learning, except where due acknowledgment has
been made in the text.
Signature:
Name: Himanshi Goel
Roll No.: 1103010068
Date: April 11,2015
iv
Table of Contents
ACKNOWLEDGEMENTS
CERTIFICATE
LIST OF FIGURES
TABLES OF CONTENT
LIST OF FIGURES
LIST OF TABLE
CHAPTER 1: SYSTEM STUDY AND ANALYSIS
1.1. PRODUCT INFORMATION
1.1.1. PRODUCT PERSPECTIVE
1.1.2. PRODUCT FEATURES
1.1.3. PERFORMANCE ATTRIBUTE
1.2. REQUIREMENT ANALYSIS
1.2.1. FUNCTIONAL REQUIREMENT
1.2.2. NON FUNCTIONAL REQUIREMENT
1.3. FEASIBILITY STUDY
1.3.1. TECHNICAL FEASIBILITY
1.3.2. ECONOMICAL FEASIBILITY
1.3.3. SCHEDULED FEASIBILITY
1.3.4. OPERATIONAL FEASIBILITY
CHAPTER 2: SOFTWARE REQUIREMENT SPECIFICATION
2.1. INTRODUCTION
2.1.1. PURPOSE
2.1.2. PROBLEM STATEMENT
2.1.3. PROJECT OBJECTIVE
2.1.4. PROJECT SCOPE
2.1.3. OPERATING ENVIRONMENT
2.1.4. METHODOLOGY
2.1.5. DESIGN & IMPLEMENTATION CONSTRAINTS
2.2. SOFTWARE DEVELOPMENT LIFE CYCLE
2.2.1. INTRODUCTION TO SDLC
2.2.2. STAGES OF SDLC
2.2.3. SDLC MODELS
2.2.4. PROCESS MODEL ADOPTED
2.2.5. SYSTEM FEATURES
2.3. EXTERNAL INTERFACE REQUIREMENTS
2.3.1. USER INTERFACES
2.3.2. HARDWARE INTERFACES
2.3.3. SOFTWARE INTERFACES
II
III
IV
V
VIII
IX
2
2
4
5
5
6
7
7
7
10
10
11
11
11
12
13
14
15
16
23
25
26
27
27
CHAPTER 3: SYSTEM DESIGN

3.1. DATA FLOW DIAGRAM
3.2. CLASS DIAGRAM
3.3. SEQUENCE DIAGRAM
3.4. INPUT DESIGN
3.5. OUTPUT DESIGN
3.6. DATABASE DESIGN
3.7. TABLES
CHAPTER 4: THEORETICAL BACKGROUND
4.1. INTRODUCTION TO FRONT END
4.1.1. ABOUT THE PLATFORM (VISUAL C#)
4.1.2. DEVELOPING AN APPLICATION IN VISUAL C#
4.1.3. COMMON FEATURES
4.2. INTRODUCTION TO BACK END
4.2.1. INTRODUCTION TO DBMS
4.2.2. SQL SERVER 2000 DATABASE
4.2.3. DBMS ARCHITECTURE
30
33
34
37
37
38
40
47
47
49
50
52
53
CHAPTER 5: CODING
CHAPTER 6: SYSTEM MAINTENANCE
6.1. SOFTWARE MAINTENANCE
6.2. SYSTEM SECURITY
6.2.1. THREATS TO SYSTEM SECURITY
6.2.2. SYSTEM SECURITY MEASURES
6.3. SYSTEM TESTING
6.3.1. TESTING STAKEHOLDERS
6.4. TESTING STRATEGIES ADOPTED
6.4.1. UNIT TESTING
6.4.2. BLACK BOX TESTING
6.4.3. WHITE BOX TESTING
6.4.4. INTEGRATION TESTING
6.4.5. VALIDATION TESTING
6.4.6. OUTPUT TESTING
6.4.7. USER ACCEPTANCE TESTING
6.4.8. REGRESSION TESTING
55
56
56
57
58
58
58
58
59
59
59
59
CHAPTER 7: SNAPSHOTS AND RESULT

CHAPTER 8: CONCLUSION & FUTURE WORK
8.1. CONCLUSION & FUTURE WORK
CHAPTER 9: REFERENCES
9.1. REFERENCES
9.1.1. BOOKS REFRENCES
9.1.2. WEB REFRENCES
vi
vii
List of Figures
Figure 1 Graphical representation of the various stages of a typical SDLC
Figure 2 Prototype Model Phases
Figure 3 Diagrammatic representation of how Training and Placement Portal will work.
Figure 4 DFD Components
Figure 5 DFD (Level 0)
Figure 6 TPO DFD
Figure 7 Student DFD
Figure 10 ER Diagram
Figure 11 Login Sequence Diagram
Figure 12 Student Sequence Diagram
Figure 13 TPO Sequence Diagram
Figure 14 Users of DBMS
Figure 15 Cycle of requests and their associated responses
Figure 16 Three Tier Architecture of ASP.NET
Figure 17 Detailed diagram of Three Tier Architecture
Figure 18 Using multiple objects in the Data Access layer
Figure 19 A typical application with multiple "windows"
Figure 20 Each "window" has its own layers
Figure 21 Multiple Presentation layers sharing a single Business layer and Data Access
layer
viii
List of Tables
Table Name
1. UIAccessRights Table
2. AccessControlGroups Table
3. User Table
4. StudentDetails Table
5. QualificationDetails Table
6. CompanyDetails Table
7. JobPosts Table
8. JobPostNotices Table
9. PlacementRecord Table
10. SkillSetMaster Table
11. SegmentMaster Table
12. StudentRequest Table
13. StudentSkills Table
Page No
40
40
40
41
42
43
44
44
44
45
45
45
45
ix
Chapter 1:
System Study and Analysis
1.1 Product Information

1.1.1. Product Perspective
This project is mainly intended for automating this procedure that can help the people who
belong to the Training and Placement cell by saving their time, based on this basic operation
actually their activity is under two steps. The first one is, to maintain the list of students and their
credit records and the second job is to maintain the company details and based on the company
requirements, need to select the students and make the list of students branch wise, which is
more complex task, and here informing is through notice boards, where as this is also a bit old
fashioned task, which can be automated in our proposed system by posting job posts on the
intranet and by sending mails to the respective candidates. This proposed system is far
advantageous than the existing one in many cases such as retrieving the student details is easily
maintained in a manner that with just one click we can easily attain the details of the company
such as the responsible person contacts and company contact details such as address and phone
numbers can be maintained. Training and Placement cell mainly include the details of students.
The percentage of the students must be appropriate and true. The notices can be generated, so
that we notify all the departments, the corresponding information about campus recruitment
drives. The student details can also be viewed.
EXISTING SYSTEM AND ITS DRAWBACKS

The earlier system is not computerized. All transactions in the system are done manually like
maintaining records. To make this laborious job simple the clients have to computerize the
system.
The management and all the departments that have been carrying out this job using manually
makes the job more complicated and tedious most of the times. So, the best way is computerize
computerization of the current environment.
For example, in the earlier system placement officer has to collect student details for placements.
Approving those student details takes lot of time. Placement officer and students have to consult
each other directly if any information is needed. If any new company come for placements,
placement officer and his staff has to search the student details and they have to find the eligible
candidates for that particular company placement.
Here searching for eligible candidates takes lots of time. And sometimes some candidates details
may be missed.
Filling of forms by students
Here a form is given to students in which he/she has to fill with some details such as his name,
roll number, contact details, percentages(from first year to till date), Intermediate
particulars(name of institution, place, year of pass, percentage), SSC particulars(name of
institution, place, year of pass, percentage).
Collecting marks from green book Marks of each student are collected from green book (a book
containing marks and other details maintained by each department in college).
Preparing excel sheet from the data collected through filled-forms and green book, excel sheets
are prepared. These excel sheets are used to prepare a list of students who full-fill the
requirements of a company visiting the campus and these students are eligible to attend the
campus placement.
RECOGNITION OF NEED
For the purpose of training and placement of the student in colleges, TPOs have to collect all the
information of students and manages them manually and thus arranges the data according to
various streams.
If any modification is required that is to be also done manually. So, to reduce the job required to
manage students data manually and the information of various recruiters, a new system is
proposed which is processed through computers.
BOTTLENECKS OF PRESENT WORKING SYSTEM

The Job of TPO is a unique task that involves taking into considerations many details. Existing
system has some bottlenecks looked upon by TPOs and students of colleges. They are:
i)It takes so much time for a placement officer to collect students details and approving the
details provided by them.
ii) Poor communication between students and placement officer, so intimating about new
placements is a hard task.
iii) Students may not know about company details. Here also poor communication provides a
problem.
iv) Candidate may not get required information regarding companies visiting campus and
information about the job(profile) the company is offering.
v) It is a time consuming activity of managing, updating and informing specific student for
specific company requirements.
PROPOSED SOLUTIONS:
In the proposed system the TPO need not do all the hectic work. he will be provided with an
interface with which he can easily get his work done. The following are the facilities that are
provided by the system to the user.
i) Notice generation: Here TPO has to provide information about company name, date and venue
at which campus drive might take place. With this information the portal will generate a notice
which can be seen on students account to intimate students about placement drive.
ii) Student list generation: Here the TPO has to provide information about the requirements of
the company (such as, cut off percentage, whether backlogs allowed or not etc.).
iii) View student profile: Here the TPO is able to view a students profile of his interest by giving
the students roll number as input.
iv) Result analysis: Here the TPO is able to get the results which are released and store them for
later usage.
v) Posts: Here the TPO is provided to post updates or any necessary details to students depending
on his need.
vi) Reduce the paperwork and storage area.
vii) Improve the output of operators.
viii) Improve accuracy in result.
ix) Allow easy navigation through company information.
x) Manage the man and machine resources efficiently.
xi) It has user friendly interface having quick authenticated access to documents.
xii) Secured check in, check out & updates.
xiii) Easily scalable to grow with changing system requirement.
1.1.2 Product Features

i) Complete automation is possible in this sector, which is against the main disadvantage namely
time consuming.
ii) Can maintain student details who have been studying in the college.
iii) Any kind of lists based on students profile can be retrieved with in less time.
iv) Results are uploaded directly from the system so that no errors exist in calculating
percentages.
v) Effective and good means of communication can be facilitated mailing module is included in
the proposed system.
vi) TPO can view students profile and also update it as per requirement.
1.1.3. Performance Requirements:

i) The completely separate business logic at server side from the student interface ensures good
performance.
ii) The system exhibits high performance because it is well optimized. The business logic is
clearly separate from the User Interface.
iii) The response to the user is within seconds, providing all the information at a glance.
1.2 Requirement Analysis

We are overcoming the difficulty of student details which were manual in the current system and
here we generate detailed information about the students which will save our time to inform each
and every batch and section and student profile is maintained.
1.2.1. Functional Requirements

Students should be able to login to the system through the first page of the application, by
mentioning their required username and they should be able to view their details and request to
update the same. TPO can login into his account and he/she will update the student information.
It can filter students on the basis of certain criterion. Students as well as companies information
is maintained.
1.2.2. Non Functional Requirements

i) Performance requirements
The accountability is a vital feature and this could only be assured if the system is working in full
capability. So uninterrupted power supply is needed.
ii) Safety requirements
The data handled is very vital. The data are saved to the database at consecutive intervals. Power
is a significant feature and the power supply should be always taken care of. An Uninterrupted
Power Supply is always recommended.
iii) Software quality attributes
The source code can be easily modified and the system can be updated easily. This system is
flexible. Necessary changes can be done when needed.
iv) Usability
This section includes all of those requirements that effect usability. We get the response within
seconds. The software must have a simple, user-friendly interface so customers can save time
and confusion.
v) Reliability
The system is more reliable because of the qualities that are inherited from the chosen platform
dot NET. The code built by using dot NET is more reliable.
vi) Supportability
The system is designed to be the cross platform supportable. The system is supported on a wide
range of hardware and any software platform. This application is being developed using Visual
C#, hence it is extremely portable.
vii) Implementation
The system is implemented in web environment. The IIS is used as the web server and windows
XP/vista/7/8/10 is used as the platform.
viii) Interface
The user interface is based on the web browser. The application is developed using Visual C#
and .The Interface design is aimed at a flexible front-end communication to provide the user with
clear information in navigating a user-friendly interface is planned.
1.3. Feasibility Study

A feasibility analysis usually involves a thorough assessment of the operational (need), financial
and technical aspects of a proposal. Feasibility study is the test of the system proposal made to
identify whether the user needs may be satisfied using the current software and hardware
technologies, whether the system will be cost effective from a business point of view and
whether it can be developed with the given budgetary constraints. A feasibility study should be
relatively economical and done at the earliest possible time. Depending on the study, the decision
is made whether to go head with a more detailed analysis. When a new project is proposed, it
normally goes through feasibility assessment. Feasibility study is carried out to determine
whether the proposed system is possible to develop with available resources and what should be
the cost consideration.
Facts considered in the feasibility analysis were:
i) Technical Feasibility
ii) Economic Feasibility
iii) Scheduled Feasibility
iv) Operational Feasibility
Once you define a problem you have to analyze whether this is feasible or not, because all
possible solutions are not feasible and feasible one is not always possible. The detailed studies
carried out to check the work ability of proposed system. A feasibility study is a test of system
proposal regarding to its work ability, impact on the organization ability to meet user needs an
effective use of resources. Thus when a new application is proposed it normally goes through a
feasibility study before it is approved for deployment.
Thus during feasibility analysis for this project, following primary areas of interest are to be
considered. Investigating the existing system in the area under investigation and generating ideas
about a new system does this.
1.3.1. Technical Feasibility

Technical feasibility includes whether the technology is available in the market for development
and its availability. The assessment of technical feasibility must be based on an outline design of
system requirements in terms of input, output, files, programs and procedures. This can be
qualified in terms of volumes of data, trends, frequency of updating, cycles of activity etc, in
order to give an introduction of technical system. Considering our project it is technically
feasible. Training and Placement System, with its emphasis on a more strategic decision making
process is fast gaining ground as a popular outsourced function.
The study of resource availability that may affect the ability to achieve an acceptable system.
This evaluation determines whether the technology needed for the proposed system is available
or not.
i) It will avoid multiple file handling
ii) Report generation is very easy
iii) The new system provides full security of confidential data
1.3.2. Economical Feasibility

This feasibility study present tangible and intangible benefits from the project by comparing the
development and operational cost. The technique of cost benefit analysis is often used as a basis
for assessing economic feasibility. This system needs some more initial investment than the
existing system, but it can be justifiable that it will improve quality of service. Thus feasibility
study should center along the following points:
i) Improvement resulting over the existing method in terms of accuracy, timeliness.
ii) Cost comparison
iii) Estimate on the life expectancy of the hardware.
iv) Overall objective.
Our project is economically feasible. It does not require much cost to be involved in the overall
process. The overall objective is in easing out the recruitment processes. The system will be
developed and operated in the existing hardware and software infrastructure. So there is no need
for procuring additional hardware and software for the system. The proposed system will replace
the hectic cost and man power involved in the existing system. The employees will be trained in
using and operating the system, thus eliminating the need for recruiting employees. Thus the
project is economically feasible for the development of the company.
1.3.3. Scheduled Feasibility

An evaluation of the time, which is to be taken in the development of the project. The time
scheduled for the development of the project is very important since more development time
affects machine time, cost and cause delay in the development of other systems, so the project
should be completed within a fixed scheduled time as the company is concerned. Besides this,
the project is assigned to the student as an academic exercise to complete within a fixed schedule
of time.
1.3.4. Operational Feasibility

This analysis involves how it will work when it is installed and the assessment of managerial
environment in which it is implemented. People are inherently resistant to change and computers
have been known to facilitate change. The new proposed system is very much useful to the users
and therefore it will accept broad audience from around the world.
Chapter 2:
Software Requirement Specification (SRS)
2.1. Introduction
Software Requirements Specification is a complete description of the behavior of the system to
be developed. It includes asset of use cases that describe all the interactions the users will have
with the software. Use cases are also known as functional requirements. In addition to use cases,
the SRS also contains non-functional (or supplementary) requirements. Non-functional
requirements are requirements which impose constraints on the designer implementation (such as
performance engineering requirements, quality standards, or design constraints)
Training & Placement Portal aims at providing the Facility to automate and simplify the process
of registration and list generation of eligible students for placement. This system provide facility
to TPO to do all their Work Regarding Placement like Collecting Student Records, Registering
the Suitable Students, to check the number and percentage of placed & unplaced students, and
important announcements to other departments. The whole work is automated as well as on
Intranet.
2.1.1. Purpose
Computer based information system are designed to improve existing system. Whatever the
information, TPO has to pass to the student and he or she can inform online. Improve accuracy in
result. It has user friendly interface having quick authenticated access to documents. It provides
the facility of maintaining the details of the students. It will reduce the paper work and utilize the
maximum capabilities of the Setup and organization as well as it will save time and money
which are spending in making reports and collecting data. It can be accessed throughout the
organization and outside as well with proper login provided. This system can be used as an
application for college to manage the student information with regards to placement.
2.1.2. Problem Statement

This project is aimed at developing an online application for the Training and Placement
Department of the college. The system is an online application that can be accessed throughout
the organization with proper login provided. This system can be used as an application for the
TPO of the college to manage the student information with regards to placement. Students
logging should be able to view various job posts posted by TPO.
At present the new entries of company, college and candidates and technical problem are
managed manually. It is time consuming and much paper work is needed, also there are
possibilities of human error, as the transactions are done manually. Fake entries can be there.
System is more error-prone and time consuming. Difficulty in managing huge amount of data of
students. Large piles of records are to be maintained. TPOs have to collect the information of
various companies who want to recruit students and notify students time to time about them. It is
a time consuming activity of managing, updating and informing students for specific company
requirements.
2.1.3. Project Objective

The aim of the Training & Placement Office is to computerize all the work related with
training and its placement. It includes information about TPO and detail of each student. As the
technology is growing at a faster rate, the usage of manual system is reduced. We have planned
to develop automation for Training Placement Cell, this automation is developed based on web
application so the training and placement cell works are processed within the organization with
authorized people. In placement cell, the records are maintained in paper formats, thus it is a
tedious work to short list the students according to the companys requirements. To overcome
this problem, records of the students are updated by the authorized TPOr electronically rather
than manually. There will be unique user name and password for the TPOr.
The student only view the details of the records and can ask for updation of some personal
information like his/her contact number, email id. Only the authorized TPOr should have the
rights to insert, delete and update information into the database, thereby filtering candidate for
particular company.
The system proposed by us is beneficial to overcome the problem sited in the Placement. In the
manual, time is taken to prepare the records and the information of all Company and also
difficult to retrieve the information about the particular candidates, hence the computer section is
necessary to achieve perfect goal. Furthermore the human errors occur in the manual system can
be avoided by using the computerized system. The use of database management system is
appropriate in the environmental condition of Training & Placement Office.
2.1.4. Project Scope

Project has a big scope to do. We Students can maintain their information and can update it.
Notifications are sent to students about the companies. Students can access previous information
about placement. This system has scope of improvement amendments. In future, sector can
communicate with each other online. All currently active enquires can also be added in the
website to view if online. This application can be modified from time to time as per the changing
requirement of the user with lesser cost. Also the backend of the application can be changed as
per the storage requirement of the application and to provide more security level features.
2.1.5. Operating Environment
Operating System : Windows XP Prof. or above.

Processor : Pentium 4, 1.2 GHz or above.
Hard Disk : 40 GB or above.
RAM : 512 MB or above.
10
2.1.6. Methodology
PHASES:
i) Initiation Phase
The initiation of a system (or project) begins when a business need or opportunity is identified. A
Project Manager should be appointed to manage the project. This business need is documented in
a Concept Proposal. After the Concept Proposal is approved, the System Concept Development
Phase begins.
ii) System Concept Development Phase
Once a business need is approved, the approaches for accomplishing the concept are reviewed
for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the
system and requires Senior Official approval and funding before beginning the Planning Phase.
iii) Planning Phase
The concept is further developed to describe how the business will operate once the approved
system is implemented, and to assess how the system will impact employee and customer
privacy. To ensure the products and /or services provide the required capability on-time and
within budget, project resources, activities, schedules, tools, and reviews are defined.
Additionally, security certification and accreditation activities begin with the identification of
system security requirements and the completion of a high level vulnerability assessment.
iv) Requirement Analysis Phase
Functional user requirements are formally defined and delineate the requirements in terms of
data, system performance, security, and maintainability requirements for the system. All
requirements are defined to a level of detail sufficient for systems design to proceed. All
requirements need to be measurable and testable and relate to the business need or opportunity
identified in the Initiation Phase.
v) Design Phase
The physical characteristics of the system are designed during this phase. The operating
environment is established, major subsystems and their inputs and outputs are defined, and
processes are allocated to resources. Everything requiring user input or approval must be
documented and reviewed by the user. The physical characteristics of the system are specified
and a detailed design is prepared. Subsystems identified during design are used to create a
detailed structure of the system. Each subsystem is partitioned into one or more design units or
modules. Detailed logic specifications are prepared for each software module.
vi) Development Phase
The detailed specifications produced during the design phase are translated into hardware,
communications, and executable software. Software shall be unit tested, integrated, and retested
in a systematic manner. Hardware is assembled and tested.
11
vii) Integration and Test Phase

The various components of the system are integrated and systematically tested. The user tests the
system to ensure that the functional requirements, as defined in the functional requirements
document, are satisfied by the developed or modified system. Prior to installing and operating the
system in a production environment, the system must undergo certification and accreditation
activities.
viii) Implementation Phase
The system or system modifications are installed and made operational in a production
environment. The phase is initiated after the system has been tested and accepted by the user.
This phase continues until the system is operating in production in accordance with the defined
user requirements.
i.i) Operations and Maintenance Phase
The system operation is ongoing. The system is monitored for continued performance in
accordance with user requirements, and needed system modifications are incorporated. The
operational system is periodically assessed through In-Process Reviews to determine how the
system can be made more efficient and effective. Operations continue as long as the system can
be effectively adapted to respond to an organizations needs. When modifications or changes are
identified as necessary, the system may reenter the planning phase.
ix) Disposition Phase
The disposition activities ensure the orderly termination of the system and preserve the vital
information about the system so that some or all of the information may be reactivated in the
future if necessary. Particular emphasis is given to proper preservation of the data processed by
the system, so that the data is effectively migrated to another system or archived in accordance
with applicable records management regulations and policies, for potential future access.
2.1.7. Design & Implementation Constraints
User friendliness is provided in the application with various controls.

The system makes the overall project management much easier and flexible.
It can be accessed over Intranet.
Secured check in, check out & updates.
There is no risk of data mismanagement at any level while the project development is under
process.
12
2.2. Software Development Life Cycle

2.2.1. Introduction to Software Development Life Cycle
SDLC, Software Development Life Cycle is a process used by software industry to design,
develop and test high quality software. The SDLC aims to produce a high quality software that
meets or exceeds customer expectations, reaches completion within times and cost estimates. It
is also called as Software development process. The software development life cycle (SDLC) is a
framework defining tasks performed at each step in the software development process.
ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the
standard that defines all the tasks required for developing and maintaining software.
SDLC is a process followed for a software project, within a software organization. It consists of
a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
Figure 1 Graphical representation of the various stages of a typical SDLC
13
2.2.2. Stages of Software Development Life Cycle

A typical Software Development life cycle consists of the following stages:
Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by
the senior members of the team with inputs from the customer, the sales department, market
surveys and domain experts in the industry. This information is then used to plan the basic
project approach and to conduct product feasibility study in the economical, operational, and
technical areas.
Planning for the quality assurance requirements and identification of the risks associated with the
project is also done in the planning stage. The outcome of the technical feasibility study is to
define the various technical approaches that can be followed to implement the project
successfully with minimum risks.
Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product
requirements and get them approved from the customer or the market analysts. This is done
through .SRS. . Software Requirement Specification document which consists of all the product
requirements to be designed and developed during the project life cycle.
Stage 3: Designing the product architecture

SRS is the reference for product architects to come out with the best architecture for the product
to be developed. Based on the requirements specified in SRS, usually more than one design
approach for the product architecture is proposed and documented in a DDS - Design Document
Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as risk
assessment, product robustness, design modularity , budget and time constraints , the best design
approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if any).
The internal design of all the modules of the proposed architecture should be clearly defined with
the minute details in DDS.
Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming
code is generated as per DDS during this stage. If the design is performed in a detailed and
organized manner, code generation can be accomplished without much hassle.
Developers have to follow the coding guidelines defined by their organization and programming
tools like compilers, interpreters, debuggers etc are used to generate the code. Different high
level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The
programming language is chosen with respect to the type of software being developed.
Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However this stage refers to the testing
only stage of the product where products defects are reported, tracked, fixed and retested, until
the product reaches the quality standards defined in the SRS.
14
Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometime product deployment happens in stages as per the organizations. business
strategy. The product may first be released in a limited segment and tested in the real business
environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested enhancements
in the targeting market segment. After the product is released in the market, its maintenance is
done for the existing customer base.
2.2.3. Software Development Life Cycle Models

There are various software development life cycle models defined and designed which are
followed during software development process. These models are also referred as "Software
Development Process Models". Each process model follows a Series of steps unique to its type,
in order to ensure success in process of software development.
Following are the most important and popular SDLC models followed in the industry:
i) Build and Fix Model
ii) Waterfall Model
iii) Iterative Model
iv) Spiral Model
v) Prototype Model
The other related methodologies are Agile Model, RAD Model, Rapid Application Development
and Prototyping Models.
15
2.2.4. Process Model Adopted

The model that we used in implementation of TRAINING and PLACEMENT PORTAL is
Software Prototype Model. This model is explained as below.
The Software Prototyping refers to building software application prototypes which display the
functionality of the product under development but may not actually hold the exact logic of the
original software.
Software prototyping is becoming very popular as a software development model, as it enables
to understand customer requirements at an early stage of development. It helps get valuable
feedback from the customer and helps software designers and developers understand about what
exactly is expected from the product under development.
Prototyping is used to allow the users evaluate developer proposals and try them out before
implementation. It also helps understand the requirements which are user specific and may not
have been considered by the developer during product design.
Requirements Gathering
Quick Design
Refine requirements
incorporating
customer satisfaction
Build Prototype
Customer Evaluation
Design
Implementation and Unit Testing
Integration and System Testing
Operation and Maintenance

Figure 2 Prototype Model Phases
16
Following is the stepwise approach to design a software prototype:

i) Basic Requirement Identification: This step involves understanding the very basics product
requirements especially in terms of user interface. The more intricate details of the internal
design and external aspects like performance and security can be ignored at this stage.
ii) Developing the Initial Prototype: The initial Prototype is developed in this stage, where the
very basic requirements are showcased and user interfaces are provided. These features may not
exactly work in the same manner internally in the actual software developed and the
workarounds are used to give the same look and feel to the customer in the prototype developed.
iii) Review of the Prototype: The prototype developed is then presented to the customer and the
other important stakeholders in the project. The feedback is collected in an organized manner
and used for further enhancements in the product under development.
iv) Revise and enhance the Prototype: The feedback and the review comments are discussed
during this stage and some negotiations happen with the customer based on factors like , time
and budget constraints and technical feasibility of actual implementation. The changes accepted
are again incorporated in the new Prototype developed and the cycle repeats until customer
expectations are met.
Prototypes can have horizontal or vertical dimensions. Horizontal prototype displays the user
interface for the product and gives a broader view of the entire system, without concentrating on
internal functions. A vertical prototype on the other side is a detailed elaboration of a specific
function or a sub system in the product.
The purpose of both horizontal and vertical prototype is different. Horizontal prototypes are used
to get more information on the user interface level and the business requirements. It can even be
presented in the sales demos to get business in the market. Vertical prototypes are technical in
nature and are used to get details of the exact functioning of the sub systems. For example,
database requirements, interaction and data processing loads in a given sub system.
Software Prototyping Types:

There are different types of software prototypes used in the industry. Following are the major
software prototyping types used widely:
i) Throwaway/Rapid Prototyping: Throwaway prototyping is also called as rapid or close
ended prototyping. This type of prototyping uses very little efforts with minimum requirement
analysis to build a prototype. Once the actual requirements are understood, the prototype is
discarded and the actual system is developed with a much clear understanding of user
requirements.
ii) Evolutionary Prototyping: Evolutionary prototyping also called as breadboard prototyping is
based on building actual functional prototypes with minimal functionality in the beginning. The
prototype developed forms the heart of the future prototypes on top of which the entire system is
built. Using evolutionary prototyping only well understood requirements are included in the
prototype and the requirements are added as and when they are understood.
iii) Incremental Prototyping: Incremental prototyping refers to building multiple functional
prototypes of the various sub systems and then integrating all the available prototypes to form a
complete system.
17
iv) Extreme Prototyping: Extreme prototyping is used in the web development domain. It
consists of three sequential phases. First, a basic prototype with all the existing pages is
presented in the html format. Then the data processing is simulated using a prototype services
layer. Finally the services are implemented and integrated to the final prototype. This process is
called Extreme Prototyping used to draw attention to the second phase of the process, where a
fully functional UI is developed with very little regard to the actual services.
Software Prototyping Application
Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems. Systems which need users to fill out forms or go through
various screens before data is processed can use prototyping very effectively to give the exact
look and feel even before the actual software is developed.
Software that involves too much of data processing and most of the functionality is internal with
very little user interface does not usually benefit from prototyping. Prototype development could
be an extra overhead in such projects and may need lot of extra efforts.
Advantages of Prototype model

i) Users are actively involved in the development
ii) Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
iii) Errors can be detected much earlier.
iv) Quicker user feedback is available leading to better solutions.
v) Missing functionality can be identified easily
vi) Confusing or difficult functions can be identified
vii) Requirements validation, Quick implementation of, incomplete, but
functional, application.
Disadvantages of Prototype model

i) Leads to implementing and then repairing way of building systems.
ii) Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
iii) Incomplete application may cause application not to be used as the
full system was designed
iv) Incomplete or inadequate problem analysis.
When to use Prototype model

Prototype model should be used when the desired system needs to have a lot of interaction with
the end users.
Typically, online systems, web interfaces have a very high amount of interaction with end users,
are best suited for Prototype model. It might take a while for a system to be built that allows ease
of use and needs minimal training for the end user.
Prototyping ensures that the end users constantly work with the system and provide a feedback
which is incorporated in the prototype to result in a useable system. They are excellent for
designing good human computer interface systems.
18
2.2.5. System Features

i) Simplicity
Although it may seem old-fashioned, the aphorism all things in moderation applies to web
apps. There is tendency among some designers to provide the end-user with too muchexhaustive content, extreme visuals, intrusive animation, enormous web pages.
ii) Consistency
This design goal applies to virtually every element of the design model. Content should be
constructed consistently. Graphic design should present a consistent look across all parts of the
web app. Architectural Design should establish templates that led to consistent hypermedia
structures.
iii) Identity
The aesthetic, interface, and navigational design of a web app must be consistent with the
application domain for which it is to be built. The web app architecture will be entirely different
interfaces will be constructed to accommodate different categories of users; navigation will be
organized to accomplish different objectives.
iv) Robustness
Based on the identity that has been established, a web app often makes an implicit promise to a
user. The user expects robust content and functions that are relevant to the users need.
v) Compatibility
A web app will be used in a variety of environment (e.g. different hardware, operating
System) and must be designed to be compatible with each.
19
2.3. External Interface Requirements

2.3.1. User Interfaces
TPO: This module contains all the information about the TPO. He can add all the students as
well as company that is going to visit campus for the recruitment. TPO can post jobs. Allow TPO
to verify the details of the student, and to approve the same if their request is correct. TPO can
also filter the students on the basis of criterion led down by the company and can communicate
with those students via emails or messages. Allow TPO to insert/update statistics like no. of
students placed. Allow TPO to add/insert an events. Also allow TPO to upload materials (like
notices related with job posts).
Student: This module contains all the information related to the students. Students are the
registered person who will edit their personal details like their contact numbers, email ids. They
can also request for updation of their particular details like their marks. They can also see the list
of companies visiting the campus.
Company: This module contains all the information related to various companies visiting the
campus.
Guest: The guests can be Directors, HODs of various departments, or the faculties, they can
view the statistics of placements till date. Statistics can be viewed to them in various perspectives
like batch wise, branch wise, percentage wise.
Figure 3: Diagrammatic representation of how Training and Placement Portal work.
20
2.3.2. Hardware Interfaces
Processor -------- Pentium 4, 1.2 GHz or above.

Hard Disk: -------- 40 GB or above.
RAM: -------- 1GB or above.
2.3.3. Software Interfaces

Operating System: Windows 2007/xp/2010
Backend: SQL Server 2012
Frontend: Visual Studio 2010
Server: IIS
Scripting Languages: JavaScript
Server Side Scripting: Asp.net
Markup Languages: HTML, XML
(To be discussed)
21
Chapter 3:
SYSTEM DESIGNING
22
System design
Software analysis and design includes all activities, which help the transformation of
requirement specification into implementation. Requirement specifications specify all functional
and non-functional expectations from the software. These requirement specifications come in the
shape of human readable and understandable documents, to which a computer has nothing to do.
Software analysis and design is the intermediate stage, which helps human-readable
requirements to be transformed into actual code.
The design data structure, software architecture, software architecture, software representation
and procedure detail is specified. The design process translate requirement into a representation
if the software. The suggested system is Establishment. Design is the process of applying the
various techniques and principles for the purpose of defining a device, a process or a system in
sufficient detail to permit its physical realization.
The system design is carried out in two phases:i) The architecture design (High Level Design)
ii) The detailed design (Low Level Design)
High Level Design:The high level design, describes the actual processes of the system, i.e. the information flow of
the system. In this phase we identified all the entities or in other words we can say external
source. That is, in this phase we represent flow graphically, this is known as DFD (Data Flow
Diagram).
Low Level Design:In the low level design, first we collect all the data in the form of tables. The name of entity is
taken as the name of tables. The process is known as Fast Patch Table. The next important step
after the designing of tables is actual coding of the program. The code of program is written and
tested separately.
23
3.1. DATA FLOW DIAGRAMS

Data flow diagram is graphical representation of flow of data in an information system. It is
capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not
mention anything about how data flows through the system.
It is a graphic tool used to describe and analyze the moment of data through a system manualor
automated including the processes, stores of data, and delays in the system. Data flow diagrams
are the central tools and the basis from which other components are developed.
The transformation of data from input to output, through processes, may be described logically
and independently of the physical components associated with the system.
Data Flow Diagram is a means of representing a system at any level of detail with a graphic
network of symbols showing data flows, data stores, data processes and data sources.
The purpose of data flow diagram is to provide a semantic bridge between users and system
developers. The diagram is the basis of structured system analysis. A DFD describes what data
flows rather than how they are processed, so it does not depend on hardware, software, data
structure or file organization.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD does
not contain any control or branch elements.
Types of DFD
.i) Logical DFD - This type of DFD concentrates on the system process, and flow of data in the
system. For example in a Banking software system, how data is moved between different
entities.
ii) Physical DFD - This type of DFD shows how the data flow is actually implemented in the
system. It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of
components -
Figure 4 DFD Components
Entities - Entities are source and destination of information data. Entities are represented
by a rectangle with their respective names.
Process - Activities and action taken on the data are represented by Circle or Roundedged rectangles.
Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with only one
side missing.
Data Flow - Movement of data is shown by pointed arrows. Data movement is shown
from the base of arrow as its source towards head of the arrow as destination.
24
Figure 6 TPO DFD
Figure 7 Student DFD
25
26
3.2. Entity Relationship Diagram

An entity-relationship diagram (ERD) is a data modeling technique that graphically illustrates an
information systems entities and the relationships between those entities. An ERD is a
conceptual and representational model of data used to represent the entity framework
infrastructure.
The elements of an ERD are: Entities, Relationships, Attributes.
27
3.3. Sequence Diagrams:

A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals
with some sequences, which are the sequence of messages flowing from one object to another.
Interaction among the components of a system is very important from implementation and
execution perspective.
So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific
functionality.
UML sequence diagrams are used to show how objects interact in a given situation. An
important characteristic of a sequence diagram is that time passes from top to bottom: the
interaction starts near the top of the diagram and ends at the bottom (i.e. Lower equals Later).
A popular use for them is to document the dynamics in an object-oriented system. For each key
collaboration, diagrams are created that show how objects interact in various representative
scenarios for that collaboration.
Login Sequence Diagram
Figure 11 Login Sequence Diagram
28
Student Sequence Diagram:
Figure 12 Student Sequence Diagram
29
TPO Sequence Diagram
Figure 13 TPO Sequence Diagram
30
3.4. DATABASE DESIGN

Data base is designed to manage large bodies of information. The management of data involves
both the definitions of structures for the storage of information. In addition the data base system
must provide for the safety of the information solved, despite system crashes or due to attempts
at unauthorized access. For developing an efficient database we have to fulfill certain conditions
such as controlled redundancy.
i) Defining the data
ii) Inputting the data
iii) Locating the data
iv) Accessing the data
v) Communicating the data
vi) Revising the data
Objectives of Data base design
In this data base design several objectives are designed such as :
i) Ease of use
ii) Control of data integrity
iii) Control of redundancy
iv) Control of security
v) Data independence (logical & physical)
vi) Data storage protection
vii) System performance
viii) System functions
ix) System compatibility
For achieving the abovementioned criterias we have to make use of various features that are
available with the RDBMS by enforcing integrity constrains, we can ensure data integrity and
reduce data inconsistency to a great extend.
DATA DICTIONARY
A data dictionary is a catalogue a repository of the elements in a system. As the name
suggests, these elements center on data the way they are structured to meet user requirements and
organization needs. In a data dictionary you will find a list of all the elements composing the data
flow through a system.
31
3.7. Tables
AccessControlGroups Table
Fields
AccessControlGroupId
Name
Description
ModTs
Data Type
int
varchar
varchar
Size
Data Type
int
int
int
bit
bit
Size
Data Type
uniqueidentifier
int
varchar
varchar
int
varchar
varchar
bit
Size
100
200
Description
Access Control Group Id
Name
Description
Constraints
Primary Key
Description
Access Control Group Id
Security Profile Id
College Id
view
Edit
Constraints
Description
Unique Id
College Id
User Id
Name
Security Profile Id
Salt
Salted Hashed
Is Active
Constraints
Primary Key
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
UIAccessRights Table
Fields
AccessControlGroupId
SecurityProfileId
CollegeId
[view]
Edit
ModTs
NOT NULL
NOT NULL
NOT NULL
User Table
Fields
UniqueId
CollegeId
UserId
Name
SecurityProfileId
Salt
SaltedHashed
IsActive
ModTs
15
50
50
MAX
32
StudentDetails Table
Fields
StudentId
FullName
ActualName
FirstName
MiddleName
LastName
FatherName
Dob
Sex
AddressCorrespondence
ContactNo
PermanentAdd
PermanentContact
MobileNum
EmailId
StudentPinNo
RollNo
EnrollmentNo
AdmissionNum
AdmissionSessionId
StatusId
SessionId
CourseId
SemesterId
YearId
ModTs
Data Types
int
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
datetime
varchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
varchar
char
char
nvarchar
int
int
int
int
int
int
Size
20
50
15
15
15
50
6
250
100
250
100
20
50
12
15
15
50
Description
Student Id
Full Name
Actual Name
First Name
Middle Name
Last Name
Father Name
Dob
Sex
Address Correspondence
Contact No
Permanent Address
Permanent Contact
Mobile Number
Email Id
Student Pin No
Roll No
Enrollment No
Admission Number
Admission Session Id
Status Id
Session Id
Course Id
Semester Id
Year Id
ModTs
Constraints
Primary Key
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
33
QualificationDetails Table
Fields
IdQualification
StudentId
TenthBoard
TenthMedium
TenthPassingYear
TenthPercentageGrade
TwelthBoard
TwelthMedium
TwelthPassingYear
TwelthPercentageGrade
GraduationUniversity
GraduationMedium
GraduationPassingYear
GraduationPercentGrade
PostGradUniv
PostGradMedium
PostGradPassingYear
PostGradPercentGrade
DiplomaUniversity
DiplomaMedium
DiplomaPassingYear
DiplomaPercentGrade
DiplomaMarksheet
GraduationMarksheet
GapCertificate
TenthMarksheet
TenthCertificate
TwelthMarksheet
TwelthCertificate
DegreeCertificate
DiplomaCertificate
Per_ten
ModTs
Data Type
int
int
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
nvarchar
bit
bit
bit
bit
bit
bit
bit
bit
bit
decimal(18,2)
Size
100
10
10
25
100
10
10
25
100
10
10
25
100
10
10
25
100
10
10
25
Description
Qualification Id
Student Id
Tenth Board
Tenth Medium
Tenth Passing Year
Tenth Percentage Grade
Twelfth Board
Twelfth Medium
Twelfth Passing Year
Twelfth Percentage Grade
Graduation University
Graduation Medium
Graduation Passing Year
Graduation Percent Grade
Post Graduation University
Post Graduation Medium
Post Graduation Passing Year
Post Graduation Percent Grade
Diploma University
Diploma Medium
Diploma Passing Year
Diploma Percent Grade
Diploma Marksheet
Graduation Marksheet
Gap Certificate
Tenth Marksheet
Tenth Certificate
Twelfth Marksheet
Twelfth Certificate
Degree Certificate
Diploma Certificate
****Percentage
ModTs
Constraints
Primary Key
34
CompanyDetailsTable
Fields
CompanyId
CompanyName
CompanyLogo
CompanyWebsite
CompanyHeadquarter
PhoneNo
Fax
Email
CompanyProfile
ModTs
Data Type
uniqueidentifier
varchar
image
varchar
varchar
varchar
varchar
varchar
text
datetime
Size
Data Type
uniqueidentifier
uniqueidentifier
int
varchar
varchar
varchar
text
varchar
date
date
date
varchar
varchar
varchar
varchar
varchar
Size
200
100
20
20
20
50
Description
Company Id
Company Name
Company Logo
Company Website
Company Headquarter
Phone Number
Fax No
Email Address
Company Profile
Constraints
Primary Key
NOT NULL
Description
Job Post Id
Company Id
Segment Id
Designation
Annual Salary
Joining Location
Job Details
Event Venue
Event Date
Valid Upto
Job Post Date
Placement Type
Bond Period
Training Period
Event Time
Valid Upto Time
Constraints
Primary Key
FK(CompanyDetails)
NOT NULL
JobPosts Table
Fields
JobPostId
CompanyId
SegmentId
Designation
AnnualSalary
JoiningLocation
JobDetails
EventVenue
EventDate
ValidUpto
JobPostDate
PlacementType
BondPeriod
TrainingPeriod
EventTime
ValidUptoTime
ModTs
50
MAX
50
100
50
50
50
10
10
NOT NULL
NOT NULL
35
JobPostNotices Table
Fields
JobPostNoticeId
JobPostId
Description
Link
JobPostNoticeDate
ModTs
Data Type
uniqueidentifier
uniqueidentifier
varchar
varchar
date
Size
Description
Job Post Notice Id
Job Post Id
Job Description
Apply Link
Job Post Notice Date
Constraints
Primary Key
FK(JobPosts)
NOT NULL
NOT NULL
NOT NULL
Constraints
Description
Student Id
Job Post Id
Job Posted Date
Placement Track Id
Size
5
50
Description
Skill Set Id
Skill Details
Constraints
Primary Key
NOT NULL
MAX
80
PlacementRecord Table
Fields
StudentId
JobPostId
PostedOn
PlacementTrackId
ModTs
Data Type
int
uniqueidentifier
date
varchar
Size
NOT NULL
NOT NULL
NOT NULL
SkillSetMaster Table
Fields
SkillSetId
SkillDetails
ModTs
Data Type
varchar
varchar
36
SegmentMaster Table
Fields
SegmentId
SegmentName
ModTs
Data Type
int
char(100)
Size
100
Description
Segment Id
Segment Name
Fields
Primary Key
NOT NULL
Description
RequestId
StudentId
UpdateField
UpdateValue
Constraints
Primary Key
FK(StudentDetails)
NOT NULL
NOT NULL
Description
Student Skill Id
Student Id
Skill Set Id
Experience
Constraints
Primary Key
FK(StudentDetails)
StudentRequest Table
Fields
RequestId
StudentId
UpdateField
UpdateValue
ModTs
Data Type
uniqueidentifier
int
varchar
varchar
Size
50
100
StudentSkills Table
Fields
StudentSkillId
StudentId
SkillSetId
Experience
ModTs
Data Type
uniqueidentifier
int
varchar
int
Size
37
CHAPTER 4:
THEORETICAL BACKGROUND
38
4.1. Introduction to Front End

4.1.1. About the Platform (Visual C#):
C# (pronounced "C-sharp") is an object-oriented programming language from Microsoft that
aims to combine the computing power of C++ with the programming ease of Visual Basic. C# is
based on C++ and contains features similar to those of Java.
C# is designed to work with Microsoft's .Net platform. Microsoft's aim is to facilitate the
exchange of information and services over the Web, and to enable developers to build
highly portable applications. C# simplifies programming through its use of Extensible Markup
Language (XML) and Simple Object Access Protocol (SOAP) which allow access to a
programming object or method without requiring the programmer to write additional code for
each step. Because programmers can build on existing code, rather than repeatedly duplicating it,
C# is expected to make it faster and less expensive to get new products and services to market.
Microsoft is collaborating with ECMA, the international standards body, to create a standard for
C#. International Standards Organization (ISO) recognition for C# would encourage other
companies to develop their own versions of the language. Companies that are already using C#
include Apex Software, Bunka Orient, Component Source, devSoft, Far Point Technologies,
LEAD Technologies, Proto View, and Seagate Software.
4.1.2. Developing an application in Visual C#

It takes only few minutes to build an application in Visual C# application you create the user
interface by drawing the controls on the form. For example: text boxes, command buttons, check
boxes etc. Next you set the properties for the form and the controls on your form. You can
specify the multiple values such as caption (name for any control to be displayed) color and size.
Finally, you have written some code and your application is ready to run you can run it and test it
before final use of .exe file.
Event Driven Programming

Visual C# is object based language which means it works around the objects created by the user
or those which are pre-defined and it is event driven which all the activities in a program is
triggered on the occurrence of a particular event. Each object has its own properties determining
its position, size, color and the type of text its takes fonts etc. Each object has its own event
handling procedure. The Visual C# system knows all about these already. It knows that this is a
button and how it works. It also knows how to handle the images and all the menus, dialog
boxes, drives and directories and all the stuff which is included within the package. We just have
to tell it through the programming that what to do and when to do it i.e. what command it has to
execute at which event. For instance - a widow closes on the click event of exit button. We dont
have to write anything about these events the Visual C# knows how much events can be
performed on any object; a programmers job is to just write the action to be performed on that
event. The process of program design reflects the nature of the system. In the Visual C# we have
saved in the form of project a project can have multiple forms, modules & so on.
39
Forms Control menus:

The first step to creating an application with Visual C# is to create with interface. The visual part
of the application with which user will interact. Forms & controls are the basic building blocks
used to create an interface. These are the object that we will work with to build our application.
By setting the properties, of the forms and writing the visual code to respond to its events, you
customize the objects to meet the requirements of your application.
Controls are objects that are contained within the forms object. Each type of control has its own
set of properties, methods and events that make it suitable for entering or displaying the text.
Other controls let you access other applications and process data as if the remote application was
part of your code. To create an application with visual C#, you work with projects. A project is
the collection of all the files that you use to build an application.
When you create an application, you will usually create new forms. You might also reuse of
modify of forms that were created for previous projects. The same is true for objects from other
applications can also be shared between the projects.+
After all of the basic building blocks of visual C# application, the actual windows with which a
user interacts when they run the application. Forms have their own properties, events & methods
with which you can control their appearance & behavior.
Microsoft Visual Studio is an Integrated Development Environment (IDE) from Microsoft. It can
be used to develop console and graphical user interface applications along with Windows
Forms applications, web sites, web applications, and web services in both native code together
with managed code for all platforms supported by Microsoft Windows, Window Mobile,
Windows CE, .NET Framework, .NET Compact Framework and Microsoft Silverlight. Visual
Basic 9.0 was released together with the Microsoft .NET Framework 3.5 on 19 November 2007.
ASP.NET is a set of Web development tools offered by Microsoft. Programs like Visual Studio
.NET and Visual Web Developer allow Web developers to create dynamic websites using a
visual interface. ASP.NET also supports Visual Basic .NET, Jscript, .NET and open-source
languages like Python and Perl. .NET provides a visual interface for developers to create their
applications, which makes .NET a reasonable choice for designing Web-based interfaces as well.
SQL Server is a relational database developed and sold by Microsoft. Originally bought from
Sybase, Microsoft have released versions 6, 6.5, 7, 2000 and 2005. The Express Edition of SQL
Server 2005 is used in the C++ and C#.
40
4.1.3. Common Features

Microsoft added many features including:
i) Debugging the .NET source code
VS2008 has integrated debugging support so that you can step into the framework libraries.
Visual Studio will automatically download the source file from Microsofts server and you will
get full watch and breakpoint support.
ii) Visual Studio Split View
It is becoming increasingly more common to have multiple monitors on developers desks.
Building on the split window feature of VS 2005, Visual Studio 2008 now allows you to tile
the window horizontally or vertically so you can split your design and code view across monitors
iii) C# 3.0 support
Things like automatic properties, lambda expressions (which reduce your typing for anonymous
delegates), partial methods, anonymous types and extension methods will radically change how
you can build applications. They will cut down your typing and provide for some really cool
ways to enhance and evolve your projects.
iv) Refactoring enhancements
The refactoring support was a welcome addition to VS 2005 - and Microsoft has enhanced the
support in 2008 to support C# 3.0 features and allow you to refactor anonymous types, extension
methods and lambda expressions.
v) Organize your "using" statements
Visual Studio now has the ability to organize your using statements. As a project evolves, you
often end up with a ton of using statements at the top of each file which are not really being used
- either because the project template added it, or because you originally did use something from
that namespace which was then removed later. Now you can right click on your using statements
and sort and/or remove unused namespaces.
vi) Better IntelliSense support
Visual Studio now has IntelliSense and code completion support! Its smart enough to look at the
underlying type currently assigned and correctly infer the methods which are available. Visual
Studio will also look at the comments applied to your methods- just like in C# and VB.NET, it
will pull descriptions out of XML based comments on your JavaScript methods and display
descriptions as tooltips when you are navigating the IntelliSense dropdown. Now if you press a
letter and start typing, it will begin to restrict your choices displayed, not just scroll to that
section. This filters the output and makes it easier to find what you are looking for.
vii) Multi-framework targeting
This release of Visual Studio has a much-needed feature that I wish had been there before - the
ability to target multiple versions of .NET. Specifically, you can select your target framework
(2.0 SP1, 3.0 or 3.5) and the project types, toolbox, references, IntelliSense and features will be
appropriately set to that version. This selection can occur during project creation - in the project
templates dialog or on the project properties dialog. Be aware that selecting .NET Framework
2.0 actually means 2.0 SP1 and not the original .NET 2.0 framework released with Visual Studio
2005.
41
4.2. INTRODUCTION TO BACK END

4.2.1. Introduction to Database Management System
Database is a collection of related data and data is a collection of facts and figures that can be
processed to produce information.
Mostly data represents recordable facts. Data aids in producing information, which is based on
facts. For example, if we have data about marks obtained by all students, we can then conclude
about toppers and average marks.
A Database Management System stores data in such a way that it becomes easier to retrieve,
manipulate, and produce information.
To build up any application or any software, which is to be implemented, the database performs
very important role. We should know about database how to make database, how to establish the
relation between database & how to implement these functions for making good and efficient
software. For the project of Training & Placement Portal, as it is a System Software, so we have
taken SQL Server 2000 database for building application database. Thus it is necessary to talk
about this database system. It is also important to think what is the purpose of creating database.
Here are some key features like tables, fields and expression of SQL Server which is being taken
by us as a back end.
Characteristics
Traditionally, data was organized in file formats. DBMS was a new concept then, and all the
research was done to make it overcome the deficiencies in traditional style of data management.
A modern DBMS has the following characteristics
i) Real-world entity A modern DBMS is more realistic and uses real-world entities to design
its architecture. It uses the behavior and attributes too. For example, a school database may use
students as an entity and their age as an attribute.
ii) Relation-based tables DBMS allows entities and relations among them to form tables. A
user can understand the architecture of a database just by looking at the table names.
iii) Isolation of data and application A database system is entirely different than its data. A
database is an active entity, whereas data is said to be passive, on which the database works and
organizes. DBMS also stores metadata, which is data about data, to ease its own process.
iv) Less redundancy DBMS follows the rules of normalization, which splits a relation when
any of its attributes is having redundancy in values. Normalization is a mathematically rich and
scientific process that reduces data redundancy.
v) Consistency Consistency is a state where every relation in a database remains consistent.
There exist methods and techniques, which can detect attempt of leaving database in inconsistent
state. A DBMS can provide greater consistency as compared to earlier forms of data storing
applications like file-processing systems.
vi) Query Language DBMS is equipped with query language, which makes it more efficient
to retrieve and manipulate data. A user can apply as many and as different filtering options as
required to retrieve a set of data. Traditionally it was not possible where file-processing system
was used.
vii) ACID Properties DBMS follows the concepts of Atomicity, Consistency, Isolation,
and Durability (normally shortened as ACID). These concepts are applied on transactions, which
manipulate data in a database. ACID properties help the database stay healthy in multitransactional environments and in case of failure.
42
viii) Multiuser and Concurrent Access DBMS supports multi-user environment and allows
them to access and manipulate data in parallel. Though there are restrictions on transactions
when users attempt to handle the same data item, but users are always unaware of them.
ix) Multiple views DBMS offers multiple views for different users. A user who is in the Sales
department will have a different view of database than a person working in the Production
department. This feature enables the users to have a concentrate view of the database according
to their requirements.
x) Security Features like multiple views offer security to some extent where users are unable
to access data of other users and departments. DBMS offers methods to impose constraints while
entering data into the database and retrieving the same at a later stage. DBMS offers many
different levels of security features, which enables multiple users to have different views with
different features. For example, a user in the Sales department cannot see the data that belongs to
the Purchase department. Additionally, it can also be managed how much data of the Sales
department should be displayed to the user. Since a DBMS is not saved on the disk as traditional
file systems, it is very hard for miscreants to break the code.
Users
A typical DBMS has users with different rights and permissions who use it for different
purposes. Some users retrieve data and some back it up.
Figure 14: Users of DBMS
TPO TPO maintain the DBMS and are responsible for administrating the database. They are
responsible to look after its usage and by whom it should be used. They create access profiles for
users and apply limitations to maintain isolation and force security. TPO also look after DBMS
resources like system license, required tools, and other software and hardware related
maintenance.
Designers Designers are the group of people who actually work on the designing part of the
database. They keep a close watch on what data should be kept and in what format. They identify
and design the whole set of entities, relations, constraints, and views.
End Users End users are those who actually reap the benefits of having a DBMS. End users
can range from simple viewers who pay attention to the logs or market rates to sophisticated
users such as business analysts.
43
4.2.2. SQL Server 2000 Database

Microsoft SQL Server 2000 is a full-featured relational database management system (RDBMS)
that offers a variety of administrative tools to ease the burdens of database development,
maintenance and administration.
The six frequently used tools of SQL Server are as follows:i) Enterprise Manager:
Enterprise Manager is the main administrative console for SQL Server installations. It provides
you with a graphical "birds-eye" view of all of the SQL Server installations on your network.
You can perform high-level administrative functions that affect one or more servers, schedule
common maintenance tasks or create and modify the structure of individual databases.
ii) Query Analyzer:
Query Analyzer offers a quick and dirty method for performing queries against any of your SQL
Server databases. It's a great way to quickly pull information out of a database in response to a
user request, test queries before implementing them in other applications, create/modify stored
procedures and execute administrative tasks.
iii) SQL Profiler:
SQL Profiler provides a window into the inner workings of your database. You can monitor
many different event types and observe database performance in real time. SQL Profiler allows
you to capture and replay system "traces" that log various activities. It's a great tool for
optimizing databases with performance issues or troubleshooting particular problems.
iv) Service Manager:
Service Manager is used to control the MS-SQL Server (the main SQL Server process), MSDTC
(Microsoft Distributed Transaction Coordinator) and SQL Server Agent processes. An icon for
this service normally resides in the system tray of machines running SQL Server. You can use
Service Manager to start, stop or pause any one of these services.
v) Data Transformation Services:
Data Transformation Services (DTS) provide an extremely flexible method for importing and
exporting data between a Microsoft SQL Server installation and a large variety of other formats.
The most commonly used DTS application is the "Import and Export Data" wizard found in the
SQL Server program group.
44
4.2.3. DBMS Architecture

The architecture that we are using to build Training and Placement Portal is the Three Tier
Architecture.
A Three tier architecture separates its tiers from each other based on the complexity of the users
and how they use the data present in the database.
Rules of Three Tier Architecture

It is simply not good enough to split the code for an application into 3 parts and call it "3 Tier" if
the code within each tier does not behave in a certain way. There are rules to be followed, but
these rules are pretty straightforward.
i) The code for each layer must be contained with separate files which can be maintained
separately.
ii) Each layer may only contain code which belongs in that layer. Thus business logic can only
reside in the Business layer, presentation logic in the Presentation layer, and data access logic in
the Data Access layer.
iii) The Presentation layer can only receive requests from, and return responses to, an outside
agent. This is usually a person, but may be another piece of software.
iv) The Presentation layer can only send requests to, and receive responses from, the Business
layer. It cannot have direct access to either the database or the Data Access layer.
v) The Business layer can only receive requests from, and return response to, the Presentation
layer.
vi) The Business layer can only send requests to, and receive responses from, the Data Access
layer. It cannot access the database directly.
vii) The Data Access layer can only receive requests from, and return responses to, the Business
layer. It cannot issue requests to anything other than the DBMS which it supports.
viii) Each layer should be totally unaware of the inner workings of the other layers. The Business
layer, for example, must be database-agnostic and not know or care about the inner workings of
the Data Access object. It must also be presentation-agnostic and not know or care how its data
will be handled. It should not process its data differently based on what the receiving component
will do with that data. The presentation layer may take the data and construct an HTML
document, a PDF document, a CSV file, or process it in some other way, but that should be
totally irrelevant to the Business layer.
Figure 15 Cycle of requests and their associated responses
45
If you look carefully at those layers you should see that each one requires different sets of skills:
i) The Presentation layer requires skills such as HTML, CSS and possibly JavaScript, plus UI
design.
ii) The Business layer requires skills in a programming language so that business rules can be
processed by a computer.
iii) The Data Access layer requires SQL skills in the form of Data Definition Language (DDL)
and Data Manipulation Language (DML), plus database design.
In web application development, three-tier architecture refers to separating the application
process into three specific layers. What the user sees via a web browser is called the presentation
tier and is content served from a web server. The middle tier performs the business logic
processing that occurs, for example, when a user submits a form. The back end consists of the
data tier which handles the database processing and access to the data. We'll take a simplistic
look at each of these.
Figure 16 Three Tier Architecture of ASP.NET
46
Layer: A layer is a reusable portion of code that performs a specific function.

In the .NET environment, a layer is usually set up as a project that represents this specific
function. This specific layer is in charge of working with other layers to perform some specific
goal.
Various layers present in Three Tier Architecture are Data Layer, Business Layer and the
Presentation Layer. These layers can be describes as:
i) Data Layer
A Data Access Layer contains methods that help the Business Layer to connect the data and
perform required actions, whether to return data or to manipulate data (insert, update, delete and
so on).
ii) Business Layer
A Business Access Layer contains business logic, validations or calculations related to the data.
Though a web site could talk to the data access layer directly, it usually goes through another
layer called the Business Layer. The Business Layer is vital in that it validates the input
conditions before calling a method from the data layer. This ensures the data input is correct
before proceeding, and can often ensure that the outputs are correct as well. This validation of
input is called business rules, meaning the rules that the Business Layer uses to make
judgments about the data.
iii) Presentation Layer
The Presentation Layer contains pages like .aspx or Windows Forms are forms where data is
presented to the user or input is taken from the user. The ASP.NET web site or Windows Forms
application (the UI for the project) is called the Presentation Layer. The Presentation Layer is the
most important layer simply because its the one that everyone sees and uses. Even with a well
structured business and data layer, if the Presentation Layer is designed poorly, this gives the
users a poor view of the system.
47
Figure 17 Detailed diagram of Three Tier Architecture
48
Advantages of Three-Tier Architecture

The aim of using the 3-Tier Architecture is not just to make it easier only when you change your
database engine or programming language. It is also useful when you want to either replace your
Presentation layer or create an additional Presentation layer.
The main advantages of the 3 Tier Architecture is often quoted as:
i) Flexibility: By separating the business logic of an application from its presentation logic, the
3-Tier architecture makes the application much more flexible to changes.
ii) Maintainability: Changes to the components in one layer should have no effect on any others
layers. Also, if different layers require different skills (such as HTML/CSS is the presentation
layer, PHP/Java in the business layer, SQL in the data access layer) then these can be managed
by independent teams with skills in those specific areas.
iii) Reusability: Separating the application into multiple layers makes it easier to implement reusable components. A single component in the business layer, for example, may be accessed by
multiple components in the presentation layer or even by several different presentation layers
(such as desktop and the web) at the same time.
iv) Scalability: A 3-Tier architecture allows distribution of application components across
multiple servers thus making the system much more scalable.
v) Reliability: A 3-Tier architecture, if deployed on multiple servers, makes it easier to increase
reliability of a system by implementing multiple levels of redundancy.
Another not-so-obvious benefit which can only come from actual exposure to having developed
multiple applications using the 3-Tier Architecture is that it becomes possible to create a
framework for building new applications around this architecture. As each of the layers
specializes in just one area of the application it is possible to have more reusable components
which deal with each of those areas. Such components can either be pre-built and delivered as
part of the framework, or generated by the framework itself. This reduces the amount of effort
needed to create a new application, and also reduces the amount of effort needed to maintain that
application.
The benefits of alternative Data Access layers

A lot of critics of the 3-Tier Architecture seem to think that the ability to switch from one DBMS
to another is not worth the effort as it rarely happens in real life. While it is true that, once
developed, an application will rarely be switched to a different DBMS, a lot of organizations are
now wishing that they had that ability when they compare the costs of their proprietary databases
with the modern and far cheaper open source equivalents.
Switching to a different DBMS after an application has been built is not the only benefit when
you consider that not everyone works on a single legacy application for a single organization.
There are software houses that develop and maintain a variety of applications for a variety of
customers, so speed of development, cost of development, and providing their customers with
more choices is what differentiates them from the competition and is likely to be a selling point
instead of a rarely-used option. Consider the following:
Suppose you develop an application which you want to sell as a package to lots of different
customers? Do you want to restrict your potential customers to a DBMS of your choice, or one
of their choices? By having all the DBMS logic in its own component in its own layer you can
deliver the same application code to everybody and let them decide on what DBMS to use at
installation time.
49
Suppose that, instead of developing actual end-user applications, you develop a framework for
building end-user applications? Do you want to restrict the potential users of this framework to a
DBMS of your choice, or one of their choice?
By giving your customers the ability to easily switch from one DBMS to another without
enormous expense and effort you will be pleasing your customers and displeasing your
competitors.
The ability to switch from one DBMS to another does not, or should not, restrict you to just one
DBMS at a time. If each component in the Business layer is responsible for creating and
communicating with a component in the Data Access layer it should be possible to allow more
than one component to exist at the same time, as shown in the figure below.
Figure 18 Using multiple objects in the Data Access layer
Here you can see that instead of just "alternative" components in the Data Access layer you
actually have the option of "additional" components. This will allow, for example, part of your
application to access a MySQL database while another part accesses a PostgreSQL/Oracle/SQL
Server database.
50
The benefits of alternative Presentation layers

A lot of critics of the 3-Tier Architecture seem to think that the ability to switch from one
Presentation layer to another is something else which has very little value in the real world, but
yet again they are being narrow-minded and blinkered in their viewpoint. I first encountered the
3-Tier Architecture when using a compiled language which produced applications for the
desktop. As soon as the internet revolution got into full swing and more and more organizations
wanted a web site, the authors of this language added in the ability to generate a new
presentation layer based around the HTTP protocol and HTML forms. This new Presentation
layer still accessed the existing Business and Data Access layers, so it did not involve a full
application rewrite, just the development of a new set of components for the Presentation layer.
This new layer was not instead of the old layer, it was in addition to the old layer, which made it
possible for the original desktop application to be used by the in-house staff while internet
visitors used the new HTML layer. Developers who used this language liked the idea that they
could build a web interface into their existing application and make use of existing components
instead of having to rewrite the whole application from scratch.
The ability to switch from one Presentation layer to another does not, or should not, restrict you
to just one Presentation layer at a time. Each Presentation layer has its own set of components
and is activated in a different way by a different set of users, but they all then communicate with
the same set of components in the Business and Data Access layers. It should then be possible to
allow more than one Presentation layer to be used at the same time. Thus instead of just an
"alternative" Presentation layer you actually have the option of "additional" Presentation layers.
This will allow one set of users to access the application through one Presentation layer while
other sets of users access it through different Presentation layers which have been tailored just
for them.
This choice between two Presentation layers, one for in-house staff and another for internet
visitors has been extended in recent years to cover additional sets of users. I have personally
worked on several e-commerce applications which, as well as a Business-to-Consumer (B2C)
site they also have a Business-to-Business (B2B) site - sometimes known as a Supplier Portal and increasingly an additional site for dealing with web services. I have also helped an
organization go multi-national with copies of their UK website ported to different servers in
different languages, all being served from the same back-end application and database. This then
produces an application which has several Presentation layers or "windows", as shown in the
figure below.
51
Figure 19 A typical application with multiple "windows"
Just suppose each of these "windows" was treated as a separate application instead of a small
part of a much larger application? None of these applications would share any component in any
of the other applications, which would result in a duplication of effort. Even though each of these
"windows" would have its own presentation logic, it would also have its own business logic and
data access logic. This would result in the situation shown in the figure below.
Figure 20 Each "window" has its own layers
52
If you wanted each of these "windows" to enforce the same business rules you would have to
maintain the program code in each of the different business layers, which would be a costly
duplication of effort as well as a potential problem area should the code in one "window" not be
kept in sync with the others.
Just suppose the first (or primary) application had been developed using the 3-Tier Architecture
with its reusable Business layer and Data Access layer components? All the additional (or
secondary) "windows" would be much smaller as they would not require their own set of
business and data access logic, they would be able to share the logic which was written for the
first application. This arrangement is shown in the figure below.
Figure 21 Multiple Presentation layers sharing a single Business layer and Data Access layer
Here you can see that only one application - the back end management application - has all three
layers of code while all the other applications are nothing more than simple "windows" which
consist of a separate presentation layer which connects to the shared business layer (and through
that the shared data access layer).
As the code to enforce the business rules is maintained in a single place then you also eliminate
the problem of synchronizing those rules in multiple places. You can make a change to a single
component in the Business layer and have that change immediately picked up (or "inherited"
using the parlance of Objected Oriented programmers) by all the various "windows".
As each of these additional "windows" is able to reuse a significant amount of existing code, the
observant among you will immediately notice that this should also make them quicker, easier
and cheaper to develop. How much cheaper depends on how you build your front ends. For
example, if you are a follower of the Model-View-Controller design pattern you should see that
the existing Business layer already provides the Model, so you have nothing to design and
develop for each front end except the Controller and the View. The skills required here are little
more than HTML, CSS and JavaScript, while the heavy lifting - the database design, the
processing of business rules and the generation of complex SQL queries - can be left to the big
boys in the back office.
53
CHAPTER 6:
SYSTEM MAINTENANCE
54
6.1. Software Maintenance

Software maintenance is a set of software engineering activities that occur after software has
been delivered for the customer and put into operation. The success of the software and the
project relies on the maintenance procedure adopted. As with the venture of human, not a single
one is perfect. The further modifications are left to the followers. Its because the opinion or
vision or a thing differs from individual to individual. The maintenance is performed at regular
intervals to keep the project safe and reliable.
Development is a single activity maintenance is a continuous activity. Maintenance involves
activities like inspections, corrections and enhancements. Once the system is delivered and
deployed, it enters the maintenance phase. The system need to be maintained not because pf
some of its components wear out and need to be replaced, but because there are some residual
errors remaining in the system that must be removed as they are discovered. This includes
activities related to debugging the software after it goes live,, changes required to address
evolving software and enhancement to meet changing customer requirements. So maintenance
phase involves:
i) Understanding the effects of change.
ii) Testing the new parts
iii) Retesting the old parts that were not changed
iv) Making changes to both the code and the documents.
These changes have to be designed by the user before the change can be carried out. Since
requirement change request involves cost, user will be cautious while requesting the software
changes. The software will require continued support. The system maintenance means the
maintenance activities after and during the system development processes. This include activities
related to debugging the software after it goes live, changes acquired to meet changes in user
requirement.
Maintenance phase identifies if there are any changes required in the current system. If the
changes are identified, then an analysis is made to identify if the changes are really required.
Cost benefit analysis is away to find out if the change is really essential.
55
6.2. SYSTEM SECURITY

Security is a critical stage in system development. Even candidate system must provide built-in
features for security and integrity of data. Without safe guards against unauthorized access,
fraud, embezzlement, fire and natural disaster, a system could be so vulnerable as to threaten the
survival of the organizations.
To do an adequate job on security, the risk, exposure, cost and specific measures such as
password should be analyzed to provide protection. In addition, back up of copies of software
and recovery restart procedures must be available when needed.
The amount of protection depends on the sensitivity of data, the reliability of the user and the
complexity of the system. The motive behind security is to keep the organization running, protect
data as an asset and seek management support for more installations.
6.2.1. THREATS TO SYSTEM SECURITY

The lists of potential threats are:
i) Errors and Omissions
ii) Disgruntled and Dishonest Employees
iii) Fire
iv) Natural Disaster
v) External Attacks
6.2.2. SYSTEM SECURITY MEASURES

After system security risk has been evaluated, the next step is to select security measures. The
measures are:
i) Identification
ii) Access Control
iii) Audit Control
iv) System Integrity
IDENTIFICATION
It is the scheme of identifying person to the system based on Something you know such as a
password or a picture badge, Something you are such as finger print or voice print or
Something you have such as credit card, key or special terminal.
ACCESS CONTROL
Controlling the access to the computer facility is secured through encoded cards or similar
devices. Encryption prevents intruders from accessing data by scrambling messages across
telephones to the destination.
AUDIT CONTROL
Auditing must be supported at all levels of management. Audit control protects a system from
external security breaches and internal fraud or embezzlement. Various software programs are
available to help in audit function.
SYSTEM INTEGRITY
This line of different safeguards the functioning of hardware, software and physical security and
operating procedure. Proper back of hardware and software are extremely important.
56
6.3. SYSTEM TESTING

System testing is done when the entire system has been fully integrated. The purpose of the
system testing is to test how the different modules interact with each other and whether the
system provides the functionality that was expected.
Software testing is an investigation conducted to provide stakeholders with information about
the quality of the product or service under test. Software testing also provides an objective,
independent view of the software to allow the business to appreciate and understand the risks of
software implementation. Test techniques include, but are not limited to, the process of executing
a program or application with the intent of finding software bugs (errors or other defects).
Software testing can also be stated as the process of validating and verifying that a software
program/application/product: meets the business and technical requirements that guided its
design and development; works as expected; and can be implemented with the same
characteristics.
Testing is the process of executing a program with the intention of finding any error. A good test
of course has the high probability of finding a yet undiscovered error. A successful test is the one
that uncovers a yet undiscovered error.
A test is vital to the success of any system. System test makes a logical assumption that if all
parts of the system are correct, then goal will be successfully achieved. The candidate system is
subjected to a variety of tests online like responsiveness, its value, stress and security. A series of
tests are performed before the system is ready for user acceptance testing.
Testing is the process of evaluating a system or its component(s) with the intent to find whether
it satisfies the specified requirements or not. In simple words, testing is executing a system in
order to identify any gaps, errors, or missing requirements in contrary to the actual requirements
.According to ANSI/IEEE 1059 standard, Testing can be defined as - A process of analyzing a
software item to detect the differences between existing and required conditions (that is
defects/errors/bugs) and to evaluate the features of the software item.
6.3.1. Testing Stakeholders

It depends on the process and the associated stakeholders of the project(s). In the IT industry,
large companies have a team with responsibilities to evaluate the developed software in context
of the given requirements. Moreover, developers also conduct testing which is called Unit
Testing.
In most cases, the following professionals are involved in testing a system within their respective
capacities:
i) Software Tester
ii) Software Developer
iii) Project Lead/Manager
iv) End User
57
6.4. TESTING STRATEGIES ADOPTED

Testing should be done through the implementation process. Even before and application is
installed; it makes sense to verify that the basic platform is capable of achieving its design
capabilities. System testing is a critical process. Testing is a process of executing a program with
the explicit intention of finding errors that is making the program fail. This helps in finding the
bottle neck in the system. Executing a program in a stimulated environment performs testing.
The feedback from testing phase generally produces changes in the software to deal with errors
and failures that are uncovered.
6.4.1. UNIT/COMPONENT TESTING

Here we test each module individually and integrate the overall system. Unit testing focuses
verification effort even in the smallest unit of software development in each module. This is also
known as module testing. The modules of the system are tested separately. This testing is carried
out in the programming style itself. In this testing, each module is focused to work satisfactorily
as regard to expect output from the module.
6.4.2. BLACK BOX TESTING

This is a software testing approach in which the tester doesnt know the internal working of the
item being tested. For example in a Black box test, on software design the tester only knows the
input and the expected outputs. He doesnt know how the program derives the output. He doesnt
even imagine as to how, the coding is done. He need know only the specifications.
Test cases are decided on the basis of requirements or specifications of the program or module.
Black box testing is done in the project to remove the following types of errors:
i) Incorrect or missing function
ii) Interface errors.
iii) Errors in data structure or external database access.
iv) Behavioral or performance error.
v) Errors in initiation and termination.
6.4.3. WHITE BOX TESTING

The White box testing or structural testing performs close operation of procedural details. They
test the software logical path by having test cases exercising specific sets of condition and loops.
White box testing is done in the project to remove the following types of errors:
i) All modules path have been exercised at least once.
ii) Exercised on logical decisions.
iii) Executed all loops at their boundaries and within their operational bounds.
iv) Exercised internal data structure to ensure their validity.
6.4.4. INTEGRATION TESTING

This testing is done to tackle problems of interface that is putting all interfaces together. When
the separate modules are put together in an integrated manner, this testing is performed. This
testing is systematic technique. This testing is performed to check the data should not be lost
across an interface. The objective is to take an unit tested module and build a program structure
that has been dedicated by design.
Data can be lost across on an interface, one module have an adverse effect on the other subfunctions, when combined may not produce the desired functions. Integrated testing is the
systematic testing to uncover the error within the interface. The testing is done with simple data
58
and the developed system can run successfully with this simple data. Here the major intention is
to find the overall system performance.
6.4.5. VALIDATION TESTING

Verification and validation testing are two important tests which are carried out on a software
before it has been handed over to the customer. The aim of both verification and validation is to
ensure that the product is made according to the requirements of the client, and does indeed
fulfill the intended purpose. While verification is a quality control process, the quality assurance
process carried out before the software is ready for release is known as validation testing. Its goal
is to validate and be confident about the product or system, and that it fulfills the requirements
given by the customer. The acceptance of the software from the end customer is also its part.
At the culmination of Black box testing the software is completely assembled as a whole
package. Interfacing error has been uncovered and corrected and the final series of tests that is
validation begins. The validation test can be defined by the following simple definition that
validation succeeds when the software functions in a manner that can be reasonably accepted by
customer.
6.4.6. OUTPUT TESTING

After performing validation testing the next step is the output testing. The system cannot be
useful if it does not produce the required output. Asking the user about the format in which the
system is required, test the output that is displayed or generated by the system under
consideration. Here the output format is considered in two way. One is on screen format and the
other is the printed format. The output format on the screen is found to be correct as the format
was designed in the system phase according to user names. As for hard copy, the output comes
according to the specification requested by the user. Here the output testing doesnt result in any
correction in the system.
6.4.7. USER ACCEPTANCE TESTING

User acceptance testing of the system is the key factor of the success of any system. The system
under consideration is tested for user acceptance by constantly keeping in touch with the
prospective system at the time of development and making change whenever required. This is
done with regard to input-output screen designs.
6.4.8. REGRESSION TESTING

Regression was done to ensure proper working of each module with the whole system. Each
module is embedded in the system and the whole tested for integrity.
Regression testing is a black box testing technique that consists of re-executing those tests that
are impacted by the code changes. These tests should be executed as often as possible throughout
the software development life cycle.
59
60

TNPProjectReport (APril 19)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TNPProjectReport (APril 19)

Uploaded by

Copyright:

Available Formats

A Report on

TRAINING AND PLACEMENT PORTAL

INDERPRASTHA ENGINEERING COLLEGE, GHAZIABAD

Mentor: Dr. Pooja Tripathi

Date: April 11,2015

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

Name: Himanshi Goel

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

CHAPTER 3: SYSTEM DESIGN

CHAPTER 7: SNAPSHOTS AND RESULT

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

1.1 Product Information

EXISTING SYSTEM AND ITS DRAWBACKS

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

BOTTLENECKS OF PRESENT WORKING SYSTEM

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

1.1.2 Product Features

1.1.3. Performance Requirements:

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

1.2 Requirement Analysis

1.2.1. Functional Requirements

1.2.2. Non Functional Requirements

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

1.3. Feasibility Study

1.3.1. Technical Feasibility

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

1.3.2. Economical Feasibility

1.3.3. Scheduled Feasibility

1.3.4. Operational Feasibility

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

2.1.2. Problem Statement

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

2.1.3. Project Objective

2.1.4. Project Scope

2.1.5. Operating Environment

Operating System : Windows XP Prof. or above.

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

vii) Integration and Test Phase

2.1.7. Design & Implementation Constraints

User friendliness is provided in the application with various controls.

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

2.2. Software Development Life Cycle

Figure 1 Graphical representation of the various stages of a typical SDLC

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

2.2.2. Stages of Software Development Life Cycle

Stage 1: Planning and Requirement Analysis

Stage 2: Defining Requirements

Stage 3: Designing the product architecture

Stage 4: Building or Developing the Product

Stage 5: Testing the Product

TRAINING AND PLACEMENT PORTAL PROJECT REPORT, IPEC, GHAZIABAD

Stage 6: Deployment in the Market and Maintenance

2.2.3. Software Development Life Cycle Models