Help Desk Essay

Custom Student Mr. Teacher ENG 1001-04 31 March 2016

Help Desk

Project Abstract

The help desk provides users with the answers they need for their technical issue. By bringing Help Desk Process to the digital medium and onto computers, finding what you are looking for has never been easier.

Using a web-based Help Desk Process solves problems with expansion and usability over large geographic areas. It also allows field techs or even clients themselves to retrieve up to the minute information regarding their query. Modern Help Desk Process also provides a tracking system, to actively monitor a certain problem area.

COST AND EFFORT ESTIMATION

FUNCTION POINT MODEL
It is based on the visible features of the system that are weighed accordingly to produce an overall score. The intent is to construct a measure of product size that can be available easily in the development process. It is based on the notion of function points regarding as a measure of functionality of the system. The starting point of the construction of the model is to determine the number of items occurring in the system. The items are as follows:

External inputs are the inputs from the user that provide distinct application oriented data. Examples of such inputs are filenames and menu selections. External outputs are directed to the user, they come in the form of various reports and messages. User inquiries are interactive inputs requiring the response. External files deal with all machine readable interfaces on other systems. Internal files are the master files in the system.

These items are related differently according to their complexity that is given below in the following table. Item| Simple | Average| Complex|
External Inputs| 3| 4| 6|
External Outputs| 4| 5| 7|
User Inquiries| 3| 4| 6|
External files| 7| 10| 15|
Internal files| 5| 7| 10|

Here, first the Unadjusted Function Count (UFC) is determined using the formula
UFC = ∑itemi wi
In the second phase, refining the Function Point Count by including Technical Complexity Factor (TCF) and multiplying the value with UFC by using the formula determine Adjusted Function Point Count (FP): FP = UFC * TCF

Where TCF is calculated using the formula:
TCF = 0.65 + 0.1∑fi
Where if specifies the detailed factors contributing to the overall notion of complexity. The various factors are as follows-
* Reliable Backup and Recovery
* Distributed Functions
* Heavily used Configuration
* Operational Use
* Complex Interface
* Reusability
* Multiple sites
* Data Communications
* Performance
* Online Data Entry
* Online Update
* Complex Processing
* Installation Ease
* Facilitate Change
Here each factor is rated on 0 to 5 scales with 0 being irrelevant and 5 standing for essential. If al the factors are irrelevant then the constant 0.65 is used otherwise the constant 1.35 is used.

Considering the Data Automation System the items are as follows- External inputs – 37 (File no, Mineral Id, Mineral Name, Land Type, Location, GO
number, Year of join, Exp Year, Area, . . .) External outputs – 3 (Confirmation to Dorector, Confirmation to Data Entry Clerk, Test report) User inquiries – 5 (Availability of location, Validity of client, Selecting mine site, …..) External Files – (Client info files)

Internal Files – 7 (Minerals & User’s info files)
Considering the Data Automation System, we assume the complexity of all items to be average. So, UFC = (4*37) + (5*3) + (4*5) + (10*1) + (7*7)
= 148 + 15 + 20 + 10 + 49
=182
TCF = 0.65 + 0.1(5 + 0 + 0 + 5 + 1 + 1 + 0 + 3 + 0 + 0 + 1 + 2) = 2.45
Therefore FP = UFC*TCF
Software Recruitment Specification
Introduction:

The Advanced help desk software was created to deliver a professional help desk management product to service oriented companies. This software have been proven to make customer support up to 3 times faster with half the amount of man power at the same time ensuring the customers are billed correctly. Building up on all of the standard Help desk software available in the market this product achieves superior performance using advanced technologies like AJAX and SQL Server 2008.

Purpose:

It is internal project of a software company developed for the sake of Customer to get solved from his problem and also to get the feedback from the customer regarding the problems solution

Scope:
This system is an intranet based application can be used with in the organization.

Definition, Acronyms and Abbreviations

Term| Definition|
AHDA| Advanced Help Desk Automation|
UC| Use case|
NA| Not Applicable|
URD| Use case Requirement Document|
BRD| Business Requirement Document|
Software Development Methodology:
Research and Development

Once the Market Research is carried out, the customer’s need is given to the Research & Development division (R&D) to conceptualize a cost-effective system that could potentially solve the customer’s needs in a manner that is better than the one adopted by the competitors at present. Once the conceptual system is developed and tested in a hypothetical environment, the development team takes control of it. The development team adopts one of the software development methodologies that is given below, develops the proposed system, and gives it to the customer.

The Sales & Marketing division starts selling the software to the available customers and simultaneously works to develop a niche segment that could potentially buy the software. In addition, the division also passes the feedback from the customers to the developers and the R&D division to make possible value additions to the product.

While developing a software, the company out sources the non-core activities to other companies who specialize in those activities. This accelerates the software development process largely. Some companies work on tie-ups to bring out a highly matured product in a short period.

Popular Software Development Models
The following are some basic popular models that are adopted by many software development firms A. System Development Life Cycle (SDLC) Model

B. Prototyping Model

C. Rapid Application Development Model

D. Component Assembly Model

A. System Development Life Cycle (SDLC) Model

This is also known as Classic Life Cycle Model (or) Linear Sequential Model (or) Waterfall Method. This model has the following activities.

1. System/Information Engineering and Modeling

As software is always of a large system (or business), work begins by establishing the requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when the software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases, to extract the maximum output, the system should be re-engineered and spruced up. Once the ideal system is engineered or tuned, the development team studies the software requirement for the system.

2. Software Requirement Analysis

This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, target dates etc….

The requirement gathering process is intensified and focussed specially on software. To understand the nature of the program(s) to be built, the system engineer or “Analyst” must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and
to define the problem that needs to be solved .

3. System Analysis and Design

In this phase, the software development process, the software’s overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc… are all defined in this phase. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

4. Code Generation

The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc… are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.

5. Testing

Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available. Some companies build their own testing tools that are tailor made for their own development operations.

6. Maintenance

The software will definitely undergo change once it is delivered to the
customer. There can be many reasons for this change to occur. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.

System Analysis

Study of the system

The aim of the project is to develop interactive application for providing solution to the customer. Supervisor and Technician specially has to work out for this to solve the Customer problems and their needs. Then there is no waste of time of the Customer and cost effective to solve all the problems. The main goal of this is to design User friendly interactive application where customer can be registered themselves for their technical problems. Under these many employees are working to attend the customer requirements. The employees are such as Supervisor and Technician.

The aim of this project is to develop a graphical user interface this can be easily understood by the end users also. Through this we are developing a dynamic application that enables the problem register and developing solution for the registered problem of the customer. By this application we can reduce the risk of the customer.

There is graphical user interface is developed to interact with the Customer and solution developer. Through this every one can interact with the organization databases.

New user understandable formats are inserted into application. Through these contents users are interacting and registering the problems to the organizations.

The main goal of this system is to develop an application that helps reduce
the risk involved in getting the solution for the problem. The customer is interacting with automated system designed from the company. There is maximum reduction of time consumption and cost effectiveness while developing the solutions for the customer problems.

Problems in Existing system

Technicians and consultants will perform a full review of your service and help desk system at all of your locations. Technicians can add new screens to your service and help desk system and configure the existing screens based on ur particular needs. Our technicians will configure Auto Ticket Generation so that e-mails received by your service and help desk system will automatically create call records and trigger a process for assigning and escalation. When a ticket is created you can make sure it gets assigned to the right person. Often, our clients have data that needs to be exported from one source and imported into your service and help desk system. We can design custom application to move data from one place to the other either in batch or in real time. Our consultants can recommend and specify the best type of integration for you and test the work done by our visual basic programmers. We do our best to ensure that our clients are not doing repetitive work. .

