A PROJECT BY RAMA EMAIL ME AT

[email protected] FOR THIS

PROJECT DIAGRAMS AND MORE…

ROBOTICS

INTRODUCTION

PROBLEM DESCRIPTION

In the present system of sending probes into the earths

atmosphere whether into the inter planetary orbit and into

Inter galactic missions we encounter a wide variety of

Problems. These problems can be faced by many persons

from developer to the system tester who tests the system

For any bugs .Generally we require to take care of different

problems encountered by different people in different walks

of life.

Example:

Generally many probing missions fail due to lack of proper

involvement of team members and due to technical problems

Encountered by testing people also this responsibility rests

With software engineers.

The sequences of the rocket ignition to detaching and to

finally reaching its destination completely must be modeled

with giving any complexity to system.

Due to lack of people with a logical sense many of our missions

have been a failure. The failure percentage

Now must fall down which is the chief aim of the project.

GOALS FOR THE SYSTEM AND PROJECT

• .The first and foremost aim of this project is to model

the defects of a particular system and to enhance the view.

• To model the problems that are encountered by the

Software engineers and other people who are in charge .

• To depict the systems problems and to find efficient

solution.

• To precisely model all the problems faced by developers and

engineers in controlling the probing machine.

• To enhance each and every module such that it leads to

concurrent operation in a probe.

• To visualize and find out technical problems regarding the

machines that control the hardware and technical problems

related to it.

THE GOALS ACHIEVED BY THIS PROJECT:

• To find out technical problems by frequent checks and

by imposing constraints.

• To improve the life time of the probe by minimizing the

hardware faults and software loopholes.

• To introduce a function which deals with security as well

as safety which reports every procedure that occurs

through signals.

• Modularizing the each and every device into its own

category and defining their functions.

• To improvise and enhance the mission life by frequent

checks.

• To check and report back all the activities in a sequence

to the base owner.

Vision Statement :

To establish ourselves pioneers in this industry and to

Improve the quality of the space probe we have introduced

And visualized many methods.

MISSION
To enhance credibility and to promote this concept which is

unique and has its own advantages.

To make space probe control less complex and to make

common people to mingle with in this environment.

To make quality software thereby setting standards in space

probe control.

To complete the mission with comfort (user friendly) and

quality.

To maintain software budget and increase the longevity of the

software.
To specify user requirement and develop accordingly.

SYSTEM STUDY

EXISTING SYSTEM WITH LIMITATIONS :

In the current methodology of sending a probe into space we

encounter with problems like file management and technical

problems due to mal-function. This method is highly

insufficient to fulfill our project requirement rather it is a

very limited view of the project.

Here, we are likely to encounter problems like software

loopholes wherein entire system may crash and may not be

able to reboot.

The data is entirely lost and the purpose of the mission fails.

Any crashes happening with the system are attributes of file

management system which resides within an operating system.

So by incorporating flexibility we have improved the

performance of the software which was previously mal-

functioning.
PROPOSED SYSTEM WITH OBJECTIVES :

• The proposed system currently deals with all the loopholes

in OS which is an essential and most important component

that resides within main memory.

• It is responsible for the functioning of the whole system

and by categorizing each and every devise into its own

group, we have established flow control of work which is

essential and necessary for data to flow.

• We have achieved the concept of concurrency by using

different applications which provides different

implementations dynamically.

• This project is likely to be launched on the satellite which is

ready.
• The concept of data abstraction is clearly implemented

thereby providing security.

• Transparency is more which leads to efficient execution due

to flexibility in software.

FEATURES:

- Latest Technology

- Modular

- Integrated

- User friendly
 - Graphic User Interface

- Easy to Customize

- Secured

- Online Help

- Easy to install

SYSTEM OVERVIEW :

The system has gone through lot of check points during its

developmental stages. Each and every part of the software has

been vividly tested for confirming how it responds to each and

every situation.

The system has gone through rigorous checks including black box

and white box checking which are two essential testing methods

used to check the efficiency of the software.

The entire system on a whole has been vividly categorized based

on its functions and functionalities into modules.

MODULES :

1. SAFETY MODULE

2. SENSOR MODULE
 3. EQUIPMENT MODULE

