Time Planner Final

8/2/2019 Time Planner Final

http://slidepdf.com/reader/full/time-planner-final 1/87

Smart Time Planner – An Academic Project

Page 1 of 87

Acknowledgement

We honestly want to thank that behind the completion of our project we

are really fortunate for the support of our honorable professors.

We are thankful to our Project Guide Mr. Sami Patel and of our Head of

Department Mr. Mehtab Aalam and our teachers for their valuable

guidance and suggestions.

We are thankful to them from bottom of our heart for their kind support

and help they endowed to us. We will also not waste the opportunity to

thank our colleagues for always being ready to help us in each and every

way they could.




Page 2 of 87

Sr.No Topic Page No

1. Introduction 4

2. Problem Definition 5

3. Need For Computerization 7

4. Scope For The Proposed System 8

5. Fact Finding Technique 10

6. Hardware & Software Requirements 11

7. Analysis Specification 13

8. Design Specification 23

9. Data Dictionary 32

10. Decision Tools 35

11. Testing Strategies 38




Page 3 of 87

12. Implementation Strategies 44

13. Input Screen 46

14. Output Screen 69

15. User Manual 81

16. Limitation & Drawbacks 84

17. Future Enhancements 85

18. Conclusion 86

19. Reference & Bibilography 87




Page 4 of 87

Introduction

“Failing to plan is planning to fail.” , Alan Lakein.

Time is a precious commodity; everyone gets an equal share but we

use it very differently. We also look at time very differently. About

57% of us are present and future oriented, 33% are mainly future

oriented, 9% are present oriented and only 1% of us focus on the

past. Societies have different attitudes toward time, some are rushed

and punctual, other are relaxed and disregard the clock. Successful

managers, professionals, and students are future or goal oriented.

Productive people have set their priorities and scheduled their time

accordingly.

When current needs demand your attention, whether that is because

the family must be fed or you "must" have a good time with friends,

it becomes harder to carefully plan for the future. Our situation and

needs influence our time orientation, but our time orientation (and

needs) can be changed, leading to more success in life. That is why

scheduling is so important; it enables you to order your use of time

so that you can achieve your goals in life.




Page 5 of 87

Problem Definition

Planner is not a new concept. Diaries, calendars, note books,

appointment books, special schedulers, event planners are used

everywhere for recording events. These days most computer and cell

phone operating systems come with some kind of scheduling

software. Everyone wants to manage time using different tools.

Limitations

We have studied most of the frequently used calendar applications

to understand their merits and limitations.

1. Microsoft Outlook Calendar

2. Google Calendar

3. Yahoo My Page

Both are flooded with functionalities. They have attractive interfaces

and also come with some kind of database conversion facilities.

Microsoft Outlook, for instance, also combines scheduler with email

manager and is very user friendly. So what are the limitations? As per

our observations the primary limitations of these applications are as




Page 6 of 87

follows:

1. Limited access: This is the primary limitation. The application can only be

accessed from the desktop it is installed. In this age when users tend to

access multiple systems during a day, like a computer at home, their mobile

phone while travelling and at a desktop or laptop for personal usage, they

would like to have access to their planner from each of these systems.

2. Platform dependency: Microsoft Outlook is platform dependent. Different

versions would be required to be maintained for different operating

systems like Windows, Linux and Mac OS X.

3. Non intuitive: Since the application is so rich in functionalities, the usage is

less intuitive for a new user. Hence the user needs to spend significant

amount of time learning the different features that the application offers.

4. Too many functionalities insists user to think about its use which also waste

user's time.

5. Though interface is very good its overall arrangement and execution

confuses user.

6. Too much functionality on screen at one time confuses user work priorities.




Page 7 of 87

Need for Computerization

Manual System Consumes Human Time And Energy Because of

Maintenance of Large Number of Documents.

Maintaining all Record about the various Appointments, Addresses,

Links, Tasks, and Reminders Etc. is a very tedious Job.

Process of Validation and Updating is tedious, complicated & Time