Proposed System

Achieving and maintaining a successful Help Desk operation can depend on a number of pre-requisites that need to be in place. These components have been identified from surveys covering a wide range of help desk facilities.

Set clear, realistic and quantifiable goals and objectives

Understand your customer requirements and carefully plan the Help Desk structure.

Establish and implement secure, practical and cost effective policies.

Ensure adequate staffing levels.

Provide ongoing comprehensive training to all levels of management and staff. Communication skills must be developed to a very high degree together with an understanding of the technical issues involved with the delivery of the organization’s products and services.

Automation of the help desk operations should be maximized but care must be taken to ensure that this is one on a cost effective basis.

Manage and monitor service level performance trough service level agreements. Control potential problem areas through effective change management procedures. The main goal of problem management is in the detection of the underlying reasons for a particular incident and the resolution and prevention of future reoccurrence of that incident through problem elimination.

Hold regular service review meetings.
Requirement Specification:

Functional Requirements:

* The system should have a provision for the Customer to contact the help desk by phone/email. * System should have a facility to track the phone and electronic message traffic to generate a trouble ticket with unique id. * The system should have an option for the customer to track the status. * The system should provide a facility to the customer to give the feedback. * System should have a provision for the Consultants to access the knowledgebase which details problems and solution. * System should have a facility for the Consultants/Administrator to view all the tickets by date * The system should facilitate the Consultants to add notes on all the work done on the issue

* The system should provide an option for the Consultants to reach the customer through mail regarding solution to the problem/statues. * The system should have a provision for the Administrator to add/update/delete the Consultants * System should have an potion for the Administrator to generate reports regarding number of calls logged/closed, percent of calls closed.

Non-Functional Requirements:

* The users of the system should be provided user id and password along with the well defined access privileges. * 24X7 internet connectivity should be provided for well functioning of the system. * Systems should be provided with proper backup media and resources to handle system crash scenarios.

FEASIBILITY STUDY

Feasibility Study Introduction:
Preliminary investigation examines project feasibility; the likelihood the system will be useful to the organization. The main objective of the feasibility study is to test the Technical, Operational and Economical feasibility for adding new modules and debugging old running system. All systems are feasible if they are given unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary investigation:

* Technical Feasibility
* Operation Feasibility
* Economical Feasibility

TECHNICAL FEASIBILITY:

Evaluating the technical feasibility is the trickiest part of a feasibility study. This is because, at this point in time, not too many detailed design of the system, making it difficult to access issues like performance, costs on (on account of the kind of technology to be deployed) etc. A number of issues have to be considered while doing a technical analysis.

Understand the different technologies involved in the proposed system:
Before commencing the project, we have to be very clear about what are the technologies that are to be required for the development of the new system.

Find out whether the organization currently possesses the required technologies:
Is the required technology available with the organization? If so is the capacity sufficient?

For instance- “Will the current printer be able to handle the new reports and forms required fort the new system?”

* The technical issue usually raised during the feasibility stage of the investigation includes the following:

* Does the necessary technology exist to do what is suggested?

* Do the proposed equipments have the technical capacity to hold the data required to use the new system?

* Will the proposed system provide adequate response to inquiries, regardless of the number or location of users?

* Can the system be upgraded if developed?

OPERATIONAL FEASIBILITY
Proposed projects are beneficial only if they can be turned into information systems that will meet the organizations operating requirements. Simply stated, this test of feasibility asks if the system will work when it is developed and installed. Are there major barriers to implementation? Here are questions that will help test the operational feasibility of a project.

Is there sufficient support for the project from management from users? If the current system is well liked and used to the extent that persons will not be able to see reasons for change, there may be resistance.

Are the current business methods acceptable to the user? If they are not, Users may welcome a change that will bring about a more operational and useful systems.

Have the user been involved in the planning and development of the project? Early involvement reduces the chances of resistance to the system and in general and increases the likelihood of successful project.

Since the proposed system was to help reduce the hardships encountered. In the existing manual system, the new system was considered to be operational feasible.

User-friendly
Customer will use the forms for their various transactions i.e. for adding new routes, viewing the routes details. Also the Customer wants the reports to view the various transactions based on the constraints. Theses forms and reports are generated as user-friendly to the Client.

Reliability
The package wills pick-up current transactions on line. Regarding the old transactions, User will enter them in to the system.

Security
The web server and database server should be protected from hacking, virus etc

Portability
The application will be developed using standard open source software (Except Oracle) like Java, tomcat web server, Internet Explorer Browser etc these software will work both on Windows and Linux o/s. Hence portability problems will not arise.

Maintainability

The system called the ewheelz uses the 2-tier architecture. The 1st tier is
the GUI, which is said to be front-end and the 2nd tier is the database, which uses My-Sql, which is the back-end.

The front-end can be run on different systems (clients). The database will be running at the server. Users access these forms by using the user-ids and the passwords.

ECONOMIC FEASIBILITY:
Economic feasibility attempts to weights the costs of developing and implementing a new system, against the benefits that would accrue from having the new system in place. This feasibility study gives the top management the economic justification for the new system.

A simple economic analysis which gives the actual comparison of costs and benefits are much more meaningful in this case. In addition this provides to be a useful point of reference to compare actual costs as the project progresses. There could include increased client satisfaction, improvement in product quality better decision making timeliness of information, expediting activities, improved accuracy of operations, better documentation and record keeping, faster retrieval of information, better employee morale.

The computerized system takes care of the present existing system’s data flow and procedures completely and should generate all the reports of the manual system besides a host of other management reports. It should be built as a web based application with separate web server and database server. This is required as the activities are spread through out the organization customer wants a centralized database. Further some of the linked transactions take place in different locations.

Open source software like .Net, JAVA, Mysql and Linux is used to minimize the cost for the Customer. Environmental Details
Software:

Technology : ASP.NET with Ajax
Programming Language : C#.NET
Database : SQL Server.
Modeling Language: Rational Rose (UML).
Application Server: IIS (Internet Information Server)

Hardware:

* Pentium IV processor
* 1 GB RAM
* 80GB HDD
URD (USER REQUIREMENT DOCUMENT)

DATA FLOW DIAGRAMS

Context level diagrams

Top Level 1 Diagrams:

Top Level 2 Diagrams:

USE CASE DIAGRAMS

Customer Use Case Diagram

Supervisor Module Use Case Diagram

Technician Module Use Case Diagram

Administrator Module Use Case Diagram

Look Up Table

S.No| Requirement ID| Requirement Name| Actors| Stable (Y/N)| Priority| Need| Verifiable (y/n)| 1| AHDA_UC_ADM_01| View Customer Details| Administrator , Customer| Y| High| Essential| Y| 2| AHDA_UC_ADM_02| Add Customer Details| Administrator, Customer| Y| High| Essential| Y| 3| AHDA_UC_ADM_03| Update Customer Details| Administrator, Customer| Y| High| Essential| Y| 4| AHDA_UC_ADM_04| Delete Customer Details| Administrator, Customer| Y| High| Essential| Y| 5| AHDA_UC_ADM_05| View Supervisor Details| Administrator, Supervisor| Y| High| Essential| Y| 6|

