CHAPTER - 1

INTRODUCTION
1.1 Company Profile
We have the specialized in Web application development. We have the good team of
programmers who can design and develop all kinds of your web applications. We have provided
best ecommerce solutions for the shopping cart web sites.
Web applications are the business strategies and policies implemented for the use of
business. Many companies are today purely depending on the online transfer for that they need
secure and reliable solutions. As we are the masters in providing the most secure solutions and
choosing the right kind of Web application is very important for you. We always guide you in
point of your business as well as for the future security of that particular web application. We can
design the static as well as the dynamic web applications.
Web application includes the following steps:
Analyzing your web application through the R& work
Making the perfect plan
Web application development
!esting and "#ecuting your web application
We are very fle#ible in the flow of your web application development. We will always
focus more on the customization of the web application. $ur web applications are always allows
user to add%delete futures.
&inally our web applications are user friendly' customizable and accurate ones. We
offer all kinds of support for web applications
1
1.2 OBJECTIVE
(ash)*onnect has been designed to embrace separation of the different design layers.
+t has also been written with ,component- programming in mind with clean simple interfaces
that can be reused.
Figure 1. Separation of logic
&igure . above shows how the code is split into the different design layers. /eparation
of code is very important for component programming and the use of +nterfaces is enforced to
ensure separation.
Cla !i"rarie
(ash)*onnect have been split into two main parts 0 the implementation code and the
business logic%data access. At some point the data access will be separated into a separate
assembly as will the handlers. What you will be left with is the following components:
(ash1andlers 2controller and handler ob3ects4
(ashataAccess 2data access ) protected from the outside world4
(ash*lass5ibrary 2classes and structures4
+mplementation *ode 2the asp# files that call the handler ob3ects4
2
CHAPTER - 2
#$#TE% ANA!$#I#
2.1 E&I#TIN' #$#TE%
6log
7hoto sharing
*urrent events
*hain of friends
3
2.2 PROPO#ED #$#TE%
Activity
Activity 5og
Advanced &orum
Advanced 7rofile (it
7ersonal 6log
*omment 8otify
&riend
&riend 5ist
7rofile /etup
9uestion%Answer
Rich :;+ with A<A=
"ase of access to recent trends%topics
&aster communication over longer distances
6ig audience
6logging
">uating computer to sociability
Marketing could always be a fun and creative method of doing business
More /ecure
4
2.( Pro)e*+ ,or-flo.
Most pro3ects follow ,typical- stages and these are defined in the table below.
/ P0ae Deli1era"le
. 7re)sales *ontract' /$W' /ales $rder
? Re>uirements Re>uirements document
@ esign 7ro3ect plan' Resource plan' ata efinition' esign document
A 6uild ,Milestone- builds' final build
B !esting & 9A !est plan' !est & bugs log' Working builds and versions
C ;ser !esting ;ser Acceptance /ign $ff
D Release eployment and notification to client' 6 backups' build scripts'
code package
E /upport 7roduction /ervices *ontract
+tFs very difficult to define a typical timeline for any given pro3ect as they are always very
different. 1owever the target for a medium size pro3ect is to implement within a @ to A month
period. 5arge pro3ects are to be complete within a C month period. With this in mind itFs
important to allocate the appropriate time to each stage.
!he following diagram shows how each stage breaks down in the entire process. 7hases
will obviously change depending on the size and comple#ity of pro3ects but as a guide the design
phase should be a sizeable part of the pro3ect to ensure everything is defined in sufficient enough
detail to avoid client dissatisfaction at the end of the pro3ect and to make sure we donFt incur
additional costs.
Pro)e*+ ,or- 2lo. Dia3ram
5
2.4 Pro56*+ion #er1i*e Pro*e
!he diagram below shows the process for implementing 7roduction /ervices 7ro3ects.
"ach stage is described in the subse>uent sections.
6
7
2.4.1Pre-ale
Deli1era"le789 *ontract and /tatement of Work' Master /ervice Agreement 2M/A4' 7roduction
/ervices Agreement 27/A4' /ales $rder 2/$4' 7re)sales Analysis
7re)sales is the first phase in the 7roduction /ervices process and is primarily the
responsibility of the sales department. +t involves the sales force talking with a prospect
regarding solutions and services we can provide for the prospectFs business.
uring the sales cycle' the sales force uses a central tracker system to log phone calls and
other interactions with the client. +t is the responsibility of the sales force to enter basic
information into the tracker system about the client such as the main contact name' address'
phone number' description of business and other basic identifying information.
&or each good prospect' the /ales Account Manager 2/AM4 will make a re>uest to the
1ead of evelopment for a 7resales "ngineer 27/"4 to be assigned to the prospect' based on
skill set' availability' and possible pro3ect scale. !he 7/" will be involved in the process to help
the sales force with estimating time and costs.
A very important part of this stage is to provide technical e#pertise to assist the sales
workforce. Many times the sales force is asked technical >uestions about the services we provide
and re>uire someone with the relevant skills to assist. +t also ensures that the sales force is not
agreeing to anything we simply cannot deliver upon or at least make it known that a custom
engineering effort is re>uired.
!he 7/"Fs 3ob is to create a 7re)sales Analysis Report from the available information
from the client. !his information includes any data' documentation' print products' websites etc.
that will help the 7/" understand and outline the services and modules re>uested by the client.
At this stage' the 7/" should also identify any >uestions that need to be answered by the client in
order to properly estimate time and costs. !his 7re)sales Analysis is a summary from the 7/"Fs
understanding of what the pro3ect will re>uire.
8
A proposal is drafted by the /AM and sent to the client for review. !his enters an iterative
process of reviews and negotiations to agree on the various aspects of the pro3ect' timelines and
pricing.
$nce the proposal is agreed' it is signed by both parties and becomes the Con+ra*+
binding (ash+!Media to deliver products and services to the client for agreed payment terms.
7ricing structures should cater for 7rint !emplates in a slightly different way. 1istorically
contracts were BGH in advance' BGH on completion. !he issue with this is ,complete- is open to
interpretation by the client. /ometimes the /olis database and /earch &ront "nd is operational
months before the 7rint !emplates are re>uired for delivery. !he payment terms should cater for
such scenarios ensuring we are paid for work delivered.
Another aspect of the sales process is defining a Pro56*+ion #er1i*e A3reemen+. !his
agreement specifies how much ,support- time will be provided to the client for a given period of
time 2generally monthly4. +t will specify if time can be rolled over to the ne#t month or if that
time is lost each month.
7art of the *ontract is a #+a+emen+ of ,or-. !his summarizes the main components of
what is re>uired 2high level4 for the pro3ect. !he /AM and 7/" will create a client%pro3ect entry
in !racker with the following information:
*lient +nformation 28ame' address' telephone' email' web site etc4.
*ontact 7erson 28ame' email' telephone' fa# etc4
6ackground on the client indicating their primary business and what they do.
+nformation about what the (ash+!Media solution is going to do for them and
improvements that will be realized as a result.
etails on the modules re>uired for the pro3ect 2/olis' Research' /&" etc4.
(nown timings or those agreed during the sales process.
/upport hours agreed.
!he 7ro3ect Manager 2if identified at this point4.
9
;pload the /tatement of Work from the *ontract.
;pload the 7roduction /ervices Agreement
$nce all documents have been received and signed off' the prospect becomes a client.
"lectronic versions of the *ontract' 7/A and M/A are uploaded into the tracker system so that it
is easily accessible by all relevant parties when viewing the pro3ect. +n order to bring this phase
to completion' all appropriate modules that weFre contracted to provide will be checked off in the
tracker system by the 7/". Also' a start and preliminary end date must to be entered into the
system.
After all this information is entered the tracker system will automatically generate an
alert to the 7roduction /ervices Manager stating a new pro3ect is in the system and needs to be
processed.
2.4.2 Pro)e*+ :i*- Off
Prere;6ii+e78: /tatement of Work' M/A' 7/A' 7re)sales Analysis
Deli1era"le789 7M and 75Fs analysis' notes and conclusions must be entered and organized in
tracker
When the 7re)sales phase ends' the 7ro3ect kick)off starts and the 7/ 27roduction
/ervices irector4 is notified via the tracker system of the clientFs new pro3ects re>uiring
attention. !he 7/ will then work with the 17M 21ead of 7ro3ect Management4 to nominate a
7M 27ro3ect Manager4 responsible for the clientFs new pro3ects. !he 7M will be nominated based
on availability and e#perience and based on the new pro3ectsF scale and importance.
!he 7M will then familiarize himself with the pro3ect by going through the concerned
documents and notes that have been logged into the tracker system during the 7re)sales phase.
6esides the documents being pre)sales deliverables' the 7M should find at this point in the
tracker system an overview of the clientFs background' notes about its pro3ects' contact
information of its relevant staff members' re>uested%preferred timelines if any and location%state
of its data when already available.
10
!he 7M must nominate a 75 27ro3ect 5ead % !echnical 5ead4 to be the primary technical
person for the pro3ect. !he 75 will be chosen based on availability' e#perience and skill)set.
!he 7M and the 75 will both e#amine the previously gathered information concerning
the pro3ect in order to understand what is needed and decide on the composition of the team
re>uired to achieve the pro3ect 2team composition will only be confirmed at the end of the
Re>uirements phase4. !hey will together prepare a list of >uestions for the client in order to
clarify any ambiguities.
!he 7M will arrange a kick)off call with the client to:
+dentify the resources on both ends that can be reached concerning the various pro3ectFs
aspects 2e.g. data' graphics' /;+' /&"' tech contact' etc...4
Review the clientFs e#pectations and discuss if necessary the platform%standard
mechanisms 2i.e. manage the clientFs e#pectations4
"#plain to the client the implementation process 2what are the ne#t steps' how the
revision cycles work' how are the deployments managed' how tracker is used and what
role this interface should play' etc...4
:ive to the client an informal timeline for the ne#t phases in the pro3ectFs lifecycle 2data
analysis and business re>uirements definition4
Attempt to answer any >uestions the client may have at this point
Ask the client the >uestions prepared with the 75 to clarify the unclear areas in the
pro3ectFs scope
Ask for the clientFs data 2e#haustive data structure populated with a data sample at the
very least4 if it has not been provided already.
"very client added in to the !racker system will have access to their own ,portal-. !his is a
new feature to be added to !racker. !his will be used as the primary communication tool
ensuring all re>uests are logged' acknowledged and subse>uently answered. !his system will be
11
introduced to the *lient during the kick)off call ensuring the protocol for communication is
established and understood by all parties. !he key is to remove the reliance on email to
communicate. "mail should simply be the ,notification- vehicleI all actual information must be
logged in the system.
At the end of the kick)off call the client should know what is going to happen ne#t' when it is
going to happen and how to communicate with the pro3ect team 2contacting the right persons and
using the tracker system4. !he 7M should have all the re>uired elements to move into the ne#t
phases of the pro3ect.
!he 7M and 75 have to make sure that all the new elements' pieces of information' answers
and variables that have been gathered and discussed during the kick)off call are entered and
organized in the tracker system. !his consolidation and refinement of the pro3ectFs initial
knowledge base can be considered as the main deliverable of the 7ro3ect kick)off and is therefore
crucial.
After the kick)off call' the 7M has to review with the 75 the anticipated team composition'
process and timeline and refine%update their analysis. With the product of this analysis entered in
tracker' the 7M will contact the 1eads of "ngineering' *reative esign and 9A to discuss the
pro3ectFs variables.
!he following is an initial checklist of items to be covered in the kick)off meeting:
8ame and contact information for 7M and 75
*onfirmation of the pro3ect modules re>uired
/ummary of the implementation process
iscussion of proposed timeline' knowing these are preliminary and will be ,firmed-
during the design phase.
5ogin information for client portal
*ommunication protocols
&!7 credentials for file transfer
12
2.4.( Re;6iremen+ P0ae
Prere;6ii+e78: (ick)off call
Deli1era"le78: 6usiness Re>uirements efinition 26R4
!he ne#t step is the creation of the 6R. !his will be written by the !5 with input as
needed from the 7M' 7/" and any allocated members of the evelopment department. !he 6R
establishes the specific re>uirements for the entire pro3ect 2/&"' /;+' print etc.4' and documents
them thoroughly. !his document should include as much detail as possibleI keeping in mind itFs
purposed is to e#plain what functionality is re>uired. 1ow this functionality will be delivered is a
purpose of the esign ocument.
!he 6R is an e#tension to the /tatement of Work and acts as a scope document forming
the basis of the esign ocuments. +ts primary purpose is to define the ma3or re>uirements
deemed in scope and 3ust as important those re>uirements that are outside the pro3ect scope.
Refining what is in and out of scope is part of this phase and communication with the client is
critical.
Re>uirements must be testable statements that can be checked off during the esign
process to ensure nothing is missed' and also by the 9A team ensuring all re>uirements were
met. !he 6R is the document that the engineering team will reference during the esign phase.
+n some implementations this document may simply be a standard template e#plaining
the key re>uirements%functions of /olis' /&"s' and /;+s etc. Remember this document is also an
information provider to the client stating what they are getting. +n some cases the client contact
responsible for the successful implementation may not have been involved in the presales
activities and thus might know very little about what theyFre getting.
!he 6R should also specify any ma3or ,known- client deadlines and dependencies 2e.g.
final data source to be received by this date' etc.4. +t might not always be possible for
(ash+!Media to achieve them but but they should be stated here anyway.
13
+f custom engineering components are re>uired i.e. we need to change the way /olis
works to achieve what the client wants' they must be identified in the 6R in their own section
or at least marked that specific custom engineering is re>uired.
A full dataset or at least the full data definition%dictionary from the client must be
received by the 7M%!5 during the Re>uirements phase so proper analysis can be completed.
Without the data we cannot perform detailed re>uirements analysis ensuring we can in fact
deliver what we say we can.
!he writing of the 6R will be an iterative process between the client and 7M%!5' with
telephone contact necessary. !his will mean the 7M%!5 will be re>uired to stay late on occasion
to speak with clients. !hese meetings should be scheduled and agreed during the early stages of
the pro3ect and all communication logged in the central tracking system.
uring this phase the 7M%!5 now knowing the clientFs re>uirements' must verify that the
pro3ect can still be completed in the timeline proposed by the 7/" during the pre)sales phase. +f
there are any >uestions regarding what re>uirements should or should not be included in the
pro3ect' this should be escalated to the /AM for resolution.
!he 6R must be signed off by the client and (ash+!Media ensuring all parties agree on
whatFs re>uired to deem the pro3ect -complete-.
$nce the 6R is agreed returned by the client' an electronic copy must be uploaded into
the tracker system. !his marks the completion of the Re>uirements phase.
!he 7M%!5 will work with the 1ead of "ngineering to allocate the relevant team
members based on skill set' availability and pro3ect scale to initiate the full pro3ect.
2.4.4Dei3n P0ae
Prere;6ii+e78: 6usiness Re>uirements efinition 26R4 has been produced and signed)off
Deli1era"le78: esign ocument
14
!his phase is one of the most critical of the pro3ect. +tFs vitally important to ensure all
re>uirements are catered for and everything is defined in sufficient enough detail to ensure no
ambiguity is raised at the end of the pro3ect. At the end of this phase it must be very clear to the
client what they will be getting and clear to (ash+!Media what we will be building.
!here are three deliverables for this phase of the pro3ect a4 ata efinition ocument b4
!echnical esign ocument and c4 7ro3ect 7lan. !he first two are client facing' the pro3ect plan
is an internal plan with resource allocations. (ey milestones from this plan are communicated to
the client through the portal and summary page in the esign ocument.
2.4.4.1 Da+a Defini+ion
Prere;6ii+e78: Re>uirements efinition
Deli1era"le78: ata efinition ocument
+t is the responsibility of the atabase eveloper to create the ata efinition ocument.
!hey will re>uire guidance from other team members but they are responsible for creating this
document. !hey will receive sample or actual data from the client and they must analyze it'
understand it and decide how it will be broken up and imported into the /olis platform.
!he ata efinition ocument
must ade>uately describe the structure of the /olis database in terms of groups' fields'
categories' users and any custom tables re>uired 2such as lookup tables4.
must describe what source data is being provided to (ash+!Media' itFs format and how it
will be mapped to the groups and fields.
must describe the processing to be performed. +n most cases a normalization process must
be undertaken to ensure a good logical model. Where tables are being broken up and data
is being ,cleaned- into reference tables it must be described in detail. +f the client is to
undertake some of these activities prior to supplying the final data it must also be noted
here.
15
2.4.4.2 Dei3n
Prere;6ii+e78: Re>uirements efinition
Deli1era"le78: esign ocument and%or !echnical esign
!he esign ocument will describe in detail what is to be built' how it will function and
what it will look like when delivered. +t will cover all components of the pro3ect 2including /olis'
/earch &ront "nds' /elf ;pdating +nterfaces' print page layout etc4. "ach pro3ect component is
worked on by the relevant resourceI clearly the 7age 5ayout /pecialist will define the print
template detail and /oftware "ngineers will design components such as the /earch &ront "nd
and /elf ;pdating +nterface. !he atabase evelopers may also be involved if database
design%creation is re>uired 2highly likely when delivering a /earch &ront "nd product4.
+f custom engineering components were identified during the re>uirements phase and are
deemed in scope these need to be defined and included in a !echnical esign ocument. !he
general workings or result of the custom engineering is covered in the esign ocument but the
physical database design schemas' class diagrams and schemas are placed in a separate
document. Most clients will not have any interest or understand technical designs and as such
must be put into an internal document.
!he esign document will be overseen by the 7ro3ect 5ead % !eam 5ead and 7ro3ect
Manager and must given clearance by both before being sent to the client for review. !he number
of review cycles for the client largely depends on the size and comple#ity of the pro3ect. +tFs
always a good idea to involve the client during the design phase to ensure time is not wasted
designing components that do not satisfy the clientFs needs.
8ote that if the pro3ect is small in nature it may be appropriate to combine the ata
efinition ocument and esign ocument into one all encompassing document. !his is at the
discretion of the 7ro3ect 5ead % !eam 5ead and 7ro3ect Manager
2.4.4.( Plannin3
16
Prere;6ii+e78: Re>uirements efinition' esign ocument
Deli1era"le78: 7ro3ect 7lan
As the esign is coming together the 7ro3ect Manager must create a 7ro3ect 7lan
indicating the ma3or milestones' when they will be delivered' who is working on what task and
for how long. !his is an internal document that is uploaded into !racker and maintained 2ideally
it is integrated into !racker but this is along term goal4. !his pro3ect plan will feed the overall
department Resource 7lan that will map out all resources for the department.
!he key milestones along with delivery dates are entered into !racker and these form the
basis for showing a pro3ectFs status not only to the client but also senior management. +t is
absolutely critical that the 7ro3ect Manager maintain these milestones and status markers to
ensure consistent client feedback. +f a client feels there is progress being made they are less
likely to phone up and re>uest status meetings.
!ime for !esting' 9A' 6uild and Release phases must be built into the pro3ect plan. 9A
7ersonnel must be consulted to ensure schedules donFt conflict or to resolve them in whatever
way is deemed appropriate.
!he 7M%75 must include milestone builds in the plan. A /earch &ront "nd release would
be considered a milestone build. +f the /olis implementation has a number of custom engineering
components' each of these might be considered a separate milestone build and e#pected to be
shown to the pro3ect piecemeal. !his will involve creating incremental builds as well as a full
build towards the end of the phase. All of this should be worked out during the planning phase
and included in the 7ro3ect 7lan.
2.4.<B6il5 P0ae
Prere;6ii+e78: Re>uirements efinition' esign ocument' !echnical esign' 7ro3ect 7lan
Deli1era"le78: Milestone builds &inal build
17
!his is the phase all /oftware "ngineers are eager for as they now get to create the
products. +f the design phase was completed in the desired detail the build phase should be the
easy part. +t may take a long time but if "ngineers are following clear designs they will make
significant progress very >uickly.
!he build phase typically follows the following se>uence. 1owever' this is not set in
stone and the order of components should be worked out during the design epending on the
type of pro3ect the steps may be switched:
.. !he ata +mport is generally the first step to be performed and is the responsibility of the
atabase evelopers.
?. /olis configuration can also start but generally needs to wait until data is imported.
*reating the /olis interface is the responsibility of /oftware "ngineers.
@. +t may be possible to start the underlying structure of /earch &ront "nds in parallel as
long as the design is thorough enough. !here will come a point when data is re>uired to
ensure it will work in the way itFs supposed to. 6efore the /&" data e#tract routine can be
written the data import must first be completed.
A. /elf ;pdating +nterfaces 2including research interfaces4 typically must to wait until the
data import is completed and the /olis database is confirmed. !his is because group
structures always change slightly during the import to cater for new discoveries. !his is
the responsibility of /oftware "ngineers.
B. 7rint ata "#tracts are the responsibility of atabase evelopers and 7age 5ayout
/pecialists. !hese scripts can only be written once /olis has been configured and the data
imported.
!he build phase should follow the /*M process and guidelines as laid out in the
(ash+!Media /oftware *onfiguration Management document. 7lease refer to this document for
detailed descriptions on the build process and source control mechanisms.
2.4.<.1 =A
Prere;6ii+e78: Re>uirements efinition' esign ocument' !echnical esign' 7ro3ect 7lan
18
Deli1era"le78: !est 7lan' 6ug Reports
9A is an e#tremely important part of any pro3ect to ensure bugs are caught early in the
build process and fi#ed before a client release. !he 9A process will generally start mid way
through the build cycle and should be treated as an integral part of the overall build process.
/oftware "ngineers and 9A "ngineers will work closely together to test and fi# components.
!he overall design should allow for a staggered approach to development making sure
appropriate time is allocated to the testing of the products. $nce the build has started the 9A
team should work closely with the pro3ect team to draw up test plans ensuring the 9A !eam has
a good enough understanding of the pro3ect to provide ade>uate 9A and testing. !hey must draw
up a test plan that covers all aspects of the pro3ect ensuring all re>uirements have been met and
that features described in the design document work as described.
6efore any milestone release is pushed to the /taging "nvironment the 9A team and
7ro3ect Manager must sign off on all aspects of the deliverable. !his not only includes new
features but is a guarantee that regression testing has been performed 2i.e. ensuring that
something that was working in a previous version also works in this new version4. /oftware
"ngineers tend to only look forward and in many cases they insert new functionality that breaks
e#isting features. /oftware "ngineers should always consider and test this as part of their unit
testing. !he 9A !eam is responsible for ensuring everything works correctly prior to any given
release.
uring 9A bugs identified are logged into the !racking system with reports on what
happened' what the user was doing when it broke and any suggestions as to what might be
happening. !he /oftware "ngineer responsible for that component is alerted and is then
responsible for fi#ing it and updating the bug report with what action was taken to fi# it. !his
process is defined in detail in the (ash+!Media /oftware *onfiguration Management document.
/ome other considerations that both the 7ro3ect and 9A !eams should work together on are:
/imulating high traffic scenarios to ensure ade>uate performance
19
atabase concurrency and performance under high load
Anticipate une#pected user actions in the applications and try to ,break- everything.
"verything must be documented and have people accountable for testing components.
2.4.> Uer A**ep+an*e
Deli1era"le78: /igned ;ser Acceptance ocument
&or the purposes of clarity this activity has been split into its own phase but in reality itFs
part of the 6uild. +t is a bad idea to leave all user acceptance testing until the very end of the
pro3ect. !he sooner the client can see the product the sooner they can raise issues and the
easier%cheaper it is to fi# them. !his is why itFs critical that the design be put together in a
modular approach.
&or these implementations we need a hybrid approach between a standard /5* and
Agile approach. We need to ensure that the system is designed properly but also to ensure we
show the client at as many stages throughout the build as possible to adapt to the ever changing
needs. Remember the client will have agreed to the re>uirements and design but there will
always be changes. !he key is to identify them and determine if they will have a negative impact
on the pro3ect. !his is where the 7ro3ect Manager must be the controlling element and look out
for this in every phase.
+n some cases it might be possible to seek client sign off on the various components
during the build. &or e#ample the client might sign off on the /olis *onfiguration and then sign
off on the /earch &ront "nd rather than sign off on all components when all are finished. +f this
approach is to be taken itFs important to define it thoroughly during the esign 7hase so the
client is aware of the modular approach. !his is generally the recommended approach for all
pro3ects.
2.4.?Releae
Prere;6ii+e789 /igned ;ser Acceptance ocument
20
6efore any component or full implementation is placed into the production environment
we must be in receipt of a signed ;ser Acceptance ocument indicating that the client approves
the work and is happy for it to go live. !he moment this sign off happens that particular
component is considered live' delivered and moved into /upport mode.
!he *ustomer /ervice /upervisor must be notified that a particular component%or pro3ect
is now live and that the 7roduction /ervices /upport Agreement is now in effect. uring the
;ser Acceptance testing phase it is a good idea to inform the *ustomer /ervice /upervisor that a
new pro3ect is in testing and will likely be moving to the production environment shortly. !hey
will then work together 2along with the !ech /upport personnel4 to ensure a handover of basic
knowledge is conducted and that the !ech /upport personnel have all the information.
2.4.@ #6ppor+ an5 %ain+enan*e
Prere;6ii+e789 /igned ;ser Acceptance ocument' 7roduction /ervices Agreement
As mentioned in the Release phase' as soon as a component or full pro3ect enters the
production environment it is considered live and is then controlled under the 7roduction /ervices
Agreement regarding time allocated to support and maintain the pro3ect components.
!he *ustomer /ervice /upervisor is responsible for knowing which pro3ects 2or parts of
pro3ects4 are in a ,live- state and therefore know how much time can be allocated to them. !he
tracker system will aid in this and will have checks in place to ensure additional time cannot be
logged against tasks where a 7roduction service agreement doesnFt e#ist or if the time allocated
is reached.
When a re>uest is submitted to the !echnical /upport personnel it will be done through
the customer portal application. "very re>uest is logged and the !echnical /upport personnel will
monitor this for re>uests and respond accordingly. !hey are responsible for ensuring all re>uests
are addressed and ultimately solved. !his may involve contacting the client to gather more
information or escalating issues where necessary.
21
2.4.A Deli1era"le from a BTypi*alC Pro)e*+
!he previous section e#plained in detail the deliverables e#pected from each phase. !he
following diagram is a graphical representation of dependencies for a typical end to end pro3ect
involving the most common components. +t is by no means a rigid format for any pro3ect but
simply highlights parallel activities that can occur during an implementation.
As you can see the deliverables re>uired in the early stages of a pro3ect tend to be
se>uential culminating in a 7ro3ect 7lan. $nce the build phase starts you will notice that parallel
tasks can occur with smaller internal dependences. +t is important to understand what
components depend on others in order to ma#imize efficiencies in the pro3ect plan.
22
CHAPTER - (
#$#TE% #PECI2ICATION
(.1 HARD,ARE RE=UI%ENT#
7rocessor : +8!"5 7entium A
RAM : B.?M6
1ard isk rive : AG:6
(ey 6oard : /tandard .G.%.G? or igi /ync &amily
Monitor : isplay 7anel 2.G?A = DCA4
isplay Adapter : !rident /uper J:A
8etwork Adapter : /M* "thernet *ard "lite .C ;ltra
Mouse : 5ogitech /erial Mouse
(.2 #O2T,ARE RE=UI%ENT#
$perating /ystem : Windows =7
&ront) "nd : *K. 8"! with A/7. 8"!
6ack) "nd : M/ /95 /"RJ"R ?GGB "=7R"//
23
CHAPTER - 4
#$#TE% DE#I'N
4.1 INTRODUCTION
!he most creative and challenging face of the system development is /ystem esign. +t
provides the understanding and procedural details necessary for implementing the system
recommended in the feasibility study. esign goes through the logical and physical stages of
development.
+n designing a new system' the system analyst must have a clear understanding of the
ob3ectives' which the design is aiming to fulfill. !he first step is to determine how the output is to
be produced and in what format. /econd' input data and master files have to be designed to meet
the re>uirements of the proposed output. !he operational phases are handled through program
construction and testing.
esign of a system can be defined as a process of applying various techni>ues and
principles for the purpose of defining a device' a process or a system in sufficient detail to permit
its physical realization. !hus system design is a solution to ,how to- approach to the creation of
a new system. !hus important phase provides the understanding and the procedural details
necessary for implementing the system recommended in the feasibility study. !he design step
provides a data design' architectural design' and a procedural design.
OUTPUT DE#I'N
+n the output design' the emphasis is on producing a hard copy of the information
re>uested or displaying the output on the *R! screen in a predetermined format. !wo of the most
output media today are printers and the screen. Most users now access their reports from a hard
copy or screen display. *omputerFs output is the most important and direct source of information
24
to the user' efficient' logical' output design should improve the systems relations with the user
and help in decision)making.
As the outputs are the most important source of information to the user' better design
should improve the systemFs relation and also should help in decision)making. !he output
deviceFs capability' print capability' print capability' response time re>uirements etc should also
be considered form design elaborates the way output is presented and layout available for
capturing information. +tFs very helpful to produce the clear' accurate and speedy information for
end users.
INPUT DE#I'N
+n the input design' user)oriented inputs are converted into a computer based system
format. +t also includes determining the record media' method of input' speed of capture and
entry on to the screen. $nline data entry accepts commands and data through a keyboard. !he
ma3or approach to input design is the menu and the prompt design. +n each alternative' the userFs
options are predefined. !he data flow diagram indicates logical data flow' data stores' source and
destination. +nput data are collected and organized into a group of similar data. $nce identified
input media are selected for processing.
+n this software' importance is given to develop :raphical ;ser +nterface 2:;+4' which is
an important factor in developing efficient and user)friendly software. &or inputting user data'
attractive forms are designed. ;ser can also select desired options from the menu' which
provides all possible facilities.
Also the important input format is designed in such a way that accidental errors are
avoided. !he user has to input only 3ust the minimum data re>uired' which also helps in avoiding
the errors that the users may make. Accurate designing of the input format is very important in
developing efficient software. !he goal or input design is to make entry as easy' logical and free
from errors.
25
!O'ICA! DE#I'N
5ogical data design is about the logically implied data. "ach and every data in the form
can be designed in such a manner to understand the meaning. 5ogical data designing should give
a clear understanding and idea about the related data used to construct a form.
DATA 2!O, DIA'RA%
A ata &low iagram 2&4 is a diagram that describes the flow of data and the
processes that change data throughout a system. +tFs a structured analysis and design tool that can
be used for flowcharting in place of or in association with information. $riented and process
oriented system flowcharts. When analysts prepare the ata &low iagram' they specify the user
needs at a level of detail that virtually determines the information flow into and out of the system
and the re>uired data resources. !his network is constructed by using a set of symbols that do not
imply physical implementations. !he ata &low iagram reviews the current physical system'
prepares input and output specification' specifies the implementation plan etc.
&our basic symbols are used to construct data flow diagrams. !hey are symbols that
represent data source' data flows' and data transformations and data storage. !he points at which
data are transformed are represented by enclosed figures' usually circles' which are called nodes.
DATA 2!O, DIA'RA% #$%BO!#9-
- #o6r*e or De+ina+ion of 5a+a
- Da+a 2lo.
- Pro*e
26
- #+ora3e
#+ep +o Con+r6*+ Da+a 2lo. Dia3ram
&our steps are commonly used to construct a &
7rocess should be named and numbered for easy reference. "ach name should be
representative of the process.
!he destination of flow is from top to bottom and from left to right.
When a process is e#ploded in to lower level details they are numbered.
!he names of data stores' sources and destinations are written in capital letters.
R6le for *on+r6*+in3 a Da+a 2lo. Dia3ram
Arrows should not cross each other.
/>uares' circles and files must bear names.
ecomposed data flow s>uares and circles can have same names.
raw all data flow around the outside of the diagram.
4.2 DATABA#E
27
Ar+i*le %o56le9
Blo3 %o56le9
28
article_ channels
article_ comments
article_ ratings
article_ types
articles
2or6m an5 5i*6ion9
discussion_ comments
discussion_ users
discussions forum_ categories
forum_ thread_ comments
forum_ threads
forums
29
Uer %o56le9
user_ connection_ request_ status
user_ connection_ requests
user_ connections
user_ fles
user_ folder_ images
user_ folder_ videos
user_ folders
user_ group_ article_ types
user_ group_ module_ functions
user_ group_ users user_ groups
user_ images
user_ links
user_ messages user_ profle_ display_ felds
user_ videos
user_ widgets
users
4.( U%! DIA'RA%#
30
4.(.1 U#ECA#E DIA'RA%
U#ECA#E DIA'RA%
31
CHAPTER - <
#$#TE% DEVE!OP%ENT
<.1 INTRODUCTION
/ystem development is a series of operations performed to manipulate data to produce
output from computer system. !his aim at translating the design of the system produced during
32
the design phase intro code in user programming language. A modular approach is used for the
development of the software.
When we divide a system into different modules in a logical order it will lead us into a
clear solution for the problem. A module contains a group of related functions' which pass data
each other. !hat means there is a very good correlation between the different functions in a
module. "ach module will accomplish a specific task or work for the pro3ect. !he 3oint
functioning of all these modules will pay way for the ultimate solution.
When we go for modularization keep the following things in mind:
Modularization can be done in a !op)down approach or 6ottom)up approach.
!he dependency between the modules should be minimum.
!he functioning of the modules must have a flow.
!he functioning inside a module must be related with each other.

!he development phase for the pro3ect was created from the specifications created during
the design phase. A principal activity of the development phase is coding and testing the
computer program that make up the computer program component of the overall system. $ther
important activities include implementation' planning' e>uipment ac>uisition and system testing.
33
<.2 %ODU!E DE#CRIPTION
%o56le9
A5min %o56le
Uer %o56le
<.2.1 A5min %o56le9
Uer A**o6n+9
Admin can able to manage the user of this community site in this user account
section. Admin can able to search the user by first name' last name and designation. Add
user functionality is available to add user directly to the system. Admin can able to
block%delete a user from the community. Reports like list of blocked users' recently added
users and active users can be generated.
#y+em Confi36ra+ion9
+n this' Admin can able to manage the configuration of the site like' total records
displayed per page' image size' font size' etc.' Admin can also able to manage the page
layout like' header' footer' left panel' *//' etc.'
Appro1al %ana3emen+9
Admin can able to change the approval system at any time. Approval for new
users' newly added forum%blog%articles. Admin can also able to view the approval
summary' which will be helpful for audit purpose.
R## 2ee5 %ana3emen+9
Admin has the option to add new R// feeds and mange the e#isting feeds. ;ser
can able to subscribe or configure the R// feed to their dashboard.
2or6m Confi36ra+ion9
Admin can able to manage the forum in this community site. Admin have to
start%create the forum. Admin will be creating the categories for the forum. Admin can
also manage the forum topics and settings of the forum.
34
<.2.2 Uer %o56le9
Da0"oar59
;ser can able to customize his dashboard. 1e configures' what are all the things to be
displayed in the ashboard' like +nbo# 2used to view the messages like private or any friend
re>uest or any comments to them4' e#ternal R// feeds 2Admin will configure the e#ternal
R// feeds' user can subscribe to those feeds4' +nternal R// feeds 2like most%recently%highly
commented or most rated articles % blog % forum4.
Profile #e+6p9
;ser needs to setup their profile with needed information. 7rofile module will have
four sections.
6asic 7rofile
"#tended 7rofile
5inks
7rivacy /ettings
6asic profile will contain the details like 8ame' address' company details.
"#tended 7rofile will have About me' My "#perience.
+n 5inks' user can able to promote their own links or company links.
+n privacy settings' user can able to restrict others to view their profile or can able to
configure what all are the things to be displayed to others.
%ana3e me5ia li"rary9
;ser can able to upload photos or files to this site. ;ser can also able to manage
their files like setting photo as profile photo or hiding photos from others.
35
2rien5 li+9
;ser can able to search the friends by first name' last name' designation and
department or starts with or contains. ;ser can able to send the private message to
particular user or groups of users. *an able to start public messaging also. Messages will
be saved in inbo# and user can able to see that in dashboard.
Blo3D 2or6m an5 Ar+i*le9
;ser can able to create own blog' forum and articles. ;ser can also able to comment or
rate other blog%forum%articles. 8otification will be saved in inbo#.
36
CHAPTER - >
#$#TE% TE#TIN' AND I%P!E%ENTATION #$#TE% TE#TIN' AND I%P!E%ENTATION
>.1 INTRODUCTION
!esting is vital to the success of the system. /ystem testing makes a logical assumption
that if all the parts of the system are correct' the goal will be successfully achieved. /ystem
testing is the stage of implementation that is aimed at assuring that the system works accurately
and efficiently before live operation commences.

/oftware testing is a critical element of software >uality assurance and represents the
ultimate review of specification' design and coding. !he user tests the developed system and
changes are made according to their needs. !he testing phase involves the testing of developed
system using various kinds of data
Nee5 for +e+in3
!esting is re>uired at every stage of development' as to know how each module works on
its own and when integrated with other modules. While developing' many errors are foreseen
which come into light when the modules runs. !he purpose of testing is to find out what works
and what not.
>.2 %ANNUA! TE#TIN' O2 THE APP!ICATION
+n the development of this web application all the concept of testing and error deduction
was performed through manually in that ;8+! !"/!+8: and 7"8"!RA!+$8 !"/!+8: both
are main things which performed on the application manually.
37
>.( PENETRATION TE#TIN'
!his is the first in a series of three articles on penetration testing for Web applications.
!he first installment provides the penetration tester with an overview of Web applications ) how
they work' how they interact with users' and most importantly how developers can e#pose data
and systems with poorly written and secured Web application front)ends.
Web applications are becoming more prevalent and increasingly more sophisticated' and
as such they are critical to almost all ma3or online businesses. As with most security issues
involving client%server communications' Web application vulnerabilities generally stem from
improper handling of client re>uests and%or a lack of input validation checking on the part of the
developer.
!he very nature of Web applications ability to collate' process and disseminate
information over the +nternet e#poses them in two ways. &irst and most obviously' they have
total e#posure by nature of being publicly accessible. !his makes security through obscurity
impossible and heightens the re>uirement for hardened code.
>.4 UNIT TE#TIN'
+n this' the programs that made up the system were tested. !his is also called as program
testing. !his level of testing focuses on the modules' independently of one another. !he purpose
of unit testing is to determine the correct working of the individual modules. &or unit testing' we
first adopted the code testing strategy' which e#amined the logic of program.
uring the development process itself all the synta# errors etc. got rooted out. &or this we
developed test case that results in e#ecuting every instruction in the program or module i.e. every
path through program was tested. ;nit testing involves a precise definition of test cases' testing
criteria' and management of test cases .!he main purpose behind testing is to find errors. !here
are four categories of tests that a programmer will typically perform on a program unit.
&unctional tests
38
7erformance tests
/tress tests
/tructure tests
Functional Tests
&unctional tests' where test cases involving e#ercising the code with nominal input
values for which the e#pected results are known' were done.
Performance Tests
7erformance testing is concerned with the evaluation speed and memory utilization of the
program. ;sing various test cases tests the package and the performance is found satisfactory.
Stress Tests
/tress testing' which is concerned with e#ercising the internal logic of a program and
traveling particular e#ecution paths is done. !he input is given in such a way that starting form
re>uest from client to the 3ob completion all possible paths is tested.
Structure Tests
/tructure testing is also referred to as White 6o# or :lass 6o# testing. !he pro3ect is
tested for its e#ecution in every module. !he testing operation is successfully done and every
module performs properly.
CHAPTER - ?
CONC!U#ION AND #COPE 2OR 2UTURE ENHANCE%ENT
(ash)*onnect will be the great solution for making the employee to connect each other.
+t consists of professional and fun activities. +t will make the user to know about the company
39
and about the individual. 6logs' &orum' Articles' messaging with public and private are the
powerful areas where everyone can en3oy their working.
!he application was developed with latest technology and well effective design patterns.
!his application is using A<A= technology to the core. Rich ;+ and usability will give pleasant
e#perience to the user. After all the application was tested' by ;8+! and 7"8"!RA!+$8
testingFs by manually.
CHAPTER - @
APPENDI&
@.1 #OURCE CODE
B6++on *li*- e1en+9
40
While clicking the sign in button' it will first do the client side validation and it will move
to server side validation. $nce this is completed' it will call the interface by passing the email id
and password to it.
protected void btn/ign+nL$n*lick2ob3ect sender' "ventArgs e4
M
%% validate the user entry
if 2email.!e#t.5ength N A4
M
Lmaster7age./et"rrorMessage2O;sername is invalidO4I
returnI
P
if 2pwd.!e#t.5ength N A4
M
Lmaster7age./et"rrorMessage2O7assword is invalidO4I
returnI
P
%% now try and sign in
+/ession1andler db Q new /ession1andler2Lmaster7age.*ontroller4I
bool hasAccepted!* Q falseI
/ign+nResponse respI
try
M
%% try and sign in
resp Q db./ign+n2email.!e#t' pwd.!e#t4I
if 2Rresp./uccess4
M
41
Lmaster7age./et"rrorMessage2resp."rrorMessage4I
returnI
P
%% set cookie
/et*ookie2resp.;ser/ession4I
%% check for acceptance of !* ) need to do this for user
%% accounts already created
hasAccepted!* Q resp.;ser/ession.1asRead!erms*onditionsI
P
catch 2"#ception e#4
M
string additional Q string."mptyI
if 2e#.+nner"#ception RQ null4
M
switch 2e#.+nner"#ception.Message./ubstring2G' @44
M
case O2@4O:
additional Q O SAccount is lockedTOI
breakI
case O2D4O:
case O2E4O:
case O2U4O:
additional Q O S+nternal "rror: O V e#.+nner"#ception.Message V OTOI
breakI
default:
additional Q O S+nvalid username and password combinationTOI
breakI
P
42
P
%% clean up and show the user an error
Lmaster7age./et"rrorMessage2O!here was an error during sign in. 7lease check your
entries and try againO V additional4I
returnI
P
string redirect7ath Q string."mptyI
%% did we have a return pathW
if 2t#tReturn7ath.!e#t.5ength X G4
M
if 2hasAccepted!*4
M
redirect7ath Q t#tReturn7ath.!e#tI
P
else
M
redirect7ath Q Oacceptterms.asp#WredirectQO V t#tReturn7ath.!e#tI
P
P
else
M
if 2hasAccepted!*4
M
switch2resp.;ser/ession.efault/tart7age4
M
case *onnect*lass5ibrary.;ser./tart7ages.ashboard:
redirect7ath Q Ohome%dashboard.asp#OI
breakI
43
case *onnect*lass5ibrary.;ser./tart7ages.Welcome:
redirect7ath Q Ohome%startpage.asp#OI
breakI
P
P
else
M
redirect7ath Q Oacceptterms.asp#OI
P
P
Response.Redirect2redirect7ath4I
P
#eionHan5ler *la9
+nterface will get the values and it will pass the values to /ession data class for checking
the login information in database.
using /ystemI
namespace *onnect*lass5ibrary./essions
M
public interface +/ession1andler
M
string *reate/ession2int user+4I
bool oes"mailAddress"#ist2string email4I
bool oes/creen8ame"#ist2string screen8ame4I
*onnect*lass5ibrary./essions./ession :et/ession2string session+4I
bool +sJalid/ession2string session+4I
/ign+nResponse /ign+n2string username' string password4I
44
void /ign$ut2string session+4I
P
P
#eionDa+a *la9
+t will get the values from interface and it will encrypt the password and pass the values
to stored procedure ,signLin-
$nce it got the response' it will pass the success or error message to interface and interface will
pass the return value to button click event.
string +/essionata./ign+n2string username' string password4
M
/>l*onnection con Q new />l*onnection2Lconnection/tring4I
/>l*ommand cmd Q new />l*ommand2OsignLinO' con4I
cmd.*ommand!ype Q *ommand!ype./tored7rocedureI
cmd.7arameters.Add2new />l7arameter2OYusernameO' />lb!ype.Jar*har44I
cmd.7arametersSOYusernameOT.Jalue Q usernameI
cmd.7arameters.Add2new />l7arameter2OYpwdO' />lb!ype.Jar*har44I
cmd.7arametersSOYpwdOT.Jalue Q ;tility&unctions."ncrypt/tring2password4I
cmd.7arameters.Add2new />l7arameter2OYsessionLidO' />lb!ype.Jar*har' BG44I
cmd.7arametersSOYsessionLidOT.irection Q 7arameterirection.$utputI
cmd.7arameters.Add2new />l7arameter2OYutcLtimeO' />lb!ype.+nt44I
cmd.7arametersSOYutcLtimeOT.Jalue Q :enerate;ni#"poch24.!o/tring24./ubstring2G'
.G4I
try
M
con.$pen24I
45
cmd."#ecute8on9uery24I
return cmd.7arametersSOYsessionLidOT.Jalue.!o/tring24I
P
catch 2/>l"#ception err4
M
+"rror5og elog Q new "rror5og2Lconnection/tring4I
elog.5og/ystem"rror2err4I
throw new Application"#ception2Oata "rrorO' 2"#ception4err4I
P
finally
M
if 2con RQ null4
M
con.*lose24I
P
P
P
46
#i3nEIn #+ore5 pro*e56re9
*R"A!" 7R$*";R" SsignLinT

Yusername nvarchar2.BB4'
Ypwd nvarchar2@?4'
YutcLtime int'
YsessionLid varchar2BG4 $;!7;!

A/

)) check the session is valid ))
"*5AR" Y"rror int
"*5AR" YRow*ount int
"*5AR" YActual7assword nvarchar2@?4
"*5AR" Y!emp:;+ varchar2BG4
"*5AR" Y;ser+ int
"*5AR" Y+s5ocked bit
"*5AR" Y+sJalid bit
"*5AR" Y+sActive bit
"*5AR" Y5oginAttempts int
"*5AR" Y*reateate smalldatetime
"*5AR" Y"#pireate smalldatetime