Consuming.

Manual System generate voluminous amount of redundant data, which

lead to many Errors.




Page 8 of 87

Scope for the Proposed System

Imagine a business professional carrying things like calendar, calculator,

phonebook, clock, appointment book etc. with him all the time where he

travels but what if you get it on a single page with less efforts? Smart

Planner is a single application for all those features. It makes it easy to

store, manage and organize information. And this information can be as

simple as one line task or reminders.

Objectives

The following are the main objectives for the application to meet:

1. It should be simple and easy to understand as well as operate.

2. The data stored via the planner should be secure.

3. It should facilitate all the basic tasks that a user would expect from a

planner.

Scope

The following would be the scope of the application:

1. User Administration: In user administration user can login using




Page 9 of 87

username and password. New user has to submit username, password

and other details to sign up.

2. Appointment Administration: For appointment administration user has

to submit date, time, and details of appointment. User can delete

appointments that are not required. All appointments can be seen in

one glance using the ‘Show Appointment’ function.

3. Address book Administration: For address book administration user has

to submit name, address, phone no., e-mail address of contact person.

User can delete address book records according to which database will

be updated. User can see all records in one glance using ‘Show

Addresses’ function.

4. Reminder Administration: For reminder administration user has to

submit date, time and details of reminder. User can also delete

unwanted reminders. User can see all reminders in one glance using

‘View All’ function.

The Main screen will contain all these modules.




Page 10 of 87

FACT FINDING TECHNIQUES

The very first and important step in the field o system analysis and

designing is to collect the required information of the system in a detailed

manner. This kind of analysis is called as requirement analysis. This is

supposed to be carried out after the study of the system to understand the

facts regarding the system. There are four fact finding techniques in the

phase of system analysis:

Questionnaires

Interviews

Record Reviews

Observation

We haven’t used first three techniques to f ind facts as this project is not

developed for particular organization and scheduler is not very business

specific task. An independent utility our project was concerned with the

scheduler. So facts are collected by observing and referring various

scheduler patterns and packages. We analyzed arrangement and scope of

the available Linux based business scheduler packages for comparative

study of user friendliness and efficiency.




Page 11 of 87

Hardware and Software Requirement

Below are the requirements for the server:

Hardware

Processor: Any Pentium 4 or higher processor

Memory: Minimum 2 GB or higher.

Available Disk Space: Minimum 20 GB.

Network Connection: 256 MBPS or higher

Software

Operating System: Certified distribution of Linux

Java Runtime: Java EE 5 or higher

Database: MySQL 5 or higher

Web server: Apache Tomcat 5.5 or higher

Below are the requirements for the client:

Hardware

Processor: Any Pentium 4 or higher processor




Page 12 of 87

Memory: Minimum 512 GB or higher.

Available Disk Space: Minimum 20 GB.

Network Connection: 256 MBPS or higher

Software Operating System: Certified distribution of Linux

Web Browser: Mozilla Firefox




Page 13 of 87

Analysis specification:

Class Diagram:

Class:

A class is a description of a set of objects that share the same

attributes, operations, relationships and semantics.

Names: Name must be singular. Every class must have a name

that distinguishes it from other classes. A name is a textual

strings.

Attributes: Attribute is a named property of a class that

describes a range of values that instances of a property may

hold. A class may have any num bers of attributes or no attribute

at all.




Page 14 of 87

Operations: An operation is an implementation of a service that

can be requested from any object of the class.An operation is an

abstraction of something that you can do to an object and that

is shared by all objects of that class.

Use Case Diagram:

Use Case: A use case specifies t he behavior of a system or a part

of a system and is a description of a set of sequence of actions

including variants that a system performs to yield a result of a

value to an actor.

Actor: The actor represents a coherent set of roles that users f

usecase play when interacting with these use cases. Actor can

be human or they can be automated systems, hardware device.




Page 15 of 87

Use case: Every use case must have a name that distinguishes it

from other use cases. A name is a textual string.