AHDA_UC_ADM_06| Add Supervisor Details| Administrator, Supervisor| Y| High| Essential| Y| 7| AHDA_UC_ADM_07| Update Supervisor Details| Administrator, Supervisor| Y| High| Essential| Y| 8| AHDA_UC_ADM_08| Delete Supervisor Details| Administrator, Supervisor| Y| High| Essential| Y| 9| AHDA_UC_ADM_09| View Technician Details| Administrator, Technician| Y| High| Essential| Y| 10| AHDA_UC_ADM_10| Add Technician Details| Administrator, Technician| Y| High| Essential| Y| 11| AHDA_UC_ADM_11| Update Technician Details| Administrator, Technician| Y| High| Essential| Y| 12| AHDA_UC_ADM_12| Delete Technician Details| Administrator, Technician| Y| High| Essential| Y| 13|

AHDA_UC_CUS_13| Log in| Customer| Y| High| Essential| Y| 14| AHDA_UC_CUS_14| Registration| Customer| Y| High| Essential| Y| 15| AHDA_UC_CUS_15| Logged Complaints| Customer| Y| High| Essential| Y| 16| AHDA_UC_CUS_16| Status of Complaint| Customer| Y| High| Essential| Y| 17| AHDA_UC_CUS_17| Feedback of the Complaint| Customer| Y| High| Essential| Y| 18| AHDA_UC_SUP_18| View Complaints| Supervisor| Y| High| Essential| Y| 19| AHDA_UC_SUP_19| Forward Complaints to Customer| Supervisor| Y| High| Essential| Y| 20| AHDA_UC_SUP_20| View Solution Regarding Problem| Supervisor| Y| High| Essential| Y| 21| AHDA_UC_SUP_21| Post Solutions to Customer| Supervisor| Y| High| Essential| Y| 22| AHDA_UC_TEC_22| View Complaints | Technician | Y| High| Essential| Y| 23| AHDA_UC_TEC_23| Forward Solution| Technician| Y| High| Essential| Y|

URD (User Requirement Document)

Module: Admin
Use case: Manages Customer Details _ View

Requirement ID| AHDA_Administrator_UC_01_View|
Module Name| Administrator Module|
Use Case Name| Manage Customer Details _View|
Use Case Description| Here using the use case the administrator view the Customer Details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —–NA—–|
Basic Flow| 1. Admin should login 2. view the customer details 3.1 enter customer id 3.2 enter customer name 3. Click on submit button 4. View the details of Customer| Input| Customer idCustomer name|

Output| —–NA—–|
Alternate Flow| 1. if the given customer id is not valid then it should ask for reenter| Special Instructions| Customer id should be exist |

Module: Administrator
Use case: Manages Customer Details_ Add

Requirement ID| AHDA_Administrator_UC_01_Add|
Module Name| Administrator Module|
Use Case Name| Manage Customer Details _Add|
Use Case Description| Here using the use case the administrator can add new Customer Details to administrator| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —–NA—–|
Basic Flow| 1. Admin should login 2. view the customer details a. Enter customer id b. Enter customer name c. Contact number d. Address e. Email id f. Problem id 3. Click on submit button| Input| Customer idCustomer nameContact numberCustomer AddressCustomer Email idCustomer Problem id| Output| —–NA—–|

Alternate Flow| 1. Verify the entered problem is valid or not| Special
Instructions| —–NA—–|

Module: Administrator
Use case: Manages Customer Details _Update

Requirement ID| AHDA_Administrator_UC_01_ Update|
Module Name| Administrator Module|
Use Case Name| Manage Customer Details _Update|
Use Case Description| Here using the use case the administrator will Update the Customer Details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| 1. Administrator should login2. Customer Should exist| Post Condition| —–NA—–|
Basic Flow| 1. Administrator login to the system 2. Customer update the details g. customer id h. customer name 4. customer click on submit button 5. customer gets the validation acknowledgement| Input| 1. Customer id2. Customer name|

Output| —–NA—–|
Alternate Flow| 1. customer entered user id and password is not valid then it has to login again with proper details| Special Instructions| 1. Customer id should valid 2. Password should be correct |

Module: Administrator
Use case: Manages Customer Details _ Delete

Requirement ID| AHDA_Administrator_UC_01_Delete|
Module Name| Administrator Module|
Use Case Name| Manage Customer Details_ Delete|
Use Case Description| Here using the use case the administrator will Manage Customer Details| Primary Actor| Customer|
Use Case Diagram| |
Pre Condition| 1. Administrator should Login2. Customer Should exist| Post Condition| —–NA—–|
Basic Flow| 1. Administrator login to the system 2. customer delete
from the system2.1 customer id 3. click on submit button| Input| Customer id|
Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| Customer id should valid|

Module: Administrator
Use Case: Manages Supervisory Details_ View

Requirement ID| AHDA_Administrator_UC_02_View|
Module Name| Administrator Module|
Use Case Name| Manage Supervisor details _View|
Use Case Description| Here using the use case the administrator can view the Supervisor details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —–NA—–|
Basic Flow| 1. Admin should login 2. Admin view the Supervisor Details 3.1 Enter empid 3.2 Enter empnameclick on submit button| Input| Supervisor id Supervisor name|
Output| |
Alternate Flow| if given id is not then reenter again valid id| Special Instructions| 1. Id should be exist|

Module: Administrator
Use Case: Manages Supervisory Details_ Add

Requirement ID| AHDA_Administrator_UC_02_ Add|
Module Name| Administrator Module|
Use Case Name| Manage Supervisor details_ Add|
Use Case Description| Here using the use case the administrator will Add the Supervisor details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —————–Not Applicable———————|
Basic Flow| 1. Admin should login 2. Admin add the Supervisor 3.1 Enter id 3.2 Enter name 3.3 Enter contact 3.4 Email id 3.5 Enter address 3.6 Select city 3.7 Select state 3.8 Select country 3.9 Enter department id 3.10 Select location of branch 3. click on submit button| Input| Supervisor details|

Output| —–NA—–|
Alternate Flow| 1. If any of the field is not filled or not valid then the form reloads again| Special Instructions| |

Module: Administrator
Use Case: Manages Supervisory Details_ Update

Requirement ID| AHDA_Administrator_UC_02_ Update|
Module Name| Administrator Module|
Use Case Name| Manage Supervisor details_ Update|
Use Case Description| Here using the use case the administrator will Manage Supervisor details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —————–Not Applicable———————| Basic Flow| 1. Admin should login 2. Admin update the supervisor details a. Enter supervisor id b. Enter supervisor name 3. click on submit button| Input| Supervisor idName of the supervisor |

Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| —–NA—–|

Module: Administrator
Use Case: Manages Supervisory Details_ Delete

Requirement ID| AHDA_Administrator_UC_02_ Delete|
Module Name| Administrator Module|
Use Case Name| Manage Supervisor details_ Delete|
Use Case Description| Here using the use case the administrator will Manage Supervisor details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —————–Not Applicable———————| Basic Flow| 1. Admin should login 2. Admin view the Supervisor a. Enter supervisor id b. Enter supervisor name 3. click on submit button| Input| Supervisor idSupervisor name|

Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| The supervisor should be exist|

Module: Administrator
Use Case: Manages Technician Details _View