/"5"*! Y!emp:;+ Q 5$W"R2R"75A*"28ew+24'Z)Z'ZZ44
/"5"*! Y*reateate Q :etate24
/"5"*! Y"#pireate Q A!"A2day'.A'Y*reateate4 )) set this for ? weeks 2.A days4 ))

+& 8$! "=+/!/2/"5"*! + &R$M ;sers W1"R" "mail Q Yusername4
6":+8
47
RA+/"RR$R2Z2.4 +nvalid username and password combinationZ'.C'.4
R"!;R8 .
"8

)) valid usernameW ))
/"5"*! Y;ser+ Q id'
YActual7assword Q password'
Y+s5ocked Q isLlocked'
Y+sJalid Q isLvalid'
Y5oginAttempts Q failedLloginLattempts
&R$M users
W1"R" email Q Yusername

/"5"*! Y"rror Q YY"RR$R' YRow*ount Q YYR$W*$;8!

+& Y"rror RQ G $R YRow*ount Q G
6":+8
RA+/"RR$R2Z2?4 +nvalid username%password combinationZ'.C'.4
R"!;R8 ?
"8

)) valid user accountW 2must be activated4 ))
+& Y+sJalid RQ .
6":+8
)) increment the login attempts ))
;7A!" users
/"! failedLloginLattempts Q failedLloginLattempts V .'
isLlocked Q .
W1"R" id Q Y;ser+

)) kick back an error ))
48
RA+/"RR$R2Z2C4 +nvalid username and password combinationZ'.C'.4
R"!;R8 C
"8