System Boundary: It is optional and shown as a rectangle system

boundary distinguishes ‘what’ is inside from what is outside the

system

Activity Diagram:

Initial Activity: This shows the starting point or first activity of the flow.

Denoted by a solid circle. This is similar to the notation used for Initial

State.






Page 17 of 87

lecturer and looking at the blackboard is a parallel activity. This is

represented by a horizontal split (thick dark line) and the two concurrent

activities next to each other, and the horizontal line again to show the end

of the parallel activity.

Final Activity: The end of the Activity diagram is shown by a bull's eye

symbol, also called as a final activity.

.

State Chart Diagram

Initial State: This shows the starting point or first activity of the flow.

Denoted by a solid circle. This is also called as a "pseudo state," where the

state has no variables describing it further and no activities.






Page 19 of 87

state, and on the occurrence of a certain event, go back to the state it was

in when it went into a wait state—its last active state. This is shown in a

State diagram with the help of a letter H enclosed within a circle.

Event and Action: A trigger that causes a transition to occur is called as an

event or action. Every transition need not occur due to the occurrence of

an event or action directly related to the state that transitioned from one

state to another. As described above, an event/action is written above a

transition that it causes.

Signal: When an event causes a message/trigger to be sent to a state, that

causes the transition; then, that message sent by the event is called a

signal. Represented

as a class with the <<Signal>> icon above the action/event.

Final State: The end of the state diagram is shown by a bull's eye symbol,




Page 20 of 87

also called a final state. A final state is another example of a pseudo state

because it does not have any variable or action described.

Sequence diagram

Object: The primary element involved in a sequence diagram is an Object—

an instance of a class. A Sequence diagram consists of sequences of

interaction among different objects over a period of time. An object is

represented by a named rectangle. The name to the left of the ":" is the

object name and to its right is the class name.

Message: The interaction between different objects in a sequence diagram

is represented as messages. A message is denoted by a directed arrow.

Depending on the type of message, the notation differs. In a Sequence

diagram, you can represent simple messages, special messages to create or




Page 21 of 87

destroy objects, and message responses.

Component Diagram

Component: The objects interacting with each other in the system.

Depicted by a rectangle with the name of the object in it, preceded by a

colon and underlined.

Class/Interface/Object: Similar to the notations used in class and object

diagrams

Relation/Association: Similar to the relation/association used in class

diagrams

Deployment Diagram

Node: The element that provides the execution environment for the

components of a system. Depicted by a cube with the name of the object in




Page 22 of 87

it, preceded by a colon, and underlined.

Connection: Similar to the relation/association used in class diagrams to

define the interconnection between nodes.

Collaboration Diagram

Object: The objects interacting with each other in the system. Depicted by a

rectangle with the name of the object in it, preceded by a colon and

underlined.

Relation/Association: A link connecting the associated objects. Qualifiers

can be placed on either end of the association to depict cardinality.

Messages: An arrow pointing from the commencing object to the

destination object shows the interaction between the objects. The number

represents the order/sequence of this interaction.




Page 23 of 87

Design Specification:

Class Diagram:




Page 24 of 87

Object Diagram:




Page 25 of 87

Use Case Diagram:




Page 26 of 87

Sequence Diagram:




Page 27 of 87

Activity Diagram:

Invalid

Valid

Login Page

Valid

User

Display Home

Select a Option from Menu

View Insert Update Delete

Display Table

Stop

Re-enter




Page 28 of 87

State Chart Diagram:




Page 29 of 87

Component Diagram:




Page 30 of 87

Deployment Diagram:




Page 31 of 87

Collaboration Diagram:




Page 32 of 87

Data Dictionary

User:

Field Name Key Status Data Type Description

LoginId Primary key Integer Users ID

Username Text Name of user

Password Text Users password

First name Text First name of User

Last name Text Last name of User

Gender Text Gender of user

Bdate Date Date of birth of User

Address Text First line of address

City Text Name of City

Pin Code Integer Pin code

Phno Integer Phone Number