Requirement ID| AHDA_Administrator_UC_03_View|
Module Name| Administrator Module|
Use Case Name| Manage Technician details _View|
Use Case Description| Here using the use case the administrator can view the Technician details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —————–Not Applicable———————| Basic Flow| 1. Admin should login 3. Admin view the Technician Details 4.1 Enter Technician id 3.3 Enter Technician nameclick on submit button| Input| Technician id Technician name|

Output| —–NA—–|
Alternate Flow| if given id is not then reenter again valid id| Special Instructions| 1. Id should be exist|

Module: Administrator
Use Case: Manages Technician Details_ Add

Requirement ID| AHDA_Administrator_UC_03_ Add|
Module Name| Administrator Module|
Use Case Name| Manage Technician details_ Add|
Use Case Description| Here using the use case the administrator will Add the Technician details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —————–Not Applicable———————| Basic Flow| 1. Admin should login 2. Admin add the Technician2.1Enter id 3.2 Enter name 3.3 Enter contact 3.4 Email id 3.5 Enter address 3.6 Select city 3.7 Select state 3.8 Select country 3.9 Enter department id 3.10 Select location of branch 3. click on submit button| Input| Technician details|

Output| —–NA—–|
Alternate Flow| 1. If any of the field is not filled or not valid then the form reloads again| Special Instructions| Valid email id should enter|

Module: Administrator
Use Case: Manages Technician Details_ Update

Requirement ID| AHDA_Administrator_UC_03_ Update|
Module Name| Administrator Module|
Use Case Name| Manage Technician details_ Update|
Use Case Description| Here using the use case the administrator will Manage Technician details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —————–Not Applicable———————| Basic Flow| 1. Admin should login 4. Admin update the Technician details c. Enter Technician id d. Enter Technician name 5. click on submit button| Input| Technician idName of the Technician|

Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| —–NA—–|

Module: Administrator
Use Case: Manages Technician Details_ Delete

Requirement ID| AHDA_Administrator_UC_03_ Delete|
Module Name| Administrator Module|
Use Case Name| Manage Technician details_ Delete|
Use Case Description| Here using the use case the administrator will Manage Technician details| Primary Actor| Administrator|
Use Case Diagram| |
Pre Condition| Admin should login|
Post Condition| —–NA—–|
Basic Flow| 1. Admin should login 4. Admin view the Technician c. Enter Technician id d. Enter Technician name 5. click on submit button| Input| Technician idTechnician name|

Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| The Technician should be exist|

Module: Customer
Use case: Log in

Requirement ID| AHDA_ Customer _UC_01|
Module Name| Customer Module|
Use Case Name| Log in|
Use Case Description| This use case describes new customer Log in to the system| Primary Actor| Customer|
Use Case Diagram| |
Pre Condition| 1. The customer enter to the organization site| Post Condition| |
Basic Flow| 1. Enter to the organization site 2. Enter user id 3. Enter password| Input| User id Password|
Output| —–NA—–|
Alternate Flow| If valid user id and password is not entered again it asks for the re-entry | Special Instructions| User id should be valid Password should enter correct|

Module: Customer
Use case name: Registration

Requirement ID| AHDA_Customer_UC_02|
Module Name| Customer Module|
Use Case Name| Registration|
Use Case Description| This use case describes the registration of new customer| Primary Actor| Customer|
Use Case Diagram| |
Pre Condition| Customer clicks the sign up link |
Post Condition| Customer enters into complaints log in page| Basic Flow| 1. clicks on sign up link 2. Registration of customer 3.1 Enter customer id 3.2 Enter customer name 3.3 Enter customer contact number 3.4 Enter customer address 3.5 Select password 3.6 Enter mail id 3.7 Select city 3.8 Select state 3.9 Select country 3. Click on submit button 4. Receive successful registration acknowledgement from organization | Input| Customer details|

Output| |
Alternate Flow| Customer mail id entered should be valid If not enter again | Special Instructions| Valid customer mail id|

Module: Customer
Use case: Logged Complaints

Requirement ID| AHDA_ Customer _UC_03|
Module Name| Customer Module|
Use Case Name| Logged Complaints|
Use Case Description| This use case describes complaints submitted by the customer| Primary Actor| Customer|
Use Case Diagram| |
Pre Condition| 1. The customer log in to the system |
Post Condition| Complaint registered to administrator|
Basic Flow| 1. Customer log in to the system 2. Customer enters the complaint 3.1 Complaint id 3.2 Complaint description 3. Click submit button 4. Receive acknowledgement| Input| 1. Complaint id 2. Complaint description | Output| Successfully complaint accepted acknowledgement | Alternate Flow| 1. If the complaint is not valid then it can be rejected| Special Instructions| —–NA—–|

Module: Customer
Use case: Status of Complaint

Requirement ID| AHDA_ Customer _UC_04|
Module Name| Customer Module|
Use Case Name| Status of Complaint|
Use Case Description| This use case shows the status of the complaint| Primary Actor| Customer|
Use Case Diagram| |
Pre Condition| Post the complaint|
Post Condition| |
Basic Flow| 1. Complaint status 2.1 Selected 2.2 Rejected| Input| —–NA—–|
Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| —–NA—–|

Module: Customer
Use case: Feedback of the Complaint

Requirement ID| AHDA_Customer_UC_05|
Module Name| Customer Module|
Use Case Name| Feedback of The Complaint|
Use Case Description| This use case used to describe the customer satisfaction status| Primary Actor| Customer|
Use Case Diagram| |
Pre Condition| Customer should receive solution for a problem| Post Condition| —–NA—–|
Basic Flow| 1. Solution received by customer1.1 Feedback about solution| Input| —–NA—–|
Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| —–NA—–|

Module: Supervisor
Use case: View Complaints

Requirement ID| AHDA_Supervisor_UC_01|
Module Name| Supervisor Module|
Use Case Name| View Complaints|
Use Case Description| This use case used to view the details of the customer complaints.| Primary Actor| Supervisor|
Use Case Diagram| |
Pre Condition| Supervisor should login |
Post Condition| —–NA—–|
Basic Flow| 1. Supervisor view complaints 2.1 complaint id 2.2 complaint description| Input| —–NA—–|
Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| —–NA—–|

Module: Supervisor
Use Case: Forward Complaints to Technician

Requirement ID| AHDA_ Supervisor _UC_02|
Module Name| Supervisor Module|
Use Case Name| Forward Complaints to Technician|
Use Case Description| Here using the use case the Supervisor forward customer complaints to appropriate technician.| Primary Actor| Supervisor|
Use Case Diagram| |
Pre Condition| 1. Complaint should be valid or selected| Post Condition| Technician post solution of complaint|
Basic Flow| 1. Complaint checked by supervisor 2.1 forward complaint to technician 2.2 technician id 2.3 technician name 2.4 technician branch location 2. forward compliant to technician| Input| 1. Technician id2. Technician name3. Technician location| Output| —–NA—–|

Alternate Flow| —–NA—–|
Special Instructions| —–NA—–|

Module: Supervisor
Use case: View Solutions Regarding Problem

Requirement ID| AHDA_ Supervisor _UC_03|
Module Name| Supervisor Module|
Use Case Name| View Solutions |
Use Case Description| Here using the use case the customer can have solution to their problem| Primary Actor| Supervisor|
Use Case Diagram| |
Pre Condition| 1. Problem should valid|
Post Condition| |
Basic Flow| 1. Solution to the given complaint 2.1 complaint id 2.2 complaint description 2. View solution to given problem| Input| —–NA—–|
Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| —–NA—–|

