SAMAGRA PORTAL

INTRODUCTION

SSSM (Samagra Social Security Mission) Powered by Madhya Pradesh Government plans to
make easy and simple access to the Madhya Pradesh state government and central government
schemes. Established in the year 2010 by Madhya Pradesh state government. It is an interdepartmental and government-wide exercise, which is a partnership of all departments.

PROJECT OUTLINE
A.TITLE OF THE PROJECT:- SAMAGRA PORTAL

B.OBJECTIVE OF THE PROJECT:This project has been designed for the department. This
simple to use and to manage. All the basic requirements of a
department have been fulfilled successfully.
C. LEAST HARDWARE SPECIFICATION:System
Ram
CD Drive
Key Board
Monitor
Operating System

: PIV
: 500 MB
: Any One
: Any (101,104,106)
: 14/15 Color Monitor
: Windows (XP)

D.SOFTWARES USED:DEVELOPMENT TOOLS

DATABASE

: ASP.NET
: SQL

ABOUT THE PROJECT :This project is maintain the information about Samagra Portal for adding,
Deleting and Modify Detail.
This project provides many facility. Its also provides the facility for
maintain information about portal.

TESTING AND SDLC

System Development Model
Software development has hit something of a crisis we fail to deliver
software that meets user expectation. However by employing disciplined
techniques throughout the development of software and by employing a
philosophy of co-ordination control and management through out the
development lifecycle of software project standard may be achieved.
The aim is to provide discipline to the development of software a
structured framework against which development takes place is
advocated.
A model of the process of system development is used by organization
to describe their approach to producing computer system. Traditionally
this has been a staged (or phased) approach; know as the system life
cycle or system development life cycle (SDLC).

Purpose for SDLC

This SDLC methodology establishes
procedures, practices, and
guidelines governing the initiation, concept development, planning
requirements analysis, design, development , integration and text,
implementation, and operations, maintenance and disposition of
information system .it should be used in conjunction with existing
policy and guidelines for acquisition and procurement ,as these
areas are not discussed in the SDLC.

Scope
This methodology should be used for all DOJ information system and
applications .it is applicable across all information technology (IT)
environments (e.g. mainframe, client and server) and applies to
contractually developed as well as in-house development application.
These specific participants in the life cycle process. And the necessary
and approvals vary from project to project. The guidance provided in
5

this document should be tailored to the individual project based on

cost, complexity and criticality to the agencys mission.

Applicability
This methodology must be applied to those who are responsible for
information system development. All project managers and development
teams involved in system development project represent the primary
audience for the SDLC.

INTRODUCTION TO SDLC
The SDLC includes ten phases during which defined IR work products
are created or modified. The tenth phase occurs when the system is
disposed of and the task performed is eliminated or transferred to other
system. The tasks and work products.
For each phase are described in subsequent chapter. Not every project
required that the phase be sequentially executed. However the phased
are interdependent. Depending upon the size and complexity of the
project, phase may be combined or may overlap.

PHASE OF SDLC
Initiation phases
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.

System concept Development phase

One a business need is approved, the approaches for accomplishing the
concept is reviewed for feasibility and approp4iatenss. The system
boundary document identifies the scope of the system and requires
senior official approval and funding before beginning the planning
phase.

Planning phase
The concept further developed to describe how the business will operate
once the approved system is implemented, and to assess how to 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
completion of high level vulnerability assessment.

Requirements Analysis phase

Functional user requirements are formally defined and delineate the
requirement in terms of data, system performance, security, and
maintainability requirement for the system. All requirements are defined
to a level of detail sufficient for system design to proceed. All
requirement need to be measurable and testable and relate to the
business need or opportunity identified in the initiations phase.

Design phase
The physical characteristic of the system are designed during this phase.
The operating environment is established, major subsystems and input
and the output are defined, and processes are allocated to resources.
Every thing requiring user input or approval must be documented and
reviewed by the user. The physical characteristics of the system are
specified and detailed design is prepared. Subsystem identified during
design is 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.

Development phase
The detailed specification produced during the design phase is translated
hardware, communication, and executable software shall be unit tested,
integration, and rested in a systematic manner. Hardware is assembled
and tasted.
7