4. ADMINISTRATION MODULE

5. TRAJECTORY MODULE

6. USER MODULE

Let us explain these Modules one by one in detail.

1. SAFETY MODULE :

This module has been incorporated taking into

consideration the condition of the probe each time it

fulfills the task given by Administrator or User. This

 has been vividly introduced to report successful

detachments from rockets to check whether the

probe has entered into high degree zone or low

pressure zone or a zone well beyond freezing point.

This module is used by the probe to report back to the

base on the earth the status and the current position

of the probe.

2. SENSOR MODULE :
 We know that a sensor is an interface between

hardware and software. So by incorporating this

module we have established a mediator that translates

the current input and output instructions into

successfully implemented hardware statements.

Any device can be activated and deactivated using this

module and also initializations for different

equipments within the probe can be done.

3. EQUIPMENT MODULE :
 There are lot of instrumentations on board of a probe.

All this instruments are needed to calibrate

temperature, photo-sensitivity, pressure, volume, light,

moisture and chemical composition of a particular

planet that it lands on.

Initially it needs to activate required device by

reporting to sensor module after its request has

been granted and this must be reported back to earth.

4. TRAJECTORY MODULE :
 We need to establish a path to a probe which is either

in orbit or in outer space. The sole responsibility of

this module is to take an input from the earth and

redirect the probe accordingly.

Trajectory Module is necessary as it is the primary

module which helps in determining the status of the

path of the probe. All the decisions regarding the

path that the probe follows are decided by this

module.

5. ADMINISTRATION MODULE :
 This module is used by the Project Director to

monitor each and every function of the probe including

its path, velocity, temperature etc. and decisions

which are favourable to the mission are taken

instantly. The Administrator has all rights to change

and redirect the probe as necessary. So this is the

primary module which controls each and every function

that exists.

The Administrator is the person who updates, deletes,

inserts, values, new parameters into the project.

6. USER MODULE :
 This is the module which has been developed

exclusively for the person who monitors the actions

of the probe but has no authority to change its path,

temperature etc.

Here his necessity is met by reporting the data back

to Administrator who in turn redirects the probe into

a safe condition.

FEASIBILITY STUDY :
As this system has been developed using wide variety of

softwares, it is compatible which each and every OS that is

available in our market.

The compatibility issues have been given a fare consideration and

this project has been developed in Java which a platform of

independent nature.

This project nearly infuses and dissolves with every possible

system of arrangement of files, systems that are available upto

date.
 ADMINISTRATOR USER
E-R DIAGRAMS
REPORT LOGOUT
LOCK VIEW MODIFY
ROUTE REPORT DETACH CONNECT CONNECT
DECIDE CHECK INITIALIZE VERIFY VERIFY
TRAJECTO SAFETY EQUIPMENT USER ADMINISTRATOR
RY
LOGIN PAGE
HOME PAGE
ROBOTICS
SYSTEM FLOWCHARTS
III SYSTEM ANALYSIS
 PERMISSIONS

SENSOR

CONTROL

ACTIVATE DEACTIVATE

EQUIPMENT

TRAJECTORY REPORT LOGOUT

DATA-FLOW DIAGRAM (DFDs)

Data flow diagrams (“bubble charts”) are directed graphs in which the
nodes specify processing activities and the arcs specify data items
transmitted between processing nodes. A data flow diagram might
represent data flow between individual statements or blocks of
statements in a routine, data flow between sequential routines, data
flow between concurrent process, or data flow in a distributed
computing system, where each node represents a geographically
remote processing unit.
 Unlike flow charts, data flow diagrams do not indicate decision logic
or condition under which various nodes in the diagram might be
activated.

Data flow diagrams can be expressed using special symbols. These

symbols can be used to denote processing nodes, data nodes, and data
sources and data stores.

Data Flow

Processing Node

Source or Destination

Data Store

LEVEL – 0

MEASURE
Administration
CONTROL TAKE IMAGES

CONTROL EQUIPMENT
DECIDE

GUIDE
INSPECT ROBOTICS

RECEIVE INFORMATION
REPORT

ENA BLE
MODIFY
SAFETY

REDIRECT
DISABLE

LEVEL – 1
 LOAD

