samagra portal.doc

8/19/2019 Samagra Portal.doc

1/21

SAMAGRA PORTAL

1


2/21

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 !1! by Madhya Pradesh state government. "t is an inter#

departmental and government#wide e$ercise% which is a partnership o& all departments.


3/21

PROJECT OUTLINE

A.TITLE OF THE PROJECT'# SAMAGRA PORTAL

B.OBJECTIVE OF THE PROJECT'#

his proect has been designed &or the department. his

simple to use and to manage. *ll the basic re+uirements o& a

department have been &ul&illed success&ully.

C. LEAST HARDWARE SPECIFICATION:-

System ' P",

-am ' !! M/

0 rive ' *ny 2ne

3ey /oard ' *ny (1!1%1!4%1!5)

Monitor ' 14667166 0olor Monitor

2perating System ' 8indows (9P)

D.SOFTWARES USED:-

E,E:2PME; 22:S ' ASP.NET

**/*SE ' SQL


4/21

ABOUT THE PROJECT :-

his proect is maintain the in&ormation about Samagra Portal &or adding%

eleting and Modi&y etail.

his proect provides many &acility. "t6s also provides the &acility &or

maintain in&ormation about portal.

4


5/21

TESTING AND SDLC

System Dee!"#me$t M"%e!

So&tware development has hit something o& a crisis we &ail to deliver so&tware that meets user e$pectation. =owever by employing disciplined

techni+ues throughout the development o& so&tware and by employing a

philosophy o& co#ordination control and management through out the

development li&ecycle o& so&tware proect standard may be achieved.

he aim is to provide discipline to the development o& so&tware a

structured &ramework against which development takes place is

advocated.

* model o& the process o& system development is used by organi>ation

to describe their approach to producing computer system. raditionally

this has been a staged (or phased) approach? know as the system li&e

cycle or system development li&e cycle (S:0).

P&'#"se ("' SDLChis S:0 methodology establishes procedures% practices% and

guidelines governing the initiation% concept development% planningre+uirements analysis% design% development % integration and te$t%

implementation% and operations% maintenance and disposition o&

in&ormation system .it should be used in conunction with e$isting

policy and guidelines &or ac+uisition and procurement %as these

areas are not discussed in the S:0.

S)"#e

his methodology should be used &or all 2@ in&ormation system andapplications .it is applicable across all in&ormation technology (")

environments (e.g. main&rame% client and server) and applies to

contractually developed as well as in#house development application.

hese speci&ic participants in the li&e cycle process. *nd the necessary

and approvals vary &rom proect to proect. he guidance provided in


6/21

this document should be tailored to the individual proect based on

cost% comple$ity and criticality to the agency6s mission.

A##!*)+,*!*tyhis methodology must be applied to those who are responsible &or

in&ormation system development. *ll proect managers and developmentteams involved in system development proect represent the primary

audience &or the S:0.

INTRODUCTION TO SDLChe S:0 includes ten phases during which de&ined "- work products

are created or modi&ied. he tenth phase occurs when the system is

disposed o& and the task per&ormed is eliminated or trans&erred to other

system. he tasks and work products.Aor each phase are described in subse+uent chapter. ;ot every proect

re+uired that the phase be se+uentially e$ecuted. =owever the phased

are interdependent. epending upon the si>e and comple$ity o& the

proect% phase may be combined or may overlap.

PHASE OF SDLC

I$*t*+t*"$ #+seshe initiation o& a system (or proect) begins when a business need or

opportunity is identi&ied. * proect manager should be appointed to

manage the proect. his business need is documented in a concept

proposal. *&ter the concept proposal is approved% the system concept

development phase begins.

System concept Development phase2ne a business need is approved% the approaches &or accomplishing the

concept is reviewed &or &easibility and approp4iatenss. he system boundary document identi&ies the scope o& the system and re+uires

senior o&&icial approval and &unding be&ore beginning the planning

phase.

5


7/21

P!+$$*$ #+sehe concept &urther 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. o ensure the products

and 7or services provide the re+uired capability on#time and within budget% proect resources. *ctivities% schedules tools and reviews are

de&ined. *dditionally% security certi&ication and accreditation activities

begin with the identi&ication o& system security re+uirements and

completion o& high level vulnerability assessment.

Re/&*'eme$ts A$+!ys*s #+seAunctional user re+uirements are &ormally de&ined and delineate the

re+uirement in terms o& data% system per&ormance% security% and

maintainability re+uirement &or the system. *ll re+uirements are de&inedto a level o& detail su&&icient &or system design to proceed. *ll

re+uirement need to be measurable and testable and relate to the

business need or opportunity identi&ied in the initiations phase.

Des*$ #+sehe physical characteristic o& the system are designed during this phase.

he operating environment is established% maor subsystems and input

and the output are de&ined% and processes are allocated to resources.Every thing re+uiring user input or approval must be documented and

reviewed by the user. he physical characteristics o& the system are

speci&ied and detailed design is prepared. Subsystem identi&ied during

design is used to create a detailed structure o& the system. Each

subsystem is partitioned into one or more design units or modules.

etailed logic speci&ications are prepared &or each so&tware module.

Dee!"#me$t #+sehe detailed speci&ication produced during the design phase is translated

hardware% communication% and e$ecutable so&tware shall be unit tested%

integration% and rested in a systematic manner. =ardware is assembled

and tasted.

B


8/21

I$te'+t*"$ +$% test #+sehe various computer o& the system are integrated and systematically

tested. he user tested the system to ensure that the &unctional

re+uirement% as de&ined in the &unctional re+uirement document% is

satis&ied by the developed or modi&ied system. Prior to installing and

operating the system in a production environment% the system must be

undergoing certi&ication and accreditation activity.

Im#!eme$t+t*"$ #+sehe system or system modi&ication are installed and made operational in

a production environment. he phase is initiated a&ter the system has

been tested and accepted by the user. his phase continue until the

system is operating in production in accordance with the de&ined user

re+uirements.

O#e'+t*"$s +$% M+*$te$+$)e P+sehe system operation is ongoing. he system is monitored &or continued

per&ormance in accordance with re+uirement% and needed system

modi&ication is incorporated. he operational system is periodically

assessed through in#process reviews to determine how the system can

be made more e&&icient and e&&icient. 2perations continue as long as the

system can be e&&ectively adapted to respond to an organi>ation needs.

8hen modi&ications or change are identi&ied as necessary% the system

may reenter the planning phase.

D*s#"s*t*"$ P+sehe disposition activities ensure the orderly termination o& the system

and preserve the vital in&ormation about the system so that some or all o& the in&ormation may be reactivated in the &uture i& necessary. Particular

emphasis is given to proper preservation o& the data processed by the

system%

C


9/21

Implementation

(Coding)

So that the data is e&&ectively migrated to another system or archived in

accordance with applicable records management regulations and

policies% &or potential &uture access

C!+ss*)+! W+te'(+!!he li&ecycle approach is derived the water&all model o& the systemdevelopment described by -oyce in 1DB!% a simpli&ied version o& which

is given below.

0lassic system evelopment :i&e 0ycle#version 1

here are now many variations on the theme o& the water&all model%

*lternatives

D

Requirements

Analysis

Functional

Specification

Design

Testing

Feasiility

Analysis

Design

Implement

Test

!aintain


10/21

Fe+s*,*!*ty St&%y:"s the proect technically% operationally% &inancially and legally &easible

he &easibility is used to determine i& the proect should get the go#

ahead. "& the proect is preceding the &easibility study will produce a

proect plane and budget estimates &or the &uture stage o& development.

A$+!ys*s:

Gather the re+uirements &or the system. his stage includes details adetailed study o& the business needs o& the organi>ation. 2ption &or

changing the business process may be considered.

Des*$:his &ocuses on high level design (8hat programs are we going to need

how are they going to interact)% low level design (how the individual

programs are going to work)% inter&ace design (what are the inter&aces

going to look like) and data design (what data are going to need).

Im#!eme$t+t*"$:he design is translated into code. 0omputer programs may be written

using a conventional programming language to a &ourth generation

language (4G:) or an application generator.

Test:he system is tested. ;ormally programs are written are as a series o&

individual modules#these should be subect to separate and detailed test.

he system is then tested a whole# the separate modules are brought

together and tested as complete system. the system need to be ensure

that inter&aces between modules work(integration testing)% the system

1!


11/21

work on the intended plat&orm and with the e$pected volume o& data

(volume testing) and the system does what the user

re+uires(acceptance7beta testing).

M+*$te$+$)e:"nevitably the system will need maintenance#hope&ully we haven6t got

anything wrong but people will want e$tra things added or e$isting

things changed over time.

his paradigm is the oldest and the most widely used approach to

system development% it was developed by -oyce in 1DB!.

8ater&all *pproach 0haracteristics although there are many variations

on the theme o& the li&ecycle% each approach has its own characteristics'1. Speci&ic activities % techni+ues and outcomes are associated with

each stage?

. progression between stages is orderly and proceeds in a liner

&ashion?


12/21

* number o& these alternative approaches will be e$amined later in the

course. =owever% our initial &ocus will be on the on the water&all model

o& the system development.

Problem with the water&all approach1. -eal proects rarely &ollow the se+uential process illustrated#

interaction though the cycle is re+uired.

. "t is o&ten di&&icult &or the customer to state all re+uirements e$plicitly

at the state o& the development li&ecycle (the reasons &or problems when

capturing re+uirements has7will be covered).

8ith this approach% the customer must be patient# a working version is

not usually available until late in the development li&ecycle.

1


13/21

Test*$ Te)$*/&es