+& Y5oginAttempts X @
6":+8

)) increment the login attempts 2want to see how many times they attempted to login4 and lock
itR ))
;7A!" users
/"! failedLloginLattempts Q failedLloginLattempts V .'
isLlocked Q .
W1"R" id Q Y;ser+

)) kick back an error ))
RA+/"RR$R2Z2@4 !his user account is lockedZ'.C'.4
R"!;R8 @

"8

+& dbo.o7asswordsMatch2Ypwd'YActual7assword4 Q G
6":+8
)) increment the login attempts ))
;7A!" users
/"! failedLloginLattempts Q failedLloginLattempts V .
W1"R" id Q Y;ser+

)) kick back an error for incorrect passsword ))
RA+/"RR$R2Z2A4 +nvalid username and password combinationZ'.C'.4
R"!;R8 A
"8
49

)) user account lockedW ))
+& Y+s5ocked RQ G
6":+8
)) increment the login attempts ))
;7A!" users
/"! failedLloginLattempts Q failedLloginLattempts V .
W1"R" id Q Y;ser+

)) kick back an error ))
RA+/"RR$R2Z2B4 !his user account is locked.Z'.C'.4
R"!;R8 B
"8

)) go to here' everything must be ok' add a session ))
6":+8 !RA8/A*!+$8 trn/ign+n