INITIALIZE
TAKE DECISION

REPORT
STORE DATA

CONNECT EQUIPMENT

SEND TO EARTH
VISUALIZE

CREATE CHECK POINT

LOG OUT

LEVEL – 2
 CALCULATE

DECIDE CALIBRATE

ROUTE
SAVE

TRAJECTORY
FINALIZE
COMPARE

REPORT
EXECUTE
 LEVEL – 3

LOG IN
VIEW

CHECK INITIALIZE

USER

LOGOUT

REPORT
REQUIREMENT SPECIFICATIONS

This Software Requirements Analysis is base on System

Definition. System Requirement Analysis is s preliminary

user’s manual, which is primarily concerned with the user

and external view of the project. In contrast, the Software

Requirement Analysis is as technical specification of

requirements for the software project. The goal of

software requirement definition is to completely and

consistently specify the technical requirements for the

software products using formal notations as appropriate. So

this can include data flow analysis and data modeling. These

were developed using CASE tools.

USE OF CASE TOOLS:

CASE provides the Software Engineer with the ability to

automate manual activities and to improve engineering

insight. Analysis and design tools enable a software engineer

to create a model of the system to build and also evaluate

the model quality.

It is not possible to specify a problem completely at an

early stage. Prototyping offered and alternative approach

that results in an executable model of the software from

which requirements can refine. CASE tools can be used to

properly conduct prototyping. The CASE tool, turbo analyst

has been extensively used in analyzing the requirement

formally and in identifying any gaps or inconsistencies in the

analysis as well design tasks. They also help in

documentation process.
DATA FLOW ANALYSIS:

A Data Flow Diagram (DFD) is a graphical technique that

depicts information flow and transforms that are applied as

data move to represent a system or software at any level of

abstraction. Data Flow Diagram may be partitioned into

levels that represent increasing information flow and

functional detail. The notation used to create a DFD is

illustrated in the given as:

1. PROCESS:

A Process transforms incoming data flow(s) into outgoing

data flow(s).
2. EXTERNAL ENTITY:

An External Entity is a system element (hardware a

person) that produces information for transformation by

the software or received information produced by the

software.

3. DATA STORE:

A repository of data for the use of one or more process.

4. ARROW (  ):

A data item or collection of data items, the arrowhead

indicates the direction of data flow.

DATA MODELING:

Data Model is a collection of connected tools for describing

data, data relationship, data semantics, and constraints.

Data modeling focuses on data representing a “Data

Network” that exists for a given system.

Data Modeling is using for applications in which data and

relationships that govern the data re complex. Unlike the

structured analysis approach, data modeling considered

data independent of the processing that transforms the

data. It is provides the database analyst and designer with

the insight into data and the relationship that governs the

data.

The basic concept used in E-R model is Entity, Attribute

and Relationship. The definitions of these concepts are

given below:

- ENTITY:

An Entity is a thing (Object, Concept) being capable

of an independent existence and which can be

uniquely. It is represented by a rectangle in the E-R

model.
- ATTRIBUTE

An attribute is property of entity

- RELATIONSHIP

A Relationship and association between two (or

more) Entities, it is represented by diamond shaped

box in the E-R model.

 IV SYSTEM DESIGN

In general the design of any information system produces

the details that state how a system will meet the

requirements identified during systems analysis. Usually the

design process beings by identified reports and other

output the new system will produce. Design of the system

also describes the data to be input, calculated or stored. It

is a very important point that the designers should note is

that they are responsible for providing programmers with

complete and clearly outlines software specifications.

Considering the areas identified in analysis various tables is

designed with the following structures. It should be noted

that bottom-up approach is followed while designing the

tables and it is ensured that all tables are in third normal

form. The tables and their structures design of software

involves concerning, planning out, and specifying the

externally observable, characteristics of a software

product. We have data design, architectural design and user

interface design in the design process. These explained in

the following sections.

The goal of the design process is to provide a blue for

implementation, testing and maintenance activities.

REQUIREMENT SPECIFICATIONS

This Software Requirements Analysis is base on System

Definition. System Requirement Analysis is s preliminary

user’s manual, which is primarily concerned with the user