Integration and test phase

The various computer of the system are integrated and systematically
tested. The user tested the system to ensure that the functional
requirement, as defined in the functional requirement document, is
satisfied by the developed or modified system. Prior to installing and
operating the system in a production environment, the system must be
undergoing certification and accreditation activity.

Implementation phase
The system or system modification 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 continue until the
system is operating in production in accordance with the defined user
requirements.

Operations and Maintenance Phase

The system operation is ongoing. The system is monitored for continued
performance in accordance with requirement, and needed system
modification is incorporated. The operational system is periodically
assessed through in-process reviews to determine how the system can
be made more efficient and efficient. Operations continue as long as the
system can be effectively adapted to respond to an organization needs.
When modifications or change are identified as necessary, the system
may reenter the planning phase.

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

Classical Waterfall
The lifecycle approach is derived the waterfall model of the system
development described by Royce in 1970, a simplified version of which
is given below.
Requirements
Analysis

Functional
Specification

Design

Implementation
(Coding)

Testing

Classic system Development Life Cycle-version 1

There are now many variations on the theme of the waterfall model,
Alternatives
Feasibility
Analysis
Design
Implement
Test
9

Maintain

Feasibility Study:
Is the project technically, operationally, financially and legally feasible?
The feasibility is used to determine if the project should get the goahead. If the project is preceding the feasibility study will produce a
project plane and budget estimates for the future stage of development.

Analysis:
Gather the requirements for the system. This stage includes details a
detailed study of the business needs of the organization. Option for
changing the business process may be considered.

Design:
This focuses on high level design (What programs are we going to need
how are they going to interact), low level design (how the individual
programs are going to work), interface design (what are the interfaces
going to look like) and data design (what data are going to need).

Implementation:
The design is translated into code. Computer programs may be written
using a conventional programming language to a fourth generation
language (4GL) or an application generator.

Test:
The system is tested. Normally programs are written are as a series of
individual modules-these should be subject to separate and detailed test.
The system is then tested a whole- the separate modules are brought
together and tested as complete system. the system need to be ensure
that interfaces between modules work(integration testing), the system
10

work on the intended platform and with the expected volume of data
(volume testing) and the system does what the user
requires(acceptance/beta testing).

Maintenance:
Inevitably the system will need maintenance-hopefully we havent got
anything wrong but people will want extra things added or existing
things changed over time.
This paradigm is the oldest and the most widely used approach to
system development, it was developed by Royce in 1970.
Waterfall Approach Characteristics although there are many variations
on the theme of the lifecycle, each approach has its own characteristics:
1. Specific activities , techniques and outcomes are associated with
each stage;
2. progression between stages is orderly and proceeds in a liner
fashion;
3. viewed to be a process driven by technicians;
4. monitoring and control takes place at the end of stage;
5. Involvement of end users is typically passive and principally in the
analysis stage.
The lifecycle model assumes that system will be constructed from
scratch by a team of IS professionals either in-house of within a
software house.
Other approaches exist, namely:
1.
Those based on alternative lifecycle e.g. prototyping , evolution
ary development, spiral model;
2.
Those which have a different philosophical basis e.g. soft sys
tem and sociotechnical approaches;
3. The use of package software to address application areas;
4. The development of application by end users.

11

A number of these alternative approaches will be examined later in the

course. However, our initial focus will be on the on the waterfall model
of the system development.
Problem with the waterfall approach
1. Real projects rarely follow the sequential process illustratedinteraction though the cycle is required.
2. It is often difficult for the customer to state all requirements explicitly
at the state of the development lifecycle (the reasons for problems when
capturing requirements has/will be covered).
With this approach, the customer must be patient- a working version is
not usually available until late in the development lifecycle.

12

Testing Techniques
The time dependent, asynchronous nature of many
real-time applications adds a new and potential difficult element to the mixtime. Not only does the test case designer have to consider white-box test
cases but also event handing, the timing of the data, and the parallelism of the
tasks (Process) that handle the data.
Comprehensive test case design methods for real-time system have
yet to evolve. However an overall four-step strategy can be proposed:
Task Testing
Behavioral Testing
Inter Task Testing
System Testing
Task Testing:The first step in the testing of real-time software is to test each
task independently. That is, white-box and black-box tests are designed and
executed for each task. Each task is executed independently during these
13