Module: Supervisor
Use case: Post Solutions to Customer

Requirement ID| AHDA_Customer_UC_04|
Module Name| Supervisor Module|
Use Case Name| Post solutions to customer|
Use Case Description| This use case describes the solutions of customer complaints.| Primary Actor| Supervisor|
Use Case Diagram| |
Pre Condition| Customer problem should be valid |
Post Condition| Customer receives the solution|
Basic Flow| 1. Solution to the given problem 2. Forward solution to the customer 3.1 customer id 3.2 customer name 3. clicks on submit button 4. Feedback of successfully send acknowledgement. | Input| Customer idCustomer name|

Output| Solution forwarded to a customer|
Alternate Flow| If the customer id is not valid it should ask for reenter the customer id.| Special Instructions| 1. Problem should be valid.2. Customer should exist.|

Module: Technician
Use case: View Complaints

Requirement ID| AHDA_Techinican_UC_01|
Module Name| Technician Module|
Use Case Name| View Complaints|
Use Case Description| Using this use case technician view the complaint details| Primary Actor| Technician |
Use Case Diagram| |
Pre Condition| Supervisor should send the complaints|
Post Condition| —–NA—–|
Basic Flow| 1. Receive the complaints 2. View the complaints2.1 complaint id2.2 complaint description| Input| —–NA—–|
Output| —–NA—–|
Alternate Flow| —–NA—–|
Special Instructions| —–NA—–|

Module: Technician
Use case: Forward Solution

Requirement ID| AHDA_Technician_UC_02|
Module Name| Technician Module|
Use Case Name| Forward Solution|
Use Case Description| This use case is used to forward solution of complaints to the supervisor| Primary Actor| Technician|
Use Case Diagram| |
Pre Condition| Find solution|
Post Condition| Solution forward to customer|
Basic Flow| 1. Complaint details 2.1 Complaint id 2.2 Complaint description 2. forward solution to supervisor2.1 Click on submit button| Input| Solution of given complaint|
Output| —–NA—–|
Alternate Flow| Solution should be for the existed complaint.| Special Instructions| Solution should send to the supervisor.|

Activity Diagrams

Actor: Customer
Use case: Login

Actor: Customer
Use case: Register

Actor: Customer
Use case: Logged Complaints

Actor: Customer
Use case: Status complaint

Actor: Customer
Use case: Feedback of customer

Actor: Administrator
Use case: Manages the customer details

Actor: Administrator
Use case: Manage Supervisor Details

Actor: Administrator
Use case: Manage Technician Details

Actor: Supervisor
Use case: View Complaints

Actor: Supervisor
Use case: Forward Complaints to technician

Actor: Supervisor
Use case: View Solutions

Actor: Supervisor
Use case: Forward Solution to Customer

Actor: Technician
Use case: View complaints logged by customer

Actor: Technician
Use case: Forward Solution to supervisor

System Design

Sequence & Collaboration Diagrams

Admin: View Customer Details

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_PE_01|
Requirement ID| AHDA_Admin_UC_01|
Actor| Admin|
Business Logic| 1.Enter into website2.click on sign in link 2.1 View customer details 2.2 update customer details 2.2 delete customer details| Client side validation| Enter a valid website and clicks on the link| Server side validation| Required link page should provide.|

Admin: View Supervisor Details

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_Admin_02|
Requirement ID| AHDA_Admin_UC_02|
Actor| Admin|
Business Logic| 1.Enter into website2.click on sign in link 2.1 View Supervisor details 2.2 update Supervisor details 2.2 delete Supervisor details| Client side validation| Enter a valid website and clicks on the link| Server side validation| Required link page should provide .|

Admin: View Technician Details
Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_Admin_03|
Requirement ID| AHDA_Admin_UC_02|
Actor| Admin|
Business Logic| 1.Enter into website2.click on sign in link 2.1 View Technician details 2.2 update Technician details 2.2 delete Technician details| Client side validation| Enter a valid website and clicks on the link| Server side validation| Required link page should provide .|

Customer: Register

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _04|
Requirement ID| AHDA_Customer_UC_02|
Actor| Customer|
Business Logic| 1.Enter into website2.click on Registration link 2.1 Enter user name 2.2 Enter password 2.3 Enter confirm password 2.4 Enter e-mail id 2.5 Enter contact number 2.6 Enter full address3. Clicks on submit button| Client side validation| Enter a valid User name,Password should be more than 6 charactersConfirm password should match with PasswordValid e-mail id should be enteredNo fields should be left empty| Server side validation| Checks whether the user entered the fields correctlyChecks whether all fields are entered Required link page should provide.|

Customer: Login

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _05|
Requirement ID| AHDA_Customer_UC_02|
Actor| Customer|
Business Logic| 1.Enter into website2.click on Login link 2.1 Enter user name 2.2 Enter password3. Clicks on Sign in button| Client side validation| Enter a valid User name,Enter a valid Password| Server side validation| Checks whether the user entered the fields correctlyRequired link page should provide.|

Customer: Logged Complaints

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _06|
Requirement ID| AHDA_Customer_UC_02|
Actor| Customer|
Business Logic| 1. Customer login to Help Desk2. Clicks on complaint page3. Enters the fields which are mandatory| Client side validation| The description field should not be left empty| Server side validation| Checks whether the description entered is valid or notGenerates the complaint id automatically|

Customer: Status of complaint

Sequence Diagram:

Collaboration Diagram:

Customer: Feedback
Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _07|
Requirement ID| AHDA_Customer_UC_02|
Actor| Customer|
Business Logic| 1. Customer login to Help Desk2. Clicks on feed back page 2.1 Enter Customer id 2.2 Enter Complaint id 2.2 Enter Customer name3. Clicks on Feedback button| Client side validation| The Customer id, name, Complaint id must be valid and the fields should not be left empty| Server side validation| Checks whether the fields entered are validDisplays the feedback of the Logged Complaint|

Supervisor: View complaints

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _08|
Requirement ID| AHDA_Customer_UC_02|
Actor| Supervisor|
Business Logic| 1. Supervisor login to Help Desk2. Supervisor gets the list of complaints logged3. Supervisor has access to view the complaints| Client side validation| —-NA—-|
Server side validation| —-NA—-|

Supervisor: Forward complaints
Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _08|
Requirement ID| AHDA_Customer_UC_02|
Actor| Supervisor|
Business Logic| 1. Supervisor login to Help Desk2. Supervisor gets the list of complaints logged3. Supervisor has access to view the complaints4. Supervisor forward the complaints to Technician according to categories| Client side validation| Checks for Technician |

Server side validation| Checks whether the Technician exist or not|

Supervisor: View Solution

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _09|
Requirement ID| AHDA_Customer_UC_02|
Actor| Supervisor|
Business Logic| 1. Supervisor login to Help Desk2. Supervisor forward the complaints to Technician according to categories3. Technician studies the complaint 4. Technician finds and forward the solution to Supervisor5. Supervisor receives the solution| Client side validation| The Supervisor should loginThe Supervisor should receive the solution | Server side validation| —-NA—-|

Supervisor: Post Solution to Customer

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _10|
Requirement ID| AHDA_Customer_UC_02|
Actor| Supervisor|
Business Logic| 1. Supervisor login to Help Desk2. Supervisor receives the solution from Technician3. Post the solution to the customer with complaint id| Client side validation| The complaint id, Customer id, name should be valid| Server side validation| Checks for the validity of Complaint id, Customer id, name |