he time dependent% asynchronous nature o& many

real#time applications adds a new and potential di&&icult element to the mi$#

time. ;ot only does the test case designer have to consider white#bo$ test

cases but also event handing% the timing o& the data% and the parallelism o& the

tasks (Process) that handle the data.

0omprehensive test case design methods &or real#time system have

yet to evolve. =owever an overall &our#step strategy can be proposed'

ask esting

/ehavioral esting

"nter ask esting

System esting

T+s0 Test*$:-

he &irst step in the testing o& real#time so&tware is to test each

task independently. hat is% white#bo$ and black#bo$ tests are designed and

e$ecuted &or each task. Each task is e$ecuted independently during these

1


14/21

tests? ask testing uncovers error in logic and &unction but not timing or

behavior.

Be+*"'+! Test*$:-

Fsing system models created with 0*SE tools% it is

possible to simulate the behavior o& a real#time system and e$amine its behavior as a conse+uence o& e$ternal events. hese analysis activities can

serve as the basic &or the design o& test cases that are conducted when the

real#time so&tware has been built. Fsing a techni+ue that is similar to

e+uivalent partitioning% events are categori>ed &or testing. Aor e$ample%

events &or the photocopier might be user interrupts mechanical interrupts%

system interrupt% and &ailure mode. Each o& these events tested individuallyand the behavior o& the e$ecutable system is e$amined to detect errors that

