SIMPLE MAILING SYSTEM (GMS) CONTENTS

1. ABSTRACT 2. INTRODUCTION 3. DESIGN PRINCIPLES & EXPLANATION 3.1. MODULES 3.2. MODULE DESCRIPTIOIN 4. PROJECT DICTIONARY 4.1. UML DIAGRAMS 4.2. DATA DICTIONARY 5. FORMS & REPORTS 5.1. I/O SAMPLES 6. BIBILIOGRAPHY

1. ABSTRACT

This project SIMPLE MAILING SYSTEM aims of providing a good communication interface for the organization. It can cut down the time of employees spend on routine communication tasks. Its successful implementation makes easy the job of employees in the organization. The basic problem is that the employees in the organization communicate or make correspondence only through post, as their units are located in remote areas. This method of communication is very slow in nature and it is not reliable. Therefore the solution for this problem is to develop a communication channel that meets the need of the organization. Basically, the computerized solution is for improving the services as well as self-efficiency of the computer. The objective of the system is for meeting the needs of the employees in the organization for communicating with each other within their units. This application provides basic requirements such as Mail management, File transfer and instant messaging. It also has enhanced features like web browsing and utilities. The SIMPLE-mailing System is very user-friendly application. Only certain applications like system monitoring instant messaging, chatting between two users needs a little training.

2. INTRODUCTION This company has different departments situated in different locations. It has four offices and three sites (factory). These are situated at different places and have a minimum distance of 15 Km. The basic problem is that they communicate or make correspondence only through post as their units are located in remote areas. This method of communication is very slow in nature and it is not reliable. Therefore the solution for this problem is to develop a communication channel that meets the need of the organization. Basically, the computerized solution is for improving the services as well as self-efficiency of the computer. This project SIMPLE MAILING SYSTEM aims at providing a good communication interface for the organization. It can cut down the time of employees spend on routine communication tasks. Its successful implementation makes easy the job of employees in the organization.

This application provides facilities like mails, instant messages and allows employees to communicate more effectively, and access the resources they need to maximize their day-today productivity. It provides fast and better access to up-to-date information.

MAIL: SIMPLE mailing facility allows organizations with simple intranet to exchange emails internally without the need of an Internet connection, in which (a) Usually text is transmitted, (b) Operations include sending, storing, processing, and receiving information, (c) Users are allowed to communicate under specified conditions, and (d) Messages are held in storage until called for by the addressee. SIMPLE Mailing System is the system which is used to establish online communication among the employees of an organization at different branches and within the organization between the departments. The employees of the organization can send mails to each other in the working in different departments at different locations. The purpose of SIMPLE Mailing System is, an employee of a company can send and receive mails only in that organizations Local Area Network or Wide Area Network. It will work like Internet mailing system for this Intranet.

PURPOSE: The purpose of this document is to describe all the external Requirements of the SIMPLE Mailing System. It also describes interfaces for the system it is:

1. To serve as a basis for the users to confirm that the results of the study phase are acceptable to them. 2. To serve as a basis for the design phase of the project. 3. To serve as a basis for monitoring the progress of the entire project with reference to the SIMPLE Mailing System. 4. To serve as the basis for the acceptance testing of the application system with reference to the functional requirements. 5. To document the functions, the proposed system is to perform without actually going into the implementation details.

SCOPE: This document describes the requirements of the system. It is meant for use by the developers, and will also be the basis for validating the final system. Any Changes made to the requirements in the future will have to go through a formal change approval process. The developer is responsible for asking for clarifications where necessary and will not make any alterations without the permission of the client.