Technician: View Complaints

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _11|
Requirement ID| AHDA_Customer_UC_02|
Actor| Technician|
Business Logic| 1. Technician login to Help Desk2. Technician gets the list of complaints logged3. Technician has access to view the complaints| Client side validation| —-NA—-|
Server side validation| —-NA—-|

Technician: Post Solution to Supervisor

Sequence Diagram:

Collaboration Diagram:

System Features Id| SF_AHDA_ Customer _12|
Requirement ID| AHDA_Customer_UC_02|
Actor| Technician|
Business Logic| 1. Technician login to Help Desk2. Post the solution to the Supervisor| Client side validation| Checks for the Supervisor|
Server side validation| Checks whether the Supervisor exist or not|

Data Dictionary

LOGIN TABLE

S.No| Column| Data Type| Constraints| Remarks|
1| Login| Varchar(50)| Foreign Key| |
2| Password| Varchar(50)| Not Null| |
3| Role| Varchar(50)| Not Null| |

CUSTOMER TABLE

S.No| Column| Data Type| Constraints| Remarks|
1| C id| Varchar(50)| Primary Key| |
2| Name| Varchar(50)| Not Null| |
3| Contact Number-1| Varchar(50)| Not Null| |
4| Contact Number-2| Varchar(50)| Not Null| |
5| Address| Varchar(50)| Not Null| |
6| City| Varchar(50)| Not Null| |
7| State| Varchar(50)| Not Null| |
8| Country| Varchar(50)| Not Null| |
9| E-mail| Varchar(50)| Unique| |

SUPERVISOR TABLE

S.No| Column| Data Type| Constraints| Remarks|
1| S id| Varchar(50)| Primary Key| |
2| Name| Varchar(50)| Not Null| |
3| Address| Number(15)| Not Null| |
4| Contact Number| Varchar(50)| Not Null| |
5| Designation| Varchar(50)| Not Null| |
6| Department Id| Varchar(50)| Foreign Key| |
7| Branch Location| Varchar(50)| Not Null| |
8| E-mail| Varchar(50)| Unique| |
9| T id| Varchar(50)| Foreign Key| |

TECHNICIAN TABLE

S.No| Column| Data Type| Constraints| Remarks|
1| T id| Varchar(50)| Primary Key| |
2| Name| Varchar(50)| Not Null| |
3| Address| Number(15)| Not Null| |
4| Contact Number| Varchar(50)| Not Null| |
5| Designation| Varchar(50)| Not Null| |
6| Department Id| Varchar(50)| Foreign Key| |
7| Branch Location| Varchar(50)| Not Null| |
8| E-mail| Varchar(50)| Unique| |
9| Sid| Varchar(50)| Foreign Key| |

COMPLAINT TABLE

S.No| Column| Data Type| Constraints| Remarks|
1| Complaint Id| Varchar(50)| Unique| |
2| Description| Varchar(500)| Not Null| |
3| Title| Varchar(50)| Not Null| |
4| Status| Varchar(50)| Not Null| |
5| Received Date| Date Time| Not Null| |
6| Submitted Date| Date Time| Not Null| |
7| Customer Id| Varchar(50)| Foreign Key| |

FEEDBACK TABLE

S.No| Column| Data Type| Constraints| Remarks|
1| Complaint Id| Varchar(50)| Unique| |
2| Complaint Title| Varchar(50)| Not Null| |
3| Customer Id| Varchar(50)| Not Null| |
4| Customer Name| Varchar(50)| Not Null| |
5| Feed Back| Varchar(500)| Not Null | |
6| Date Time| Date Time| Not Null| |

Component Diagram

Class Diagrams

User Interface Design

Home page

Register Page

Contact Us

Feed Back Page

Executive Brief Page

Categories

Product Guide Lines

Tips for Success

Things to Avoid

Coding

.NET Framework

The Microsoft.NET strategy was presented by Microsoft officials to the rest of the world in June 2000:

* .NET is Microsoft’s new Internet and Web strategy
* .NET is NOT a new operating system
* .NET is a new Internet and Web based infrastructure
* .NET delivers software as Web Services
* .NET is a framework for universal services
* .NET is a server centric computing model
* .NET will run in any browser on any platform
* .NET is based on the newest Web standards

.NET Internet Standards

.NET is built on the following Internet standards:

* HTTP, the communication protocol between Internet Applications * XML, the format for exchanging data between Internet Applications * SOAP, the standard format for requesting Web Services

* UDDI, the standard to search and discover Web Services

.NET Framework

* The .NET Framework is the infrastructure for the new Microsoft .NET
Platform.

* The .NET Framework is a common environment for building, deploying, and running Web Services and Web Applications.

* The .NET Framework contains common class libraries – like ADO.NET, ASP.NET and Windows Forms – to provide advanced standard services that can be integrated into a variety of computer systems.

* The .NET Framework is language neutral. Currently it supports C++, C#, Visual Basic, and JScript (The Microsoft version of JavaScript). Third-party languages like COBOL, Eiffel, Perl, Python, Smalltalk, and others – will also be available for building future .NET Framework applications. The new Visual Studio.NET is a common development environment for the new .NET Framework. It provides a feature-rich application execution environment, simplified development and easy integration between a numbers of different development languages.

Active Server Pages – ASP.NET

ASP.NET is the latest version of ASP. It includes Web Services to link Applications, services and devices using HTTP, HTML, XML and SOAP.

New in ASP.NET:

* New Language Support
* Programmable Controls
* Event Driven Programming
* XML Based Components
* User Authentication
* User Accounts and Roles
* High Scalability
* Compiled Code
* Easy Configuration
* Easy Deployment
* Not ASP Compatible
* Includes ADO.NET

SQL Server 2000
SQL Server 2000 is a fully web-enabled database.
SQL Server 2000 has strong support for XML and HTTP which are two of the main infrastructure technologies for .NET. Some of the most important new SQL Server features are direct access to the database from a browser, query of relational data with results returned as XML, as well as storage of XML in relational formats.

Internet Information Server 6.0
IIS 6.0 has strong support for more programming to take place on the server, to Allow the new Web Applications to run in any browser on any platform.

.NET Web Services:
Web services are small units of code built to handle a limited task.

What are Web Services?
* Web services are small units of code
* Web services are designed to handle a limited set of tasks * Web services uses XML based communicating protocols
* Web services are independent of operating systems
* Web services are independent of programming languages
* Web services connect people, systems and devices

Small Units of Code
Web services are small units of code designed to handle a limited set of tasks. An example of a web service can be a small program designed to supply other applications with the latest stock exchange prices. Another example can be a small program designed to handle credit card payment.

SQL SERVER

Editions of sql server
• Enterprise (Developer)
• Standard
• Personal

Components
• Server Components
• Components

Server Components
• SQL Server Engine
• SQL Server Agent
• Distributed Transaction Coordinator (DTC)
• Microsoft Search Engine
• SQL Mail
• English Query
• Data Transformation Services (DTS)
• Analysis Services

SQL Server Engine
• The core of SQL Server.
• It is the process that handles all the relational database work. • SQL language describes engine only the query to be processed. • Query optimizer determines how to process the query based on the costs of different types of query execution operations.

SQL Server Agent
• It is an optional process which, when running, executes the SQL jobs and handles other automated tasks.