and external view of the project. In contrast, the Software

Requirement Analysis is as technical specification of

requirements for the software project. The goal of

software requirement definition is to completely and

consistently specify the technical requirements for the

software products using formal notations as appropriate. So

this can include data flow analysis and data modeling. These

were developed using CASE tools.

DATABASE DESIGN

The primary activity during data is to select logical

representations of a data object identified during

requirements analysis and software analysis. A data

dictionary explicitly represents the relationships among

data objects and the constraints on the elements of the

data structure. A data dictionary should be established and

used to define both and program design. The data dictionary

for the system is in schema.

Size of a database can be estimated as the sums of all

field’s lengths and tables given as: As per the transaction

details of each registered user & shopping sites and total

number of users.
NORMALIZATION

Database is normally implemented by using package called a

Data Base Management System (DBMS). Each particular

DBMS has somewhat unique characteristics, and as such,

general techniques for the design of database are limited.

One of the most useful methods of analyzing the data

required by the system for the data dictionary has

developed from research into relation database, particularly

the work of E.F. Codd. This method of analyzing data is

called “NORMALIZATION”. UN normalized data are

converted into normalized data by three stages. Each stage

has a procedure to follow.

The first stage in normalization is to reduce the data to its

first normal form, by removing repeating item and showing

them as separate records but including them the day field

of the original record.

The next stage of the reduction to the second normal form

is to check that the record, which one is the normal form,

all the items in each record are entirely dependent on the

day of the record. It a data item is not dependent on the

key of the record, but the data item, and then it is removed

with its key to form another record. This is done until each

record contains data items, which are entirely dependent of

the key of the record.

The final stage of the analysis, the reduction of third

normal form involves examining each record, which one is in

second normal form to see whether any items are mutually

dependent. If there are any of them they are removed to

separate record leaving one of the items behind in the

original record and using that as the key in the newly

created record.
 DATA DICTIONARY
USERS

FULL NAME DATA TYPE DESCRITPTION PURPOSE

NAME
User User Id Varchar2(30) Primary key It is used to
store user
identity
Password Password Varchar2(30) It is used to
store the
user
password
Verify Verify Number(6) It is used to
store
identity
User name UserName VarChar2(30) It is used to
store user
name
Permissions Permissions VarChar2(30) It is used to
store user.
Department Dept NO Number(6) Ref from dept table It is used to
number store user
departement
number
Phone Phone Number(20) It is used to
store phone
number of
the user
Address Address VarChar2(100) It is used to
store
address
Fax Fax Number(20) It is used to
store fax
number
Email_id Email_id Varchar2(30) It is used to
store email-
id
City City Varchar2(20) It is used to
store city.
 EQUIPMENT

FULLNAME NAME DATA DESCRITPTION PURPOSE

TYPE
Equipment Equipment Number(6) Primary key It is used to
number number store
equipment
number
Equipment Equipment Varchar2(30) It is used to store Equipment
Type Type cameras etc. Type

SENSOR

FULL NAME DATA TYPE DESCRITPTION PURPOSE

NAME
Sensor Id Number(6) Primary key It is used to
identity store
identity
Name Name Varchar2(30) It is used to
store the
name
Description Description VarChar2(50) It is used to
store
description
of the
sensor
 DATA DICTIONARY
USERS

FULL NAME DATA TYPE DESCRITPTION PURPOSE

NAME
User User Id Varchar2(30) Primary key It is used to
store user
identity
Password Password Varchar2(30) It is used to
store the
user
password
Verify Verify Number(6) It is used to
store
identity
User name UserName VarChar2(30) It is used to
store user
name
Permissions Permissions VarChar2(30) It is used to
store user.
Department Dept NO Number(6) Ref from dept table It is used to
number store user
departement
number
Phone Phone Number(20) It is used to
store phone
number of
the user
Address Address VarChar2(100) It is used to
store
address
Fax Fax Number(20) It is used to
store fax
number
Email_id Email_id Varchar2(30) It is used to
store email-
id
City City Varchar2(20) It is used to
store city.
 EQUIPMENT

FULLNAME NAME DATA DESCRITPTION PURPOSE