3. DESIGN PRINCIPLES & EXPLANATION 3.1. MODULES This project consists of two modules. 1. Administration Module. ( 2. Mailing Module. 3. Security 4. Fileexhange

3.2. MODULE DESCRIPTIOIN Administrator:

In administrator module we have five options.

1. Generate User. 2. Delete User. 3. Check Mail. 4. Send Mail. 5. Show Users

When the administrator select the option generate user, he will creates a new user id and password for the new user. When the administrator selects the option Delete User, he will delete an existing user if not necessary. When the administrator selects the send mail option, then the form will be opened for sending mail. Then the admin send mail to any other user who has a user id in the organization. In check mail option, the admin check for the mails. If the user has any mails, then the mails are displayed. He will check the mails and delete the unnecessary mails. If the user has no mails then the message No Mails is displayed. . When the admin selects the show users option, then the number of users who are currently logged on is displayed. This page automatically refreshes after every 5 seconds to give the current users list. Normal User: In user module we have two options. 1. Send Mail. 2. Check Mail.

When the user selects the send mail option, then the form will be opened for sending mail. Then the user can send mail to any other user who has a user id in the organization. In check mail option, the user can check for the mails. If the user has any mails, then the mails are displayed. He will check the mails and can delete the unnecessary mails. If the user has no mails then the message No Mails is displayed.

4. PROJECT DICTIONARY 4.1. UML DIAGRAMS USE CASE DIAGRAM

Technology Overview of my Project

PHP
PHP stands for hypertext processor. PHP started in late 1994. It is the best server side technology written in C language by Rasmus Lerdorf.

Features:

--very short development times (i.e. faster to code and faster to execute) --platform independence --multiple database support

PHP is used for creating rich, dynamic web sites. PHP scripts can parse data submitted by HTML forms, communicate with databases, and make complex calculation on the fly. And it is very fast, because the freely available source code compiled into the Apache web server. The same PHP code runs unaltered on different web servers and different operating systems. PHP runs on UNIX. Windows and Macintosh. It is designed to integrate with the Apache web server. Apache is the most popular web server on the internet. PHP works with other web server, including Microsoft Internet Information Server (IIS).

What a PHP Script looks like

PHP exists as a tag inside an HTML file. Like all HTML tags, it begins with a less than symbols, or opening angle bracket(<) and ends with a greater then symbol, or closing angle bracket(>). To distinguish it from other tags, the PHP tag has a question mark (?) following the opening angle bracket and preceding the closing angle bracket.

The print function: The print is one of PHPs functions. This function sends text to the browser. E.g.: <? Print (welcome to my PHP page.) ?>

Note: Each statement is closed with the semicolon. The echo () function can also be used to print the text on the browser.

About Identifier, / Expression: An identifier can be a function or a variable. Identifiers are case sensitive. The exception is built-in functions. For example, the function like pint can be called as Print if you prefer. Variable: Variables are the memory spaces in a computers memory. The variables are casesensitive. Uppercase and lowercase letters re recognized as different. Variables are always preceded by $ sign. Variable creation, declaring and assigning value: $a=welcome to PHP world; Expressions: --Operator: An operator is usually one or two symbols that stand for some sort of data manipulation like addition or multiplication. When identifiers and operators are combined, they become an expression. Data types PHP has three elemental types of data: i) Integer: sometimes referred to as a whole or natural numbers. They Contain no decimal point.

ii)

Floating-point numbers: Sometimes called real numbers. They always contain

a decimal point. PHP refers to these as doubles, which is short for double-precision floating-point numbers. iii) String: collections of textual data. String constants are always surrounded by double quotes () or single quotes ().

As you write PHP code, you will usually be unaware of the distinction between types because variables are multi type. You do not declare a variable to be a particular type. This is a quality of a dynamic language. You just assign it a value. PHP will remember what type of data you put into the variable. When you retrieve data from the variable, they are returned with that same type.

OPERATORS: 1. Arithmetic operators: +,-,*, /, %( moduls Division), ++,-2. Relational and Logical operators: < , > , <= ,>= , = = , != ,&& , || , ! 3. Miscellaneous operators: $ Reference a variable . Concatenate 4. assignment operator: =

Array: An array is a set of variables that all have the same name but a different index. Each member of the array is called an element. You create arrays in the same way you create variables, except that each elements name must be followed by its index in square brackets: Arrays, assigning index number: E.g. 1: $cities [0] =Kathmandu; $cities [1] =Bhaktapur; $cities [2] =lalitpur; Arrays, not assigning index number; E.g. 2: $cities [] =Kathmandu; $cities [] =Bhaktapur; $cities [] =Lalitpur; Arrays, using array () function: E.g.3: $cities =array (Kathmandu, Bhaktapur, Lalitpur);