Distributed Transaction Coordinator (DTC)
• It is a process that handles dual phase commits for transactions that span multiple SQL Servers. Data Transformation Services (DTS)
• It moves data among nearly any types of data sources.
• DTS is extremely useful during data conversions, collecting data from many dissimilar data sources, or gathering for data warehousing. • Analysis
Services
• It enables the developer to define cubes that are similar to excel pivot tables or Access cross tab queries.

Client Components
• Server Network Utility
• Client Network Utility
• SQL Server Service Manager
• Enterprise Manager
• Query Analyzer .Etc
Server Network Utility
• It configures the way in which SQL Server communicates with clients. • Technically this is a client component used to control the server.

Client Network Utility
• It is the client side partner to the Server Network Utility. • It establishes the protocols used to communicate from the client to server.

Service Manager
• A client utility to start and stop the major services of SQL Server and to indicate the current status.

Enterprise Manager
• It is used for administrative tasks.
• An interface for database diagrams.

Query Analyzer
• The tool for executing raw batches of T-SQL code.
• Editing, executing and saving scripts of code is what Query Analyzer does best. • Also in viewing query-optimization plans and execution statistics.

Administering SQL Server

Administering SQL Server

Server-Configuration Properties:
It enables to set server-wide performance and display properties in SQL Server.

Default Message Language :-
The default language for server user messages can be set in Enterprise Manager as well as in code

Full-Text Search Default Language:-
The default language for full-text searches can only be set from within code

Query Governor Cost Limit:-
It limits the maximum number of queries SQL Server will perform according to the estimated query cost. If the user submits a query that exceeds the limit set by the query governor, SQL Server will not execute the query.

Server Security:
SQL Server uses a two-phase security authentication scheme. The user is first authenticated to the SQL server. Once the user is “in” the server, access can be granted to the individual databases. SQL Server stores all login information within the master database.

SQL Server Authentication Mode:-
When SQL Server was installed, one of the decisions made was which of the following authentication methods was used: Windows authentication mode-windows authentication only.
Mixed mode-both windows authentication and SQL Server user authentication.

Windows Authentication:-
It is superior to mixed mode because the user does not need to learn yet another password.

The use of windows authentication means that users exist as windows users to be recognized by SQL Server. The windows SID(Security Identifier) is passed from windows to SQL Server.

It is very robust that it will authenticate not only windows users, but also users within windows user groups.

When a windows group is accepted as a SQL Server login, any windows user who is a member of the group can be authenticated by SQL Server. Access, roles and permissions can be assigned for the windows group; they will apply to any windows user in the group.

Unified Modeling Language:

Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches to object-oriented analysis and design. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the “method wars. The development of UML began in late 1994 when Grady Booch and Jim Rum Baugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods

During 1996, it became clear that several organizations saw UML as strategic to their business. A Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response. Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML 1.0 definition.

The Unified Modeling Language allows the software engineer to express an analysis model using the modeling notation that is governed by a set of syntactic semantic and pragmatic rules.

Relationships
Association
A semantic connection between two instances
Generalization
A relationship between an element and the sub elements that may be substituted for it Dependency
The use of one element by another
Refinement
A shift in levels of abstraction

A UML system is represented using five different views that describe the system from distinctly different perspective. Each view is defined by a set of diagram, which is as follows.

User Model View

* This view represents the system from the users perspective. * The analysis representation describes a usage scenario from the end- user perspective.

Structural model view
* In this model the data and functionality are arrived from inside the system. * This model view models the static structures.

Behavioral Model View
It represents the dynamic of behavioral as parts of the system, depicting the interactions of collection between various structural elements described in the user model and structural model view.

Implementation Model View
In this the structural and behavioral as parts of the system are represented as they are to be built.
UML diagrams :

Structural Diagrams
A type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, composite structure, component, deployment, object, and package diagrams.

Class diagram
Shows a collection of static model elements such as classes and types, their contents, and their relationships. Building blocks of the model: class & relationships

Object diagram
Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram.

Package diagram
Shows how model elements are organized into packages as well as the dependencies between packages. Higher-level model organization

Behavioral Diagrams
A type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams.

Use case diagram
External functionality of a system. Shows use cases, actors, and their interrelationships.

Sequence diagram
Models the sequential logic, in effect the time ordering of messages between classifiers. Time-ordered sequences of interacting objects

Collaboration diagram
Object-centered interaction of a society of objects

State transition diagram
Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. The life history of a single object

Activity diagram
Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. Procedural flow of control within an overall interaction

Implementation Diagrams
Component diagram
Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted. The dependencies among software units

Deployment diagram
Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. The distribution and interaction of components and objects on computational nodes

Interaction diagrams: A subset of behavior diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams.

Advantages

* Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. * Provide extensibility and specialization mechanisms to extend the core concepts. * Be independent of particular programming languages and development processes. * Provide a formal basis for understanding the modeling language. * Encourage the growth of the OO tools market.

* Support higher-level development concepts such as collaborations, frameworks, patterns and components. * Integrate best practices.
* The UML is expressive
* The UML is applicable to a wide variety of problem domains and
development processes * The UML is stable

Test Cases

1) COMPILATION TEST:
It was a good idea to do our stress testing early on; this program was successfully loaded and compiled. Because of good programming there was no Compilation error. 2) EXECUTION TEST:
This program was successfully loaded and executed. Because of good programming there were no execution errors. 3) OUTPUT TEST:
The successful output screens are placed in the output screens section.

BLACK-BOX TESTING
Knowing the specified function that a product has been designed to perform, tests can be conducted that demonstrates each function is fully operational, at the same time searching for errors in each function. It enables us to derive sets of input conditions that will fully exercise all function requirements for a program. It attempts to find errors in the following categories:

* Incorrect or missing functions.
* Interface errors
* Errors in the data structures or external database access * Performance errors
* Initialization and termination errors
WHITE-BOX TESTING
This is performed knowing the internal workings of a product. Tests are conducted to ensure that “all gears mesh”, that is, that internal operation performs according to specification and all internal components have been adequately exercised. This can be done on close examination of procedural detail by providing test cases that exercise specific set of conditions and/or loops tests logical paths through the software. Using the White-Box testing we can derive test cases that, * Guarantee that all independent paths within a module have been exercised at least once. * Exercise all logical decisions on their true and false sides. * Execute all loops at their boundaries and within their operational bounds . * Exercise internal data structures to assure their validity. By the test cases each of the modules have executed at least once and tested for bugs. All the logic decisions on their true and false sides are executed so that the system will perform well. UNIT TESTING

* Black box and white box testing
* Module interfaces are tested for proper information flow. * Local data are examined to ensure that integrity is maintained. * Boundary conditions are tested.
* Basis path testing should be used.
* All error handling paths should be tested.
* Drivers and/or stubs need to be developed to test incomplete software.

INTEGRATION TESTING
* Top-down integration testing
1. Main control module used as a test driver and stubs are substitutes for components directly subordinate to it. 2. Subordinate stubs are replaced one at a time with real components (following the depth-first or breadth-first approach). 3. Tests are conducted as each component is integrated.

4. On completion of each set of tests and other stub is replaced with a real component. 5. Regression testing may be used to ensure that new errors not introduced. * Bottom-up integration testing

1. Low level components are combined in clusters that perform a specific software function. 2. A driver (control program) is written to coordinate test case input and output. 3. The cluster is tested.