Mob Integer Mobile Number

Eid Text Email Id

Security Q Varchar Challenge question 1

Security A Varchar Challenge question 2

Appointment:


PK Foreign Key Integer Reference to Login ID

Apno Primary Key Integer Primary key of table

Date Varchar Date of Appointment

Aname Varchar Name of AttendeeTime Varchar Time of Appointment

Location Varchar Place of Appointment

Des Varchar Description of Appointment




Page 33 of 87

Meeting:


PK Foreign Key Integer Reference to Login IDMno Primary Key Integer Primary key of Meetings

Date Varchar Date of Meeting

Sub Varchar Subject of Meeting

Time Varchar Time of Meeting

Place Varchar Place Meeting

Remark Varchar Remarks

Task:



TNo Primary Key Integer Primary key of Task

Fdate Date Starting Date of task

Ldate Date Ending Date of task

Descrip Varchar Description of Task

Address Book:



Adno Primary Key Integer Primary key of addressbook

Name Varchar First Name of Person

Last Varchar Last Name of Person

Add1 Varchar First Address

Add2 Varchar Second Address

Phres Integer Residence Phone No.

Phof Integer Office Phone No.

Phmo Integer Mobile Number

Eid Varchar Email Id

Organizer:




Page 34 of 87



Lno Primary Key Integer Primary key of LinkUrl Varchar U.R.L. of Link

Descri Varchar Description of Link

Reminder:



Rid Primary Key Integer Primary key of Reminder

EventId Integer Event TypeTime Time Time of Reminder

Date Date Date of Reminder

Description Varchar Description of Link




Page 35 of 87

Decision Tools

Decision:-

A decision is a choice about a "course of action". A course of

action may include many individual actions. A decision may be

characterized on a continuum from unstructured to structure.

Unstructured Decisions

Unstructured decisions are generally one-time propositions

taken in emergent situations (Hollsopple and Whinston 1996) [2], i.e. the

sets of conditions are unique and there are no fixed rules for the course of

action to take based on the conditions. The possible courses of action need

not be finite.

Structured Decisions

Structured decisions are predictable, i.e. given a particular set of

conditions; the course of action to be taken is clear and definable. The

choice is which actions to take among a predefined, finite collection of

actions. Making a structured decision is therefore algorithmic. There are




Page 36 of 87

three common methods of expressing these algorithms.

There are three types of decision tool:

1. Decision Tree

2. Structure English

3. Decision Table

Structure English:-

This was the approach taken in the creation of the original

procedural computer language compilers in the 50s and 60s. These

definitions were (and remain) so complex that programmers required

months and even years of training to acquire competence in the syntax and

semantics of the definition. This made it almost impossible to combine

knowledge of the business domain and technical proficiency in the

programming language in one individual.

Less rigorous non-executable Structured English definitions are known as

pseudo code and are used as analytical tools by analysts to create an

intermediate specification. This specification is passed to programmers who

translate it into actual compiler-compliant code. This extra step results in




Page 37 of 87

added expense both because of extra specialist personnel and because of

the inevitable miscommunications and errors involved in an intermediate

translation.

Decision Tables

A decision table is a two-dimensional matrix with one row for each possible

action and one row for each relevant condition and one column for each

combination of condition states. A decision table cans very concisely and

rigorously show complex conditions and their resulting actions while

remaining comprehensible to a human reader.

The first set of rows indicates the possible actions that may be taken. The

most common tool for the creation of decision tables is spreadsheet

software, such as Microsoft Excel. Although this is really quite sophisticated

software, it is cheap, readily available, and has a large base of trained users

Such simple software finally allows the removal of the "3rd

man" in the

analysis-synthesis process, allowing an analyst or even a logic-savvy policy

expert alone to directly create executable code to implement policy.




Page 38 of 87

Testing Strategies

A test strategy is an outline that describes the testing portion of the

software development cycle. It is created to inform project managers,

testers, and developers about some key issues of the testing process. This

includes the testing objective, methods of testing new functions, total time