Control Statements:

The if statement:
Syntax: if (expression) { It executes if the expression is true. } else if (expression2) { It executes if expression is false And expression2 is true. } else { It executes only if both expression are false. } E.g. <? if ($name= =); { print (you have no name.) } elseif (($name==a)OR ($name==a)) { Print (hello, A!); else { print(your name is $name.; } ?>

 Switch statement:
Syntax: Switch (root-expression) { Case case-expression: expression.. default: .expression.. }

<? $engDay =date (|); switch ($engDay) { case Sunday; $dayno=1; break; caseMonday; $dayno=2; break; default: $dayno=other; } Print(Today is day $dayno); ?>

Loops
a. while statement: Syntax: while(expression) { ..statement.. } Break statement E.g.: <? $a=40; While($a>=20) { Print(tis line is printed.); Break; Print(This line will never be printed.); } ?> Continue statements: The continue statements is similar to the break statement except that instead of stopping the loop entirely, only the current execution of the loop is stopped. Control is returned to the closing curly brace and the loop continues. b. do while statement : Syntax, example: do

{ Print(Hello); $a++; } While($a<=10)

c. for statements : syntax: for(initialization;continue;increment) { statements.. }

Functions: declaring a function:

When you declare a function, you start with the function statement. Next comes a name for your function. Inside the parenthesis is a list of arguments separated by commas. You may choose to have no arguments. Syntax: Function function_name (arguments) { Code block } Example: <? Function print_Bold($input Text) { Print(<b> ,$input Text ,</b>); } Print(This line is not Bold<br>\n); printBold(this line is Bold); print(<br\n); print(This line is not Bold<br>\n); ?>

date Format Codes:

Code Description

D D F H H g G i J L M M N S S Y Y Z

Day of the month with leading zeros Day of the week as a three-letter abbreviation Name of the month Hour from 01to 12 Hour from 00 to 23 Hour from 1 to 12(no leading zeroes) Hour from 0 to 23(no leading zeroes) Minutes Day of the month with no leading zeroes Day of the week Month number from 01 to 12 Abbreviated month name (Jan, Feb) Month number from 1 to 23(no leading zeroes) Seconds 00 to 59 Ordinal suffix for day of the month (1st, 2nd, 3rd) Year as two digits Year as four digits Day of the year from 0 to 365

Application Domain Overview

Historically, process boundaries have been used to isolate applications running on the same computer. Each application is loaded into a separate process, which isolates the application from other applications running on the same computer. The applications are isolated because memory addresses are process-relative; a memory pointer passed from one process to another cannot be used in any meaningful way in the target process. In addition, you cannot make direct calls between two processes. Instead, you must use proxies, which provide a level of indirection. Managed code must be passed through a verification process before it can be run (unless the administrator has granted permission to skip the verification). The verification process determines whether the code can attempt to access invalid memory addresses or perform some other action that could cause the process in which it is running to fail to operate properly. Code that passes the verification test is said to be type-safe. The ability to verify code as type-safe enables the common language runtime to provide as great a level of isolation as the process boundary, at a much lower performance cost. Application domains provide a more secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. The ability to run multiple applications within a single process dramatically increases server scalability. Isolating applications is also important for application security. For example, you can run controls from several Web applications in a single browser process in such a way that the controls cannot access each other's data and resources. The isolation provided by application domains has the following benefits:

Faults in one application cannot affect other applications. Because type-safe code

cannot cause memory faults, using application domains ensures that code running in one domain cannot affect other applications in the process.

Individual applications can be stopped without stopping the entire process. Using

application domains enables you to unload the code running in a single application.

Code running in one application cannot directly access code or resources from another

application. The common language runtime enforces this isolation by preventing direct calls between objects in different application domains. Objects that pass between domains are either copied or accessed by proxy. If the object is copied, the call to the object is local. That is, both the caller and the object being referenced are in the same application domain. If the object is accessed through a proxy, the call to the object is remote. In this case, the caller and the object being referenced are in different application domains. Cross-domain calls use the same remote call infrastructure as calls between two processes or between two machines. As such, the metadata for the object being referenced must be available to both application domains to allow the method call to be JIT-compiled properly. If the calling domain does not have access to the metadata for the object being called, the compilation might fail with an exception of type System.IO.FileNotFound. See Remote Objects for more details. The mechanism for determining how objects can be accessed across domains is determined by the object. For more information, see MarshalByRefObject Class.

The behavior of code is scoped by the application in which it runs. In other words, the

application domain provides configuration settings such as application version policies, the location of any remote assemblies it accesses, and information about where to locate assemblies that are loaded into the domain.

Permissions granted to code can be controlled by the application domain in which the

code is running.

Application Domains and Assemblies

This topic describes the relationship between application domains and assemblies. You must load an assembly into an application domain before you can execute the code it contains. Running a typical application causes several assemblies to be loaded into an application domain. If an assembly is used by multiple domains in a process, the JIT output from an assembly's code can be shared by all domains referencing the assembly. The runtime host decides whether to load assemblies as domain-neutral when it loads the runtime into a process. For more information, see the LoaderOptimizationAttribute For hosting, attribute see the and the associated for

LoaderOptimization

enumeration.

documentation

CorBindToRuntimeEx in the common language runtime Hosting Interfaces Specification found in the .NET Framework SDK. There are three options for loading domain-neutral assemblies:

Load no assemblies as domain-neutral, except Mscorlib, which is always loaded

domain-neutral. This setting is called single domain because it is commonly used when the host is running only a single application in the process.

Load all assemblies as domain-neutral. Use this setting when there are multiple

application domains in the process, all of which run the same code.

Load strong-named assemblies as domain-neutral. Use this setting when running more

than one application in the same process. When you decide whether to load assemblies as domain-neutral, you must make a tradeoff between reducing memory use and performance. The performance of a domain-neutral assembly is slower if that assembly contains static data or static methods that are accessed frequently. Access to static data is slower because of the need to isolate assemblies. Each application domain that accesses the assembly must have a separate copy of the static data, to prevent references to objects in static fields from crossing domain boundaries. As a result, the runtime contains additional logic to direct a caller to the appropriate copy of the static data or method. This extra logic slows down the call.

An assembly is not shared between domains when it is granted a different set of permissions in each domain. This can occur if the runtime host sets an application domain-level security policy. Assemblies should not be loaded as domain-neutral if the set of permissions granted to the assembly is likely to be different in each domain.

SYSTEM DEVELOPMENT LIFE CYCLE

System Development Methodology

System Development Life Cycle PHASES: 1.2.1 Initiation Phase The initiation of a system (or project) begins when a business need or opportunity is identified. A Project Manager should be appointed to manage the project. This business need is documented in a Concept Proposal. After the Concept Proposal is approved, the System Concept Development Phase begins. 1.2.2 System Concept Development Phase Once a business need is approved, the approaches for accomplishing the concept are reviewed for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the system and requires Senior Official approval and funding before beginning the Planning Phase. 1.2.3 Planning Phase

The concept is further developed to describe how the business will operate once the approved system is implemented, and to assess how the system will impact employee and customer privacy. To ensure the products and /or services provide the required capability on-time and within budget, project resources, activities, schedules, tools, and reviews are defined. Additionally, security certification and accreditation activities begin with the identification of system security requirements and the completion of a high level vulnerability assessment. 1.2.4 Requirements Analysis Phase

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

1.2.5

Design Phase

The physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The physical characteristics of the system are specified and a detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module. 1.2.6 Development Phase

The detailed specifications produced during the design phase are translated into hardware, communications, and executabsle software. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested. 1.2.7 Integration and Test Phase

The various components of the system are integrated and systematically tested. The user tests the system to ensure that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and accreditation activities. 1.2.8 Implementation Phase

The system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements. 1.2.9 Operations and Maintenance Phase

The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. The operational system is periodically assessed through In-Process Reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organizations needs. When modifications or changes are identified as necessary, the system may reenter the planning phase. 1.2.10 Disposition Phase

The disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.

SDLC Objectives This guide was developed to disseminate proven practices to system developers, project managers, program/account analysts and system owners/users throughout the DOJ. The specific objectives expected include the following:

To reduce the risk of project failure To consider system and data requirements throughout the entire life of the system To identify technical and management issues early To disclose all life cycle costs to guide business decisions To foster realistic expectations of what the systems will and will not provide To provide information to better balance programmatic, technical, management, and cost aspects of proposed system development or modification

To encourage periodic evaluations to identify systems that are no longer effective To measure progress and status for effective corrective action To support effective resource management and budget planning

To consider meeting current and future business requirements

Key Principles This guidance document refines traditional information system life cycle management approaches to reflect the principles outlined in the following subsections. These are the foundations for life cycle management. Life Cycle Management Should be used to Ensure a Structured Approach to Information Systems Development, Maintenance, and Operation This SDLC describes an overall structured approach to information management. Primary emphasis is placed on the information and systems decisions to be made and the proper timing of decisions. The manual provides a flexible framework for approaching a variety of systems projects. The framework enables system developers, project managers, program/account analysts, and system owners/users to combine activities, processes, and products, as appropriate, and to select the tools and methodologies best suited to the unique needs of each project. Support the use of an Integrated Product Team The establishment of an Integrated Product Team (IPT) can aid in the success of a project. An IPT is a multidisciplinary group of people who support the Project Manager in the planning, execution, delivery and implementation of life cycle decisions for the project. The IPT is composed of qualified empowered individuals from all appropriate functional disciplines that have a stake in the success of the project. Working together in a proactive, open communication, team oriented environment can aid in building a successful project and providing decision makers with the necessary information to make the right decisions at the right time. Each System Project must have a Program Sponsor To help ensure effective planning, management, and commitment to information systems, each project must have a clearly identified program sponsor. The program sponsor serves in a

leadership role, providing guidance to the project team and securing, from senior management, the required reviews and approvals at specific points in the life cycle. An approval from senior management is required after the completion of the first seven of the SDLC phases, annually during Operations and Maintenance Phase and six-months after the Disposition Phase. Senior management approval authority may be varied based on dollar value, visibility level, congressional interests or a combination of these. The program sponsor is responsible for identifying who will be responsible for formally accepting the delivered system at the end of the Implementation Phase. A Single Project Manager must be Selected for Each System Project The Project Manager has responsibility for the success of the project and works through a project team and other supporting organization structures, such as working groups or user groups, to accomplish the objectives of the project. Regardless of organizational affiliation, the Project Manager is accountable and responsible for ensuring that project activities and decisions consider the needs of all organizations that will be affected by the system. The Project Manager develops a project charter to define and clearly identify the lines of authority between and within the agencys executive management, program sponsor, (user/customer), and developer for purposes of management and oversight. A Comprehensive Project Management Plan is Required for Each System Project The project management plan is a pivotal element in the successful solution of an information management requirement. The project management plan must describe how each life cycle phase will be accomplished to suit the specific characteristics of the project. The project management plan is a vehicle for documenting the project scope, tasks, schedule, allocated resources, and interrelationships with other projects. The plan is used to provide direction to the many activities of the life cycle and must be refined and expanded throughout the life cycle.

Specific Individuals Must be Assigned to Perform Key Roles Throughout the Life Cycle Certain roles are considered vital to a successful system project and at least one individual must be designated as responsible for each key role. Assignments may be made on a full- or part-time basis as appropriate. Key roles include program/functional management, quality assurance, security, telecommunications management, data administration, database administration, logistics, financial, systems engineering, test and evaluation, contracts management, and configuration management. For most projects, more than one individual should represent the actual or potential users of the system (that is, program staff) and should be designated by the Program Manager of the program and organization

System Development Methodology

1. Initiation Phase
The initiation of a system (or project) begins when a business need or opportunity is identified. A Project Manager should be appointed to manage the project. This business need is documented in a Concept Proposal. After the Concept Proposal is approved, the System Concept Development Phase begins.

2.

System Concept Development Phase

Once a business need is approved, the approaches for accomplishing the concept are

reviewed for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the system and requires Senior Official approval and funding before beginning the Planning Phase.

3.

Planning Phase

The concept is further developed to describe how the business will operate once the approved system is implemented, and to assess how the system will impact employee and customer privacy. To ensure the products and /or services provide the required capability on-time and within budget, project resources, activities, schedules, tools, and reviews are defined. Additionally, security certification and accreditation activities begin with the identification of system security requirements and the completion of a high level vulnerability assessment.

4.

Requirements Analysis

Phase Functional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. All requirements are defined to a level of detail sufficient for systems design to proceed. All

requirements need to be measurable and testable and relate to the business need or opportunity identified in the Initiation Phase.

5.

Design Phase

The physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The physical characteristics of the system are specified and a detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module.

6.

Development Phase

The detailed specifications produced during the design phase are translated into hardware, communications, and executable software. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.

7.

Integration and Test Phase

The various components of the system are integrated and systematically tested. The user tests the system to ensure that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and accreditation activities.

8.

Implementation Phase

The system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the . This

phase continues until the system is operating in production in accordance with the defined user requirements.

9.

Operations and Maintenance Phase

The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. The operational system is periodically assessed through In-Process Reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organizations needs. When modifications or changes are identified as necessary, the system may reenter the planning phase.

10.

Disposition Phase

The disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.

SDLC Objectives
This guide was developed to disseminate proven practices to system developers, project managers, program/account analysts and system owners/users throughout the DOJ. The specific objectives expected include the following:

To reduce the risk of project failure To consider system and data requirements throughout the entire life of the system To identify technical and management issues early To disclose all life cycle costs to guide business decisions To foster realistic expectations of what the systems will and will not provide

To provide information to better balance programmatic, technical, management, and cost aspects of proposed system development or modification

To encourage periodic evaluations to identify systems that are no longer effective To measure progress and status for effective corrective action To support effective resource management and budget planning To consider meeting current and future business requirements

Key Principles
This guidance document refines traditional information system life cycle management approaches to reflect the principles outlined in the following subsections. These are the foundations for life cycle management. Life Cycle Management Should be used to Ensure a Structured Approach to Information Systems Development, Maintenance, and Operation This SDLC describes an overall structured approach to information management. Primary emphasis is placed on the information and systems decisions to be made and the proper timing of decisions. The manual provides a flexible framework for approaching a variety of systems projects. The framework enables system developers, project managers, program/account analysts, and system owners/users to combine activities, processes, and products, as appropriate, and to select the tools and methodologies best suited to the unique needs of each project.

1. Support the use of an Integrated Product Team

The establishment of an Integrated Product Team (IPT) can aid in the success of a project. An IPT is a multidisciplinary group of people who support the Project Manager in the planning, execution, delivery and implementation of life cycle decisions for the project. The IPT is composed of qualified empowered individuals from all appropriate functional disciplines that have a stake in the success of the project. Working together in a proactive, open communication, team oriented environment can aid in building a successful project and

providing decision makers with the necessary information to make the right decisions at the right time.

2. Each System Project must have a Program Sponsor

To help ensure effective planning, management, and commitment to information systems, each project must have a clearly identified program sponsor. The program sponsor serves in a leadership role, providing guidance to the project team and securing, from senior management, the required reviews and approvals at specific points in the life cycle. An approval from senior management is required after the completion of the first seven of the SDLC phases, annually during Operations and Maintenance Phase and six-months after the Disposition Phase. Senior management approval authority may be varied based on dollar value, visibility level, congressional interests or a combination of these. The program sponsor is responsible for identifying who will be responsible for formally accepting the delivered system at the end of the Implementation Phase.

3. A Single Project Manager must be Selected for Each System Project

The Project Manager has responsibility for the success of the project and works through a project team and other supporting organization structures, such as working groups or user groups, to accomplish the objectives of the project. Regardless of organizational affiliation, the Project Manager is accountable and responsible for ensuring that project activities and decisions consider the needs of all organizations that will be affected by the system. The Project Manager develops a project charter to define and clearly identify the lines of authority between and within the agencys executive management, program sponsor, (user/customer), and developer for purposes of management and oversight.

4. A Comprehensive Project Management Plan is Required for Each System Project

The project management plan is a pivotal element in the successful solution of an information management requirement. The project management plan must describe how each life cycle phase will be accomplished to suit the specific characteristics of the project. The project management plan is a vehicle for documenting the project scope, tasks, schedule, allocated resources, and interrelationships with other projects. The plan is used to provide direction to the many activities of the life cycle and must be refined and expanded throughout the life cycle.

5. Specific Individuals must be assigned to Perform Key Roles throughout the Life Cycle
Certain roles are considered vital to a successful system project and at least one individual must be designated as responsible for each key role. Assignments may be made on a full- or part-time basis as appropriate. Key roles include program/functional management, quality assurance, security, telecommunications management, data administration, database administration, logistics, financial, systems engineering, test and evaluation, contracts management, and configuration management. For most projects, more than one individual should represent the actual or potential users of the system (that is, program staff) and should be designated by the Program Manager of the program and organization

FEASIBILITY STUDY
A feasibility study is conducted to select the best system that meets performance requirement. This entails an identification description, an evaluation of candidate system and the selection of best system for he job. The system required performance is defined by a statement of constraints, the identification of specific system objective and a description of outputs. The key consideration in feasibility analysis are :
1. Economic Feasibility : 2. Technical Feasibility : 3. Operational Feasibility:

Economical feasibility It looks at the financial aspects of the project. It determines whether the management has enough resources and budget to invest in the proposed system and the estimated time for the recovery of cost incurred. It also determines whether it is worth while to invest the money in the proposed project. Economic feasibility is determines by the means of cost benefit analysis.The proposed system is economically feasible because the cost involved in purchasing the hardware and the software are within approachable. The personal cost like salaries of employees hired are also nominal, because working in this system need not required a highly qualified professional. The operating-environment costs are marginal. The less time involved also helped in its economical feasibility. It was observed that the organization has already using computers for other purpose, so that there is no additional cost to be incurred for adding this system to its computers. The backend required for storing other details is also the same database that is Mysql. The computers in the organization are highly sophisticated and dont needs extra components to load the software. Hence the organization can implement the new system without any additional expenditure. Hence, it is economically feasible

Data Flow Diagram Overview

DFD is an i mportant t ool used by system analysts. The main merit of DFD is that it can provide an over view of what data a system would process, what transformation of data are done, what files are used and where the result flows. The graphical representat i on of the system makes it a user and anal yst. DFDs are structured in such a way that starting from a si mple diagram which provides a broad over view at a glance, t here can be expanded t o a hierarchy of diagrams gi ving to more and more details Square: -Source or destination of data (Exter nal or Internal)

As the name suggested does not f all within system

boundar y, hence they are def ined as source or destinat ion of data. Rounded rectangle/ Circle: Pr ocess

This can be def ined at place where transf ormation of data takes place; this transf ormation includes additional modif icat ion deletion or accumulation of data. Open ended rectangle/parallel lines, data store.

This symbolically represents place wher e data is stored the data can b e stored f or f uture procession (or) it can be processed f or f uture return any place where dat a is stored is called data stored.

Data flow can take place: 1. Between pr ocess

2. 3. 4. 5.

File to process External entity to process Process to external ent ity Process to file

The result of the feasibility study is a formal proposal. This is simply report-a formal document detailing the nature and the scope of the proposed solution. The proposals summarize what is known and what is going to be done. Three key considerations are involved in the feasibility analysis: economic, technical and operational behavior. 2.3.1 Economic Feasibility: Economic analysis is the most frequently used method for evaluating the effectiveness of a candidate system. More determine the benefits and the saving that are expressed from a candidate system and compare them costs. If benefits outweigh costs. Otherwise, further justification or alterations in the proposed system will have to be made if it is to have a chance of being approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle. 2.3.2 Technical Feasibility: Technical feasibility center around the existing computer system hardware etc. and to what extent it can support the proposed addition. For example, if the current computer is operating at 80% capacity - an arbitrary ceiling then running another application could over load the system or require additional hardware. This involves financial consideration to accommodate technical enhancements. If the budget is a serious constraint then the project is judged not feasible. 2.3.3 Operational Feasibility: It is common knowledge that computer installations have some thing to do with turnover, transfers, retraining and changes in employee job status. Therefore, it is understandable that the introduction of a candidate system requites special efforts to educate, sell, and train the staff on new ways of conducting business.

Login Process Branch

User Check Process Mail Check Process Other Options

Organization

User

Admin

CLASS DIAGRAM

Enter User Login

has User Details

Accessing Mails

Normal User

Admini strator

STATE DIAGRAM

Check ID Do: Compare ID

Ok

Check UID Do: User id/ Admin id

User ID

Initiate: Mails, Check

ID not ok

Administrator

Unacceptable ID Do: Repeat

Create: New User

SEQUENTIAL DIAGRAM

Musers (User id, password) User User Request

Mails

Mails Access Report

Muser (User id, Password) Admin user User Request

New User

New User Details

4.3. DATA DICTIONARY Table name: Musers Description: contains all existing users in the organization. Field Name Userid Password Catid DataType and Size Varchar2(10) Varchar2(10) Varchar2(3)

Table Name: Minbox Description: contains all mails send by the users. Field Name Userid Sender Mail Mdate Mailid DataType and Size Varchar2(10) Varchar2(10) Varchar2(200) Date Number(6)

Table Name: Clogin Description: Contains all the user currently logged on. Field Name Userid Data Type and Size Varchar2(10)

Table Name: Cat. Description: Contains the categories of the employees. Field Name Catid Catname Data Type and Size Varchar2(3) Varchar2(10)

5. FORMS & REPORTS

SECURITY AND CONTROL (TESTING)

In order to have good security User Name and password authentication is given to the System so that only valid users can access the System.

TESTING Software Testing is a critical element of software quality assurance and represents the ultimate review of specification, design and code generation. The increasing visibility of software as a system element and the attendant costs associated with a software failure are motivating forces for well planned, thorough testing.

Testing Objectives: The following are the testing objectives: -Testing is a process of executing a program with the intent of finding an error. -A good test case is one that has a high probability of finding an as-yet-undiscovered error -A successful test is one that uncovers an as yet undiscovered error.

Testing Principles The basic principles that guide software testing are as follows: -All tests should be traceable to customer requirements. -Tests should be planned long before testing begins. -The parate principle applies to software testing.

Pareto principle states that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. Testing should begin in the small and progress toward testing in the large. Exhaustive testing is not possible. To be most effective, testing should be conducted by an independent third party.

Testability: Software Testability is simply how easily (a computer program can be tested). The following characteristics are considered that lead to testable software.

-Operability: The better it works, the more efficiently it can be tested. -Observability: What you see is what you test. -Controllability: The better we can control the software, the more the testing can be automated and optimized. -Decomposability: By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting. -Simplicity: The less there is to test, the more quickly we can test it. -Stability: The fewer the changes, the fewer the disruptions to testing. -Understandability: the more information we have, the smarter we will test.

Test Case Design: The design of testing can be divided into two broad categories: Black Box testing:

White Box Testing: Black box testing: When computer software is considered, black-box testing alludes to tests that are conducted at the software interface. Although they are designed to uncover errors, black-box tests are used to demonstrate that software functions are operational, that input is properly accepted and output is correctly produced, and that the integrity of external information(e.g a database) is maintained.

White box testing: White box testing of software is predicated on close examination of procedural detail. Logical paths through the software are tested by providing test cases that exercise specific sets of conditions and /or loops. The main disadvantage with white box testing is even for smaller programs the number of possible logical paths can be very very large.

6. BIBLIOGRAPHY 1. C.J.DateAn Introduction to Database System---Narosa Publications- 1998 2. David CockmenOracle Database Development - Tech Media - 1997 3. Joseph SchmullerTeach Yourself UML in 24 Hours - Techmedia Publications-1999 4. Pankaj JaloteIntegrated Approach to Software Engineering -Narosa Publication- 1998 5. OriellyJava Servler Pages 6. Patrick Naughton, Herbert schildt-

The Complete Reference Java2 TATA Mc -GRAW HILL Edition, 1998