occur as a conse+uence o& processing associated with these events. he

behavior o& system model and the e$ecutable so&tware can be compared &or

per&ormance.

I$te' T+s0 Test*$:-

2nce errors in individual tasks and in system behavior have been

isolated% testing shi&ts to time#related errors. *synchronous tasks that are

known to communicate with one another are tested with di&&erent data rates

and processing load to determine i& inters task synchroni>ation errors will

14


15/21

occur. ask that communicate via a message +ueue or data store are tested to

uncover errors in the si>ing o& these data storage areas.

System Test*$:-

So&tware and hardware are integrated and &ull ranges o&

system test are conducted in an attempt to uncover errors at the

so&tware7hardware inter&ace. Most real#time systems process interrupts. he

tester develops a list o& all possible interrupts and the processing that occurs

as a con se+uence o& the interrupts. ests are then designed to asses the&ollowing system characteristics'

*re interrupts priorities properly assigned and properly handled

"s processing &or each interrupts handle correctly

W*te B"1 Test*$:-

"t is also called glass bo$ testing. "t is a test

case design to derive test cases. "n this% all statement in the program has been

e$ecuted at least once during testing that all logical condition has been

e$ercised. Fsing white bo$ testing methods% the so&tware engineer can derive

test cases that

Guarantee that all independent paths within a module have been e$ercised at