and resources required for the project, and the testing environment.

The test strategy describes how the product risks of the stakeholders are

mitigated at the test-level, which types of test are to be performed, and

which entry and exit criteria apply.

The test strategy is created based on development design documents. The

system design document is the main one used and occasionally, the

conceptual design document can be referred to. The design documents

describe the functionalities of the software to be enabled in the upcoming

release. For every set of development design, a corresponding test strategy

should be created to test the new feature sets.

Testing Levels




Page 39 of 87

Software testing is usually done at several levels. They are commonly

referred to as unit testing, integration testing, and system testing.

Unit Testing

The objective of unit testing is to verify that individual units -- the smallest

compatible components, such as Java classes -- function correctly. Unit

testing is usually done by programmers.

Unit testing is also called component testing. However, component testing

is sometimes considered to be a level of testing above unit testing. This

may be the case with a system that contains individually testable

components that are composed of multiple units. For example, in a system

that contains Java classes and Enterprise Java Beans (EJBs), the Java classes

could be tested as units, and the EJBs, could be tested as components.

Alternatively, some people distinguish unit testing from component testing

by the degree to which components are isolated. In unit testing, called

components are replaced with stubs, simulators, or trusted components ,

and calling components are replaced with drivers or trusted super




Page 40 of 87

components, so that the component being tested is isolated. In component

testing, all stubs and simulators are replaced with real implementations.

Integration Testing

The objective of integration testing is to test the integration of and

communication between components. Additionally, it may include testing

the integration of subsystems or communication with external systems.

Integration testing may be done by the programmer, but it may also be

done by the build captain, or the team lead, the project manager, or even a

configuration management group.

On some projects, integration testing may be divided into two levels:

assembly testing and system integration testing. During assembly testing,

the integration of the software components is tested. During system

integration testing, the communication with external systems is tested. For

example, on a project to develop a set of EJBs for use by external

applications, assembly testing could be done to test the integration of the

EJBs and the components from which they are built, and system integration




Page 41 of 87

could be done to test communication between the EJBs and the external

applications.

System Testing

The objectives of system testing are to find defects that are attributable to

the behavior of the system as a whole, rather than the behavior of

individual components, and to test that the software functions as a

complete system. This level of testing is different from integration testing in

that the tests are concerned with the entire system, not just the

interactions between components. Other than system functionality and

behavior, system testing may include testing configuration, throughput,

security, resource utilization, and performance.

Test Design

Just as the components of a system must be designed, tests for a system

must be designed. Two common methods of test design are black box

testing and white box testing. After the tests are implemented, though, the

test design method may not be evident.




Page 42 of 87

Black Box Testing

The base of the Black box testing strategy lies in the selection of

appropriate data as per functionality and testing it against the functional

specifications in order to check for normal and abnormal behavior of the

system. Now a days, it is becoming common to route the Testing work to a

third party as the developer of the system knows too much of the internal

logic and coding of the system, which makes it unfit to test the application

by the developer. In order to implement Black Box Testing Strategy, the

tester is needed to be thorough with the requirement specifications of the

system and as a user, should know, how the system should behave in

response to the particular action.

White box testing:

It is a method of testing software that tests internal structures or workings

of an application, as opposed to its functionality. In white-box testing an

internal perspective of the system, as well as programming skills, are

required and used to design test cases. The tester chooses inputs to




Page 43 of 87

exercise paths through the code and determine the appropriate outputs.

This is analogous to testing nodes in a circuit while white-box testing can be

applied at the unit, integration and system levels of the software testing

process; it is usually done at the unit level. It can test paths within a unit,

paths between units during integration, and between subsystems during a

system level test. Though this method of test design can uncover many

errors or problems, it might not detect unimplemented parts of the

specification or missing requirements.




Page 44 of 87

Implementation Strategies

There are many techniques that can be used to test software. Some are

better than others, and some can be used in conjunction with others to get

better test coverage. Here is a summary of some common testing

techniques:

Manual testing - Tests are done by a human with estimated data that

may be predetermined but may also be determined per test. In some

cases, manual testing could be characterized as "banging away" at

the software.

Automated Testing - Tests can be run by a tool or an unattended

process, such as a nightly build, and they can be re-run many times.

Test data is predetermined or generated.

Regression Testing - Tests, usually automated, are run to determine if

modifications or enhancements have negatively affected

functionality that passed previous testing.




Page 45 of 87

Stress Testing - Tests are run to determine if the software can

withstand an unreasonable load with insufficient resources or

extreme usage.

Load Testing - Tests are run to determine if the software can handle a

typical or maximum load or to determine the maximum sustainable

load. Performance Testing - Tests are run to determine actual

performance as compared to predicted performance.




Page 46 of 87

Input Screens




Page 47 of 87




Page 48 of 87




Page 49 of 87




Page 50 of 87




Page 51 of 87




Page 52 of 87




Page 53 of 87




Page 54 of 87




Page 55 of 87




Page 56 of 87




Page 57 of 87




Page 58 of 87




Page 59 of 87




Page 60 of 87




Page 61 of 87




Page 62 of 87




Page 63 of 87




Page 64 of 87




Page 65 of 87




Page 66 of 87




Page 67 of 87




Page 68 of 87




Page 69 of 87

Output Screens:




Page 70 of 87




Page 71 of 87




Page 72 of 87




Page 73 of 87




Page 74 of 87




Page 75 of 87




Page 76 of 87




Page 77 of 87




Page 78 of 87




Page 79 of 87




Page 80 of 87




Page 81 of 87

User Manual

What is Time Planner System?

The Time Planner application is a Web based application for an

Organization. The main aim of this project is to make Scheduling very

easily. The special thing about this project is it provides different

facilities and operations.

How to start?

The software can be used by registered users only. You will have

enter the

userid and password by registering yourself first.

Facilities provided:

Once the user logs in using a valid userid and password he will be

provided with following facilities.

1. Manage Schedule

Adding /Edit/ Deleting Appointment :

Employee can add new Appointment, deletes existing Appointment or can




Page 82 of 87

change existing Appointment

Adding / Deleting / Modifying Task :

Employee can add new Task, deletes existing Task or can change existing

Task.

Adding / Deleting / Modifying Meeting :

Employee can add new Meeting, deletes existing Meeting or can change

existing Meeting.

Adding / Deleting / Modifying Reminder :

Employee can add new Reminder, deletes existing Reminder or can change

existing Reminder.

Adding / Deleting / Modifying Contact :

Employee can add new Contact, deletes existing Contact or can change

existing Contact.




Page 83 of 87

Adding / Deleting / Modifying Links :

Employee can add new Link, deletes existing Link or can change existing

Link.

Create / Modifying /Deleting User Account :

Employee can create an account, delete existing account or can change

existing account.




Page 84 of 87

Limitation and Drawbacks

Currently the System is only accessed on the

INTRANET

The Time Planner system is currently accessed on

Mozilla Firefox.

The current Time Planner System supports only Mysql

Databases.

The current Time Planner System does not have any

Java Framework.

The system is yet to be included in the main module

so still certain issues are still to be taken care of.




Page 85 of 87

Future Enhancement

We can add more features to our module like E-mail

access, Calculator, Calendar utility etc.

The System can be made available on the web so the user

can view the schedule on the web.

We can send reminder by SMS or E-Mail.

User can see the Appointment and Meeting set by other

user for him. Example: If a User A has selected User B for

Appointment, User B can view the date and time set by

User A for him.




Page 86 of 87

Conclusion

The proposed system is very fast and user friendly.

It is very easy to understand.

It is having very good accuracy than the current system.

It is very suitable for Employees.

It is less time consuming.

While doing the project I came to know how JAVA provides net accessing

facility and how to maintained the database from MySQL.

It was really learning experience we have gained through this project.

This was a chance to implement theoretical knowledge into practical work

and to test our ability.