TYPE
Equipment Equipment Number(6) Primary key It is used to
number number store
equipment
number
Equipment Equipment Varchar2(30) It is used to store Equipment
Type Type cameras etc. Type

SENSOR

FULL NAME DATA TYPE DESCRITPTION PURPOSE

NAME
Sensor Id Number(6) Primary key It is used to
identity store
identity
Name Name Varchar2(30) It is used to
store the
name
Description Description VarChar2(50) It is used to
store
description
of the
sensor
INPUT/OUTPUT FORM DESIGN

INPUT DESIGN

Inaccurate input data are most common cause of errors in

data processing. Errors entered by user can be controlled

by input design. Input design is the process of converting

user-originated inputs to computer-based format. In the

system design phase the expanded data flow diagram

identifies logical data flows, data stores, sources, and

destinations. A systems flowchart specifies master files

(data base), transaction files, and computer programs; Input

data are collection and organized into group of similar data.

Once identified, appropriate input media are selected for

processing.
The goal of designing input data is to make data entry as

easy, logical and free from errors as possible. In entering

data, users need to know the following:

o Users should feed proper data into wherever

necessary for example if user has to entering product

price then he should enter numbers rather than

character. Any way in this project I took care of this

thing by checking what type of data is entered into

each filed before storing.

o Proper care has taken in formatting date data type

that is when date is stored into database it is stored

in one format where as when displaying date it is

displayed in other format as required by situation.

o I tried my best not store data into database without

validating.
 OUTPUT DESIGN

Output design is the process of converting the already

existing Data in the system and presenting it to the user or

client according to the required format. Designing includes

automatic billing system, automatic generation of receipts,

preparation of reports and other necessary screens. All the

information stored at input stage is recalled from the

backend server and the screens are developed.

SCREEN FLOW OF PROJECT:

V SYSTEM TESTING AND QUALITY ASSURANCE

SYSTEM TESTING

As more critical function in business organization activities

are automated ,mare trust is being automated system.this

realization put an ever increasing burden on system analysts to

ensure that the quality of the system they developed is adequate

.the quality of the system depends on its design, development,

testing ,and implementation .weaknesses in any areas will seriously

jeopardize the quality.

Designing reliable systems

A system is said to be reliable i.e it does not produce un

expected failures when it is used expected is normal .there are

two levels of reliability .the first if that thee system is meeting

right requirements , for instances ,a system ,a system might be

requirements for instance a system a system might be expected

to have specific security features or control built into the system

by the users. If the design fails to specify them and permit the

loss of funds or merchandise for a lengthy time before someone

detects the problem ,the system is reliable . the second level of

reliability involes the actual working of the delivered to the user.

The type of integration is independent on the application under

development.

TESTING

No system is ever perfect .communication problem

,programmer’s negligence or time constraints create error that

must be eliminated before delivering the system to the users . a

system is tested for on –line response, volume of transaction

,stress recovery from failure and durability.

The common view of the testing held by users is that its

performed to prove that there is no error in the program

.however ,as indicated earlier ,it s virtually impossible ,since

analysts can not prove that software is free from all possible

error. Therefore testing usually means the process of executing

the program with an intention of finding errors i.e. making the

program fail. A successful test case is one that finds an error

TESTING STRATEGY

Considering from the procedural point of view ,testing is

actually a series of three steps that are implemented sequentially

.initially, testing focus on each module individually, ensuring that

it function properly as a unit .hence ,it is called unit testing next

,module must be assembled or integrated to form the complete

software package .after the software has been integrated to

form the complete software package .after the software has

been integrated a set of high order that software meets all

function, behavioral, and performance requirements .system

testing verifies that all elements mesh properly and that overall

system function /performance is achieved

 UNIT TESTING:

Unit testing mainly focused verification effort on the

smallest unit of software design-the module .using the design

document ,important control paths are tested to uncover error

within the boundary of the module .all independent path through

the control structure are exercises to ensure that all statements

in an module have been executed at least once And finally all

error –handling path are tested.

INTEGRATION TESTING:

Integration testing is a systematic technique for

construction of the program structure while at the same time

conducting testing to uncover testing module and build a program

structure has been dedicated by the design there are two types

viz,top-down integration and bottom –up integration

 TOP-DOWN INTEGRATION