tests; Task testing uncovers error in logic and function but not timing or
behavior.

Behavioral Testing:Using system models created with CASE tools, it is

possible to simulate the behavior of a real-time system and examine its
behavior as a consequence of external events. These analysis activities can
serve as the basic for the design of test cases that are conducted when the
real-time software has been built. Using a technique that is similar to
equivalent partitioning, events are categorized for testing. For example,
events for the photocopier might be user interrupts mechanical interrupts,
system interrupt, and failure mode. Each of these events tested individually
and the behavior of the executable system is examined to detect errors that
occur as a consequence of processing associated with these events. The
behavior of system model and the executable software can be compared for
performance.
Inter Task Testing:Once errors in individual tasks and in system behavior have been
isolated, testing shifts to time-related errors. Asynchronous tasks that are
known to communicate with one another are tested with different data rates
and processing load to determine if inters task synchronization errors will
14

occur. Task that communicate via a message queue or data store are tested to
uncover errors in the sizing of these data storage areas.

System Testing:Software and hardware are integrated and full ranges of

system test are conducted in an attempt to uncover errors at the
software/hardware interface. Most real-time systems process interrupts. The
tester develops a list of all possible interrupts and the processing that occurs
as a con sequence of the interrupts. Tests are then designed to asses the
following system characteristics:
Are interrupts priorities properly assigned and properly handled?
Is processing for each interrupts handle correctly?
White Box Testing:It is also called glass box testing. It is a test
case design to derive test cases. In this, all statement in the program has been
executed at least once during testing that all logical condition has been
exercised. Using white box testing methods, the software engineer can derive
test cases that
Guarantee that all independent paths within a module have been exercised at
least once.
Exercise all loops at their boundaries and within their operational bounds.
Exercise internal data structure to assure their validity.

15

Basic path testing, a white-box technique, makes use of program

graphs to drive the set of linearly independent tests that will ensure
coverage. Condition and data floe testing further exercise program logic,
and loop testing complements other white-box technique by providing a
procedure for exercising loops of varying degrees of complexity.

16

Black Box Testing:Knowing the specified function that a product has

been design to perform, tests can be conducted that demonstrate each
function is fully operational while at the same time searching for errors in
each function black box testing alludes to test that are conducted at the
software interface. A black box test examines some fundamental aspect of a
system with little regard for he internal logical structure of software.
Function Testing: - In system design may have so may function. Each
program has defined into number of function has its own task. We can test
each function to perform an accurate result. We must debug the function.
Function is block of code that performs a particular task, and returns a
particular value.
Structural Testing: - Each program has a structure, and contains the function,
variable, control statement decision making loops header files, we can test
program structure these are define properly in our program. So the
programmer set structure of program.

17

Combining Structure and Function Testing: After Testing in our program function makes the setup
the program so that each function is run the program so that each
function is fun according to define the structure. Program may have
several structural and function. Programmer can arrange these method
and structure they are properly perform our task, if they are not done
sets the structures,

18

CONCLUSION

samagra portal is a different experience and you can make the portal
creative over the internet as you get used to it. There can be lot of
apprehensions about samagra portal when you get in to it for the first time.
As you experience more and more of it those apprehensions get dissapeared
slowly. Remember that if you stick to the basics, samagra portal become
more easier than manual .

19

The system is highly flexible one and is well efficient to make easy
interactions with the client .the key focus is given on data security, as the
object id online and will be maintained in a proper way.
This will be a user-friendly one and can successfully overcome strict and
severe validation checks. The system will be a flexible one and changes
whenever can be made easy .using the facility and flexibility in .NET and
SQL, the s\w can be developed in a neat and simple manner there by
reducing the operations work .since the project is developed in .NET as a
front-end and SQL as a back-end it can be modified easily and used for a
long period

20

1. The Complete Reference

Matthew MacDonald

2. ASP.NET&C#

Prapher books

3. ASP.NET 2.0

Dreamlech

4. BEGINING IN 21 DAYS

john Kauffman

21