+8/"R! +8!$ /essions2sessionLid'userLid'createLdate' e#pireLdate4
JA5;"/ 2Y!emp:;+'Y;ser+'Y*reateate'Y"#pireate4

/"5"*! Y"rror Q YY"RR$R' YRow*ount Q YYR$W*$;8!' YsessionLid Q
/*$7"L+"8!+![24

+& Y"rror RQ G $R YRow*ount Q G
6":+8
R$556A*( !RA8/A*!+$8 trn/ign+n
RA+/"RR$R2Z2D4 ;nable to create a session.Z'.C'.4
R"!;R8 D
"8

)) last step is to update the user account with last login date and zero the lock count ))
50
;7A!" users
/"! failedLloginLattempts Q G'
isLlocked Q G'
lastLloginLdate Q Y*reateate
W1"R" id Q Y;ser+

/"5"*! Y"rror Q YY"RR$R

+& Y"rror RQ G $R YRow*ount Q G
6":+8
R$556A*( !RA8/A*!+$8 trn/ign+n
RA+/"RR$R2Z2E4 ;nable to create a session.Z'.C'.4
R"!;R8 E
"8

*$MM+! !RA8/A*!+$8 trn/ign+n

)) send back the user session ))
/"5"*! YsessionLid Q Y!emp:;+

R"!;R8 G

51
Re3i+ra+ion Pa3e9
&ollowing code will e#plain how we implemented *A7!*1A in our site.
if 2Re>uest.9uery/tringSOcOT RQ null4
M
string id Q Re>uest.9uery/tringSOcOT.!o/tring24I
+*aptcha*ode1andler cch Q new *aptcha*ode1andler2new
*onnect*ontroller2*onnection/tring.Jalue44I
string s Q cch.:et*aptcha*ode2id4I
Response.*ontent!ype Q Oimage%3pegOI
Response.*lear24I
&ont f Q new &ont2O!imes 8ew RomanO' ?C' &ont/tyle.+talic \ &ont/tyle.6old'
:raphics;nit.7i#el4I
/tring&ormat format Q new /tring&ormat24I
format.Alignment Q /tringAlignment.*enterI
format.5ineAlignment Q /tringAlignment.*enterI
6itmap bmp Q new 6itmap2.?G' @B'
/ystem.rawing.+maging.7i#el&ormat.&ormat?AbppRgb4I
:raphics g Q :raphics.&rom+mage2bmp4I
g.*lear2*olor.White4I
g./moothingMode Q /ystem.rawing.rawing?./moothingMode.AntiAliasI
g.!e#tRendering1int Q /ystem.rawing.!e#t.!e#tRendering1int.AntiAliasI
g.raw/tring2s' f' 6rushes.6lack' new Rectangle&2G' G' bmp.Width' bmp.1eight4'
format4I
52
for 2int i Q )?I i N bmp.Width % .GI iVV4
M
g.raw5ine27ens.$rangeRed' i ] .G' G' i ] .G V ?G' bmp.1eight4I
P
for 2int i Q )?I i N bmp.Width % .G V .GI iVV4
M
g.raw5ine27ens.6lue' i ] .G' G' i ] .G ) CG' bmp.1eight4I
P
g.ispose24I
bmp./ave2Response.$utput/tream' /ystem.rawing.+maging.+mage&ormat.<peg4I
returnI
P
53
@.2 #CREEN #HOT#
!o3in Pa3e9
54
Re3i+ra+ion Pa3e9
55
Da0"oar5 pa3e9
56
Comm6ni+y A5min9
57
Up5a+e Profile9
58
%y !in-
59
Profile Pri1a*y #e++in3
60
P6"li* Vie. of +0e Profile
61
A55 ne. releae9
62
%y %e5ia !i"rary
63
Pri1a+e mea3e9
64
#ear*0 +0e Ne+.or-9
65
%y %ea3e9
66
Commen+9
67
%ana3e Blo39
RE2ERENCE#
68
16RZ/ .G Must Read $n Managing [ourself. 0++p9FF....+ra56.inF0"r-1G-m6+-
rea5-mana3in3-yo6relf.
Multimedia and web design. Author: Jikas :upta. http:%%www.simplybooks.in%comde#)
multimedia)web)design)vikas)gupta)book)isbn)UDEE.DD??U.UC)UCBAC.
.8et @.B 7rogramming: *overing .8et &ramework' J6 ?GGE' *K ?GGE' And A/7.8et @.B'
6lack 6ook. Author: (ogent 5earning /olutions +nc. http:%%www.tradus.in%net)@B)
programming)covering)net)framework)vb)?GGE)c)?GGE)and)aspnet)@B)black)book
/oftware "ngineering for +nternet Applications. Author: "ve Anderrson' 7hilip
:reenspun' and Andrew :rumet. http://ebookee.org/Software-Engineering-for-
Internet-Applications!"#!.html.
!he Art & /cience of Web esign. Author: <effrey veen. 8ew Riders ) ecember ?GGG.
0++p9FF.....e"referen*e.*omFa6+0orin3F5ei3nFar+*i.
eveloping effective websites: A pro3ect managerFs guide. Author: Roy /trauss' 7atrick
1ogan. www. coursehero. com% te#tbooks% @C?E@) eveloping) "ffective) Websites) A) )
7ro3ect) Managers) :uide .
esigning with web standards. Author: <effrey ^eldman. www. zeldman. com% dwws.
69