Top-down integration is an incremental approach to the

construction of the program structure .modules are integrated by

moving downward through the control hierarchy, beginning with

the main control module through the sub ordinate module.

BOTTOM UP INTEGRATION

Bottom –up integration testing as its name implies ,begins

construction and testing with atomic modules , modules at the

lowest level0 and moving towards the higher modules.

The type of integration is independent on the application under

development
VALIDATION TESTING

At the combination of integration testing, software is

completely assembled as a package ,interfacing errors have been

uncovered and corrected, and a final series of software tests-

validation testing–may begin. This mainly concentrates on the

software requirements specification – a document that describes

all user-visible attributes of the software

SYSTEM TESTING

System testing is actually a series of different test whose

primary purpose is to fully exercises the computer –based system

.although each test has a different purpose ,all work should

verify that all system elements have been properly integrated

and perform allocated function.

RECOVERY TESTING

Recovery testing is a system test that forces the software to

fail in a variety of ways and that recovery is properly performed.

SECURITY TESTING

Security testing attempts to verify that protection

mechanisms built into the system.

STRESS TESTING

Stress testing executes a system in a manner that demands

resources abnormal situation to test effectively the developer

may have to generate abnormal test cases.

PERFORMANCE TESTING

Performance testing is designed to test the run –time

performance of software within the contest of the integrated

system .this testing occurs throughout all steps in the testing

process .even at the unit level, the performance of an individual

module may be testing.

QUALITY ASSURANCE

Quality Assurance is the review of the software product and

related documentation for completeness, correctness, reliability

and maintainability. It includes the assurance that the system

meets the specification and the requirements for its intended

use and performance .for system to be available ,control have to

be developed ensure a quality product there are three levels in

quality assurance.

TESTING :

In system testing the common view is to eliminate program

error. The test strategies explained are used.

VALIDATION :

System validation checks the quality of the software in both

simulated and live environment .first the software goes through a

phase in which errors and failures based on simulated user

requirements are verified and studied .the modified software is

then subjected to phases two in the actual users site or a live

environment.

CERTIFICATION :

This level of quality assurance is to certify is to certify that

the program or software package is correct and conform to

standards.
 VI SYSTEM SECURITY

Security is given very much concern in this company. This

company locks out for the database, security and it also

looks out for authorization maintenance. System

administrator is done by the DBA who is an experienced

prison to look after all these works. He is concerned with

the administrative security. Unauthorized access of

software resources is checked by the system DBA.

PHYSICAL SECURITY:

Physical security is maintained by having the back up of all

the data that is needed for the project to run.

OPERATING SYSTEM SECURITY:

The platform that we are using is Win NT which is

protected made kernel and this given the program to run on

its won protected made ,which makes project to be handled

on its own resources and which also works as the client in

many cases. Apart from all these Win NT has its own kernel

made security and administrator’s level security. This

effectively manages the server program.

APPLICATION LEVEL SECURITY:

Application maintains the security by handling clients

request properly which makes it to be very efficient at

critical time .the project makes to be very reliable at

crash time. Thus not have efficient security concerns.

 VII CONCLUSIONS

LIMITATIONS:

1. This project is an intra net and after some

modification we can make an inter net project

i.e. in this project the customers are not

allowed to view the details and they are not

give the user id so it is an intra net but after

we giving the permission to the user i.e. his

own user id and password it will become

internet

2. The other limitation in this project is agents

are not added the customers will do there

work by them self’s and the company will be in

 direct contact with the customers so it will be

difficult for the company to handle so many

customers.

3. The other limitation is that there is no

automatic mailing facility to the customer’s

i.e. if the premium date is coming the user

i.e. the customer should get an intimation that

he should pay the premium money

4. The last and finial limitation in the project is

if a person is taking a policy for his child who

is still a minor there is no facility for this case

in this project but can be easily over come by

this limitations.
 SCOPE FOR FUTURE WORK

This system is ever ready to attend the following needs of

future:

- Interaction with external software.

- Cross platform functionality.

- Facility to send any report by E-mail.

- Web enabling of policy’s information, so that users

can retrieve the information on the web.

- Any other feature that client needs.