4. Drivers are removed and clusters are combined moving upward in the program structure.

VALIDATION TESTING
* Ensure that each function or performance characteristic condition to its
specification. * Deviations(deficiencies) must be negotiated with the customer to establish a means for resolving the errors. * Configuration review or audit is used to ensure that all elements of the software configuration have been properly developed, cataloged, and documented to allow its support during its maintenance phase.

Types of Validation Testing
Alpha Test
A customer conducts it at the developer’s site. The software is used in a natural setting with the developer “ looking over the shoulder” of the user and recording errors and usage problems. Beta Test

This test is conducted at one or more users sited by the end user(s) of the software. Here the developer is generally not present. Therefore, the beta test is a “ live” application of the software in an environment that can’t be controlled by the developer.

Registration of Customer

Test case ID| Input| Description| Expected result| Pass/Fail| EIS_TC_01| Empty username, password, confirm password, address and contact number.| Empty username, password, confirm password, address and contact number given by user| Fields should not be empty| Pass| EIS_TC_02| Invalid username and valid id, password, confirm password, address and contact number.| An Invalid username given by user| username field should be in specified format| Pass| EIS_TC_03| Invalid username, password, confirm password, valid address and contact number. | An invalid username, password given by user| Username, password field should be in specified format.| Pass| EIS_TC_04| Different password and confirm password provided.| Different password and confirm password provided by user.| Password mismatch| Pass| EIS_TC_05| Invalid address and valid first name, last name, id, password, confirm password and contact number.| An invalid address provided by user.| Address field should be in specified format.| Pass| EIS_TC_06| Invalid contact number and valid first name, last name, id, password, confirm password and address.| An invalid contact number provided by user.| Contact number field should be in specified format.| Pass| EIS_TC_07| Valid first name, last name, id, password, confirm password, address and contact number. | Valid first name, last name, id, password, confirm password, address and contact number given by user.| Registration completed success fully| pass|

Log in Test Case

Test case ID| Input| Description| Expected result| Pass/Fail| EIS_TC_01| User id and password| Empty user id and password given by System user| User id and password field should not be empty| Pass| EIS _TC_02| Enter invalid user id and valid Password| An empty field given by System user| User id field should not be empty and valid| Pass| EIS _TC_03| Enter valid user id and invalid Password| An empty field or wrong entry given by System user| Password field should not be empty and valid| Pass| EIS _TC_04| Enter valid user id and valid Password| User id and password given by System user are valid| Navigate to next page successfully| Pass|

Registration of Complaint

Test case ID| Input| Description| Expected result| Pass/Fail| EIS_TC_01| Empty Compid ,Compname and CompDescription.| Empty Compid ,Compname and CompDescription given by user| Fields should not be empty| Pass| EIS_TC_02| Invalid Compid and valid Compname, and CompDescription| An Invalid Compid given by user| Compid field should be in specified format| Pass| EIS_TC_03| Invalid Compid, Compname, valid CompDescription. | An invalid Compid, Compname given by user| Compid, Compname field should be in specified format.| Pass| EIS_TC_04| Invalid CompDescription. and valid Compid, Compname| An invalid CompDescription provided by user.| CompDescription field should be in specified format.| Pass| EIS_TC_05| valid CompDescription. Compid, Compname| Valid CompDescription. Compid, Compname provided by user.| Sucessfully Navigate to next page.| Pass|

Manages the customer Test Case (Update)

Test case ID| Input| Description| Expected result| Pass/Fail| EIS_TC_01| contact, address,| Empty fields are submitted by the user| contact and address field should not be empty| Pass| EIS _TC_02| Enter invalid contact and valid address| An empty field given by System user| contact field should not be empty and valid| Pass| EIS _TC_03| Enter valid contact and invalid address| An empty field or wrong entry given by System user| contact field should not be empty and valid| Pass| EIS _TC_04| Enter valid contact and valid address| address and contactgiven by System user are valid| Navigate to next page successfully| Pass|

Delete the Customer

Test case ID| Input| Description| Expected result| Pass/Fail| EIS_TC_01| Customer id| Empty fields are submitted by the user| Cust id field should not be empty| Pass| EIS _TC_02| Enter valid customer id| Cust id entered by the user| Customer details are successfully deleted| Pass|

Manages the Supervisor Test Case (Update)

Test case ID| Input| Description| Expected result| Pass/Fail| EIS_TC_01| contact, address,| Empty fields are submitted by the user| contact and address field should not be empty| Pass| EIS _TC_02| Enter invalid contact and valid address| An empty field given by System user| contact field should not be empty and valid| Pass| EIS _TC_03| Enter valid contact and invalid address| An empty field or wrong entry given by System user| contact field should not be empty and valid| Pass| EIS _TC_04| Enter valid contact and valid address| address and contactgiven by System user are valid| Navigate to next page successfully| Pass|

Delete the Supervisor

Test case ID| Input| Description| Expected result| Pass/Fail| EIS_TC_01| Customer id| Empty fields are submitted by the user| Cust id field should not be empty| Pass| EIS _TC_02| Enter valid customer id| Cust id entered by the user| Customer details are successfully deleted| Pass|

Complaint Update Table

Test case ID| Input| Description| Expected result| Pass/Fail| EIS_TC_01| Comid, CompDesc| Empty fields are submitted by the user| Comid and CompDesc field should not be empty| Pass| EIS _TC_02| Enter invalid Comid and valid CompDesc| An empty field given by System user| Comid field should not be empty and valid| Pass| EIS _TC_03| Enter valid Comid and invalid CompDesc| An empty field or wrong entry given by System user| CompDesc field should not be empty and valid| Pass| EIS _TC_04| Enter valid Comid and valid CompDesc| CompDesc and Comid given by System user are valid| Navigate to next page successfully| Pass|

Conclusion

The entire project has been developed and deployed as per the requirements stated by the user, it is found to be bug free as per the testing standards that are implemented. Any specification untraced errors will be concentrated in the coming versions, which are planned to be developed in near future.-

Future Enhancements

It is not possible to develop a system that makes all the requirements of the Customer. Customer requirements keep changing as the system is being used. Some of the future enhancements that can be done to this system are:

* As the technology emerges, it is possible to upgrade the system and can be adaptable to desired environment.

* Because it is based on object-oriented design, any further changes can be easily adaptable.

* Based on the future security issues, security and be improved using emerging technologies.

Bibliography

SOFTWARE ENGINEERING

A Practitioner’s Approach * McGraw-Hill publications
* Roger S.Pressman.
SQL SERVER

http://www.w3schools.com/sql/default.asp.
http://www.sqltutorial.net
http://www.keydata.com/sql/sql.html.

.NET
Professional C#. NET 3.5
-By Wrox Publications

MSDN 2008
-By Microsoft
http://www.msdn.com

http://www.danielmoth.com/Blog/net-framework-35.aspx

http://www.windowsclient.net/wpf/wpf35/wpf-whats-new-35sp1.aspx

http://www.odetocode.com/code/419.aspx

FOR ASP.NET
Asp.Net 3.5 Unleashed
www.msdn.microsoft.com/net/quickstart/aspplus/default.com
www.asp.net
www.fmexpense.com/quickstart/aspplus/default.com
www.asptoday.com
www.aspfree.com

Free Help Desk Essay Sample

B

Let us write you a custom essay sample on Help Desk

for only $16.38 $13.9/page

your testimonials