least once.

E$ercise all loops at their boundaries and within their operational bounds.

E1e')*se *$te'$+! %+t+ st'&)t&'e t" +ss&'e te*' +!*%*ty.

1


16/21

B+s*) #+t test*$2 + 3*te-,"1 te)$*/&e2 m+0es &se "( #'"'+m

'+#s t" %'*e te set "( !*$e+'!y *$%e#e$%e$t tests t+t 3*!! e$s&'e

)"e'+e. C"$%*t*"$ +$% %+t+ (!"e test*$ (&'te' e1e')*se #'"'+m !"*)2

+$% !""# test*$ )"m#!eme$ts "te' 3*te-,"1 te)$*/&e ,y #'"*%*$ +

#'")e%&'e ("' e1e')*s*$ !""#s "( +'y*$ %e'ees "( )"m#!e1*ty.

15


17/21

B!+)0 B"1 Test*$:-

3nowing the speci&ied &unction that a product has

been design to per&orm% tests can be conducted that demonstrate each

&unction is &ully operational while at the same time searching &or errors in

each &unction black bo$ testing alludes to test that are conducted at the

so&tware inter&ace. * black bo$ test e$amines some &undamental aspect o& a

system with little regard &or he internal logical structure o& so&tware.

Aunction esting' # "n system design may have so may &unction. Each

program has de&ined into number o& &unction has its own task. 8e can test

each &unction to per&orm an accurate result. 8e must debug the &unction.

Aunction is block o& code that per&orms a particular task% and returns a

particular value.

Structural esting' # Each program has a structure% and contains the &unction%variable% control statement decision making loops header &iles% we can test

program structure these are de&ine properly in our program. So the

programmer set structure o& program.

1B


18/21

C"m,*$*$ St'&)t&'e +$% F&$)t*"$ Test*$: -

A(te' Test*$ *$ "&' #'"'+m (&$)t*"$ m+0es te set

te #'"'+m s" t+t e+) (&$)t*"$ *s '&$ te #'"'+m s" t+t e+)

(&$)t*"$ *s (&$ +))"'%*$ t" %e(*$e te st'&)t&'e. P'"'+m m+y +e

see'+! st'&)t&'+! +$% (&$)t*"$. P'"'+mme' )+$ +''+$e tese met"%

+$% st'&)t&'e tey +'e #'"#e'!y #e'("'m "&' t+s02 *( tey +'e $"t %"$e

sets te st'&)t&'es2

1C


19/21

CONCLUSION

s+m+'+ #"'t+! is a di&&erent e$perience and you can make the portal

creative over the internet as you get used to it. here can be lot o&

+##'ee$s*"$s about samagra portal when you get in to it &or the (*'st t*me.

*s you e$perience more and more o& it those apprehensions get %*ss+#e+'e%slowly. -emember that i& you stick to the basics% samagra portal become

m"'e e+s*e' than manual .

1D


20/21

he system is highly &le$ible one and is well e&&icient to make easy

interactions with the client .the key &ocus is given on data security% as the

obect id online and will be maintained in a proper way.

his will be a user#&riendly one and can success&ully overcome strict and

severe validation checks. he system will be a &le$ible one and changes

whenever can be made easy .using the &acility and &le$ibility in .;E and

S:% the sHw can be developed in a neat and simple manner there by

reducing the operation6s work .since the proect is developed in .;E as a

&ront#end and S: as a back#end it can be modi&ied easily and used &or a

long period

!


21/21

4. Te C"m#!ete Re(e'e$)e M+tte3 M+)D"$+!%

5. ASP.NET6C7 P'+#e' ,""0s

8. ASP.NET 5.9 D'e+m!e)

. BEGINING IN 54 DA;S

samagra portal.doc

Documents