Project Report Toshan

An Annotation Tools Base Line Methods Information Extraction from Repair Guides
Chapter 1
INTRODUCTION
1.1 BACKGROUND
Since the emergence of the earliest writing systems, textual instructions have always
been among the most ubiquitous means of transferring procedural knowledge.
Nowadays, free instructions are available on the Web for numerous tasks of human
life, be they easy every-day hacks, recipes, or professional-level instructions on using or
repairing technical devices of the highest complexity. For the latter, instructions
might be written in a complex and technical style, and they, in general, often use situated
language (Malmaud et al., 2014). The instructional text is regularly divided into
multiple steps, which should be performed in a specified sequence. Consequently, there
could be a sequence of objects that the person interacts with during the process.
Extract- ing such practical information from text presents a unique challenge in the
domain of information extraction (IE).
The type and structure of the extracted information also de- pend on the characteristics
of the task and the intended use of the information. In this work, we focus on IE from a
highly complex type of instructions: repair manuals. More specifically, we focus on
extracting the pieces of information that a collaborative repair assistant would benefit
most from, in order to support a human in a repair task.
A fruitful collaboration among agents depends on multiple prerequisites, one of
them being sufficient shared knowledge among the agents. Many researchers have
stressed the importance of shared knowledge and representation structure in
cooperative situations (Grice, 1975; Salas et al., 1995). In our case, we are mainly
interested in how this information builds up and is spread across the different steps as
well as across the different sentences in a single step. More precisely, we focus on the
sequence and identity of the required tools and disassembled parts during the repair
process. This information can help to estimate the state of the task and workstation
environment, serving as the “sit- uational context” of task-oriented dialogue, as it is
defined in Deutsch (1974).
When a task-oriented collaboration involves objects in the shared workspace of
the agents, an essential communica- tive function is resolving the partner’s references
to objects in the environment. Wilkes-Gibbs and Clark (1992) indicated that when
people collaborate on referring expressions, they issue full noun phrases initially,
after which they begin to shorten the phrases. Thus, in the process of repair, one
could say “Give me the T8 Torx screwdriver”, and then “Give me the screwdriver”,
or just “next one”. In such situations, the task knowledge helps the partner to
anticipate the required objects and disambiguate the references, so that the speaker
can be less explicit in referring expressions (Whitney et al., 2016). Generally, when the
agents share a common source of knowledge, such as the task instructions, it can be
expected that their cooperation becomes smoother and more intuitive.
GCoE Computer Department 1

1.2 MOTIVATION
Today’s world is an era of accelerated technological progress characterized by new
innovations whose rapid application and diffusion typically cause an abrupt change in
society. The evolution of computer, mobile, networks, the devices that run on them and
their everyday services occur at an amazing rate. It is unthinkable to consider our lives
without mobile phones. Mobile phones have been one of the most successful
technologies ever invented and adopted in the ever-developing world. Apart from
making everyday life easy, mobile phones, computers and internet are most common
weapons used by criminals to commit heinous crimes (McSweeney, 2020). These
weapons are commonly collected evidences in cybercrimes that are examined by
investigators. Sometimes criminals intentionally damage their mobile phones and
computers to destroy the evidence. Therefore, it’s becoming more challenging for an
investigator/ examiner to extract data from the evidences (Dongan & Akbal, 2017).
1.3 PROBLEM DEFINITION

To create assistance systems that are capable of supporting humans autonomously in new
tasks, it would be immensely productive, if machines were enabled to extract task
knowledge from such text instructions. In this paper, we, therefore, focus on
information extraction (IE) from the instructional text in repair manuals. This brings
with it the multiple challenges of information extraction from the situated and technical
language in relatively long and often complex instructions. To tackle these challenges,
we introduce a semi-structured dataset of repair manuals. The dataset is annotated in a
large category of devices, with information that we consider most valuable for an
automated repair assistant, including the required tools and the disassembled parts at
each step of the repair progress.
1.4 SOLUTION
In our approach we used we introduce a semi-structured dataset of repair manuals. The
dataset is annotated in a large category of devices, with information that we consider
most valuable for an automated repair assistant, including the required tools and the
disassembled parts at each step of the repair progress. We then propose methods that
can serve as baselines for this IE task: an unsupervised method based on a bags-of-
n-grams similarity for extracting the needed tools in each repair step, and a deep-

learning-based sequence labeling model for extracting the identity of disassembled parts.
These baseline methods are integrated into a semi-automatic web-based annotator
application that is also available along with the dataset.
1.5 OBJECTIVES AND SCOPE

However, nowadays all mobiles phones are securely encrypted with full disk encryption
(FDE) or file-based encryption (FBE) which makes chip-off forensics an improbable
process to successfully retrieve data. In many of these cases, the encryption is on the
hardware and hence, the device could be successfully decrypted by bringing it in its
original condition. Thus, the original user data can be obtained for investigative
purposes. This process can be enabled by replacement of electronic parts of the original
device which contains user data and decryption keys i.e. PCB to the new host. This
research paper covers a case study of a mobile phone obtained in broken and shattered
condition whose diagnosis of PCB and subsequent actions led to data recovery.

Chapter 2
LITERATURE SURVEY
2.1 PHYSICAL SURVEY

DATA COLLECTION
We gathered the manuals from iFixit along with their meta- data in JSON-like objects,
where each document has self- explaining tags regarding the Title, Category, a list of
all required tools provided by the instructor, which we refer to as the Toolbox, a list of
Steps, and a derived list of hierar- chical categories for the device (Ancestors). In most
cases, the instructors show step-by-step procedures for opening the device and
removing or repairing a broken component. Since reassembly is usually the reverse of
disassembly, it is not included in the guides of iFixit. Each step has an attribute Lines,
which contains the text description of the step and, if available, the attribute Image with
the link(s) to the provided image(s). The fact that 98.7 % of the steps have one or more
images also makes this data suitable for multi- modal studies. Figure 1 shows an
instance of the dataset, including the extra tags we added to the data that contain the
annotated information in this work.
DATA STATISTICS
In total, 31,601 repair manuals were collected from the iFixit API in 15 basic
categories, see Figure 2. There is a high variation in the number of steps
(average=9.68, median=7.00, variance = 109.95), depending on the category of the
device and the difficulty level of the task. However, there is less variation in the
number of tools pre-specified in the toolboxes, where the average number is 2.42 tools
per manual with median is 2.00 and variance is 3.98.

2.2 WEB BASED SURVEY
Figure 1: Number of collected manuals in different device categories.
This selection was due to it having the highest average number of steps and tools per
manual, 24.5 and 4.3, respectively. With an approximate estimation based on the
specified level of difficulty and the required repair time in iFixit, these devices
appeared to be among the most complicated devices for repair. One should note that
in iFixit, the instructors often copy the text description of some steps from other
manuals in order to create a new guide, and hence, there are steps with identical text
descriptions. In fact, there are 4,350 steps with unique text descriptions in this category.
There- fore, we manually annotated the steps with unique text descriptions and then
applied the same annotation to the steps with identical text. Table 1 shows the statistics
of annotated data.

Chapter 3
SYSTEM ANALYSIS
3.1 PROPOSED SYSTEM

The Forensic Science Laboratory in Chandigarh received one broken and damaged
mobile phone (Samsung, Model: SM-N975F/DS) with chipset- Exynos 9825 (Fig.1),
forwarded by investigation authority in a condition where it was unable to boot or be
charged. The chip-off technique was not suitable to retrieve the data of the exhibit due to
the higher Android version, which might extract the data in an encrypted form. When a
closer look was taken at the motherboard, it was found that the motherboard was in good
condition as all its parts were appropriately located (Fig.2). The device was reassembled
and kept for charging. However, no sign or indication of charging was observed. The
device was disassembled and a closer look was taken at the PCB. The preliminary
examination of the PCB board showed a short circuit in its internal side.

Figure 1: Damaged Samsung Mobile Phone as delivered to the laboratory
Figure 2: Parts of the Damaged Mobile Phone after Disassembling the Device
The mobile phone (Fig.3) (Wiens & 19 other contributors)Samsung, Model: SM-
N975F/DS, had two layered motherboard, like a silicon sandwich (Fig.4) (Wiens & 19
other contributors). This mobile device was then repaired using the forensic repair tool
kit that restored the device in its working condition and data extraction became possible.
3.2 METHODS AND MATERIAL

The materials employed for repairing of the device are readily available in a forensic
repair tool kit including the screws, screw removers, forceps, brushes, cleaners, etc.
Step wise procedure followed by the study:
Whenever any mobile phone is subjected to data extraction, standard laboratory

procedures and standard hardware/software are utilized. For this study, we have used
forensic repairing Tool Kit and Universal Forensic Extraction Device by Cellebrite.
Case opening:
The case was received from a messenger in sealed condition. The parcel was
appropriately marked. The parcel contained one mobile phone of Samsung, Model:

N975F/DS (in Broken and Damaged condition). The mobile phone was appropriately
marked/ tagged for identification.
Manual/ Physical Examination:
As the device was found in damaged condition, the device was physically examined with
the help of a microscope after examining through naked eyes. The device was taken
apart, into pieces by unscrewing it. Except motherboard every part of the device was
damaged i.e. the screen, back panel, screen parts, etc. were all broken. Data extraction
was possible for this mobile device by repairing it. Hence, materials for repairing were
required. New screen combo was purchased for the device and all the parts of the
exhibit were transplanted and installed with the new screen combo. The mobile phone
was kept for charging but it showed no indication for the process. Hence, a look at PCB
was taken as the theory pointed towards a possible PCB short-circuiting.
3.2 FEASIBILITY STUDY

The main objective of feasibility study is to test the Technical, operational and
economical for adding new modules and debugging old running system. All system is
feasible for adding new modules and debugging old running system.
There are aspects in the feasibility study portion of the preliminary investigation:
 Technical feasibility
 Economic feasibility
 Operational feasibility
3.1.1 TECHNICAL FEASIBILITY
This study is carried out to check the technical feasibility, that is, the technical
requirements of the system. To develop this system, we first worked with web
applications and then it would be technically feasible. The requirements here are very
modest because the system here supports very basic window version which is 8 and
above. So, this system is technically feasible because it needs only window with a basic
version.

HARDWARE COSTS
A 19”DISPLAY LCD 10,200/

MONITOR(COLOR) -
Multimedia keyboard 800/-
Optical mouse.. 400/-
160GB HDD 1850/-
2GB RAM(DDR 2) 2300/-
A Pentium D(2.8ghz)processor 7000/-
A intel chipset motherboard(915) 8000/-
SOFTWARE COSTS
HTML, CSS, JAVA SCRIPT 5000/-
MONGO DB FREE
3.1.2 ECONOMICAL FEASIBILITY
ECONOMICAL FEASIBILITY is one of the most important factors while

evaluating the effectiveness of the system. If the system would be too costly it would not
be acceptable.
The fully computerized will reduce the man hours And overhead by simplifying by today
activities. Thus the computerized system is beneficial for anyone & so it is economical
feasible. It can be done with help of COCOMO Model known as constructive cost
model.

Economical feasibility using COCOMO Model:
Ab Bb Cb Db
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Calculation
KLOC=3.0
Effort per Month (E) = ab*(KLOC) ^bb
= 3.6*(3.0) ^1.20
E = 13.45(approx) person- Month
Development Time(D)=cb*(E)^db
=2.5*(13.45) ^0.32
=5.74 month
No. of Team Members = E/D
= 13.45/5.74
= 2.89
=~3 person’s approx
For personal cost we did the following calculations:
Generally the computer engineer has Rs.16000 salary per month, therefore
1 month = Rs.15000
Per day he works only 8 hours
Therefore 30*8=240 hours
He works 240 hours per month
Therefore,
15000/240=Rs 66.6 for 1 hour
We are three project partners. We work for 5 hr a week i.e. 5 weeks a month

3.1.3 OPERATIONAL FEASIBILITY
The aspect of the study is to check the level of acceptance of the system by the
user. This includes the process of training the user to use the system efficiently. This
system will not threaten the user instead it is friendly in its operation.
i. August Month
1.Feasibility Study
2. Analysis of
Modules
3. Inclusion of
Modules
4. Compilers
Survey

ii. September Month
Work Tasks Week 1 Week 2 Week 3 Week 4
1.Rough Sketch of
GUI
2. Researching of
Communication
Process
3. Study of servlets
and TCP/IP Comm.
4. Preparation of
basic module
iii. October Month

. Work
Week 1 Week 2
Tasks
1.Creation of UML
diagrams of the
design
2. Preparation of
presentati


Chapter 4
SYSTEM REQUIREMENT SPECIFICATION
4.1 HARDWARE REQUIREMENT

1. Computer or Laptop.
4.2 SOFTWARE REQUIREMENT

1.Windows OS- Computer operating system (OS) developed by Microsoft Corporation to
run personal computers
2. Javascript- The Javascrip is use for popup front end.
3. HTML, CSS - It is a language use to develop a code of website.
4. Mongo DB- It is an local Database where the data is stored in the form of tables.
4.3 FUNCTIONAL REQUIREMENTS
It mainly analyzes the student record and gives criteria to acquire the performance.
4.3.1 EXTERNAL INTERFACE REQUIRMENTS
4.3.1.1 User Interfaces
1. All the contents in the project are implemented using Graphical User Interface (GUI).
2. Every conceptual part of the projects is reflected using the Data mining.
3. System gets the input and delivers extracted knowledge that describes students'
behavior.
4.3.1.2 Software Interfaces
1. Using Java Script we have created popupfrontend tool design and React JS for
coding.
2. Mongo DB database is used for back end to store the exam result and retrieve in the
graph view.

4.4 NON FUNCTIONAL REQUIREMENTS
Data Mining is the concept of getting the needed information from the large datasets. It
is one of the steps involved in Knowledge Discovery in Database. The other steps in
Knowledge Discovery in Database such as Selection, Transformation, Interpretation,
Preprocessing.

Chapter 5
SYSTEM DESIGN
5.1 SYSTEM ARCHITECTURE
Customer Customer Mobile Information Cluster analysis
Personal Details Mobile Handset

Assessment
Processing of
Data
Fig 5.1: System Architecture
In the architecture, once Customer login to website list of possible Mobile

Problems are displayed, and then Suitable Problem will be consider of the registered
customer, after processing the cluster analysis will be carried out and result will display
in the form of graph i.e. Customer Mobile Configuration Assessment.
5.1.1 MODULES
1. Signing up
Creating a User account is the first step for anyone to access the website. New
users should choose the signup option in the launcher page and provide the necessary
details and register into website.

2. Login Screen
Once the user is registered they can use the username and password to log into the
website for further Mobile Assesories will be display for Solving Problem issue of
Mobile.
3. Entering the name
Once the valid user enters into website, it ask for name to be identified in the list
of available users .
4. Database
The Database would contain the list of available Problems of Mobile. The
details stored as, username and password for an authentication. After solving the issue of
Mobile details stored in the database are retrieved in the form of graph.
5. Processing
In the beginning of the case, the forwarding authorities were stumped by the ingenious
planning of the smugglers who had left no clues behind that could directly connect them
to the crime. The suspects had already managed to destroy any implicating evidence of
the crime and had even tried to destroy their mobile devices. However, the innovative
and industrious efforts of the scientific officers of the case enabled a complete
restoration of the mobile device. The forwarding authority’s invaluable support by
providing the password and an intricate work in repairing the device by the scientific
officer led to the successful solution of the case.
6. Exit
To close the app, the user should select the exit option from the main
layout.

5.2 FUNCTION DESIGN:
5.1.1 DFD: (Data Flow Diagram)
Mobile Handset
Mobile Configuration
Customer
ASSESSMENT
Fig 5.1.1: 0 Level DFD

Start
Get username and

password
No Authenti Yes
cation
Display error message Display list of

Mobiles Phones
Mobile Repairs Problem
Solution to Repair
Mobile Handset
End
Stop
Fig 5.1.2: 1 Level DFD

5.3 PHYSICAL DESIGN:
5.3.1 Decision Tree
Fig 5.2.1: Decision Tree
5.3.2 Decision Table
Table 5.3.2: Decision Table

5.3.3 Data Dictionary
Fig 5.2.2: Data Dictionary

Fig 5.2.3: Waterfall Model
This phase started at the beginning of our project, we had

formed groups and modularized the project. Important points of
consideration were
1 Define and visualize all the objectives clearly.

2 Gather requirements and evaluate them.
3 Consider the technical requirements needed and
then collect technical specifications of various
peripheral components required.
4 Analyze the coding languages needed for the
project.
5 Define coding strategies.
6 Analyze future risks / problems.
7 Define strategies to avoid these risks else define alternate

solutions to these risks.

8 Check financial feasibility.
9 Define Gantt charts and assign time span for each phase.
By studying the project extensively we developed a Gantt chart
to track and schedule the project. Below is the Gantt chart of our
project.

5.3 STATIC AND DYNAMIC UML DIAGRAM
5.3.1 USE CASE DIAGRAM
Use case describe the interaction between one or more actors and the system
itself, represented as a sequence of simple steps that take part in a sequence of activities
in a dialog with the system to achieve goal.
Mobile Problem
Possible Repair Solution ADMIN

Customer
Handset Configure.
Repair Bill
Fig 5.3.1 Use Case Diagram

ADMIN
REGISTRATION
REGISTER_USER()
ALLOCATED_ID()
DISPLAY DATA
GENERATION
CUSTOMER
MOB_INFO
CUSTOMER_ID
MOBILE_NAME()
MODEL()
FEATURES()
REPAIR SOLUTION
UNIQUE_ID
READ DATA()
CHECK DATA()
DISPLAY ID()
Fig 5.3.2: Class Diagram

CUSTOMER ADMIN MOBILE REPORT

CONFIGURATION
REGISTER
ASSIGN UNIQUE ID
SEND INFO
SEND DETAILS
GENERATE RESULT
Fig 5.3.3: Sequence Diagram

CUSTOMER
REGISTER
ADMIN
MOBILE PROBLEM
WAIT FOR
SOLUTION
Report
Close
Fig 5.3.4 : Activity Diagram

Chapter 6
IMPLEMENTATION
6.1 IMPLEMENTATION DETAILS

We offer the MyFixit dataset along with a web-based annotation tool 4 that facilitates
the annotation of data. Com- pared to the available annotation tools such as Gate (Cun-
ningham et al., 2009) and Brat (Stenetorp et al., 2012), in which the user first selects
the span of words and then chooses a label, our application speeds up the annotation by
suggesting candidates in the form of checkboxes. The checkboxes are checked by default
for candidates that are extracted using the proposed methods in this paper. The user can
yet manually modify the information in case of mistakes in suggested candidates.
As for the required tools of the repair tasks, the suggested candidates are the tools
in the toolbox, while the extracted tools with the method in Section 3.1. are checked by
default. Regarding the disassembled parts and removal verbs, the user can choose to
utilize the supervised method proposed in Section 3.2., or a simple unsupervised
approach that leverages the information from each annotated step to the next ones.
In this approach, the app first employs a deep learning- based shallow parser,
implemented in the Flair framework (Akbik et al., 2019a), to extract the noun and verb
phrases from sentences. The nouns are further filtered by Wordnet (Miller, 1995) so that
only the nouns that are hyponyms of “Artifact” will be suggested as the part candidates.
6.2 FLOW OF SYSTEM DEVELOPMENT

6.2.1 REGISTRATION IN WEBSITE
Step 1: Start.
Step 2: Register to the website.
Step 3: click on login button.
Step 4: New Customer can register in register page.
Step 5: Once the Customer registered, provide the user name and password in Login
page.

6.2.2 HANDSET CONFIGURATION
Step 1: Start
Step 2: Click on start button.
Step 3: Customer submit problem issue of Mobile Handset & wait for Solution.
Step 4: Finally get Solution.

Chapter 7
SCHEDULE OF WORK
7.1 PROJECT MANAGEMENT
Month Week Task
August 1-2 Searching topics and also latest

papers based on the topics.
Searching three topics and also

the latest papers based on
3-4
website and application.
September 1-2 We select 3 topis namely:
1. Gender recognition
using facial image.
2. TV show popularity
analysis using data
mining.
3. “An Annotation
Tools Base Line
3-4 Methods Information

Extraction from
Repair Guides”
From above topics
the topic third is
selected.
October 1-2 We conduct survey on our

project topic in Mobile Shopee
at Swami Samarth, Dhule.

Chapter 8
CONCLUSION AND FUTURE WORK
8.1 CONCLUSION
We have presented the first steps for information extraction from repair manuals and
towards an intelligent repair assistant. We introduced a dataset of repair manuals with
semi-structured information. The dataset is annotated in the category of Mac Laptops,
with the objects that a user might interact with in the course of the repair task. The
dataset is well-suited for studying information extraction from long and technical
passages, where the arguments and actions might be elided, implicit and spread across
several passages. We then proposed methods that can serve as baselines for determining
the required tools and the disassembled parts in each repair step. The methods, along
with multiple NLP techniques, are integrated into a semi-automatic annotation web-
based tool, which is freely available in ad- dition to the dataset.
In this paper, we only extract the disassembled parts using the word-level
annotation of steps, i.e. when the identity of the disassembled part can be extracted by
labeling the corresponding words in the text. For future work the method needs to be
enhanced for learning the step-level information, where extracting the information
goes beyond the word labeling in descriptions and often requires extra knowledge.
8.2 FUTURE SCOPE

In future the educational data can be analyzed by classification in data mining
technique. Instead of using naïve bayes dashboard, user can use fusion chart to design
the dashboard to get the efficient result. We imagine that an inverted sequence of the
object inter- actions during the disassembly stage can serve as a prior during the
reassembly stage. The long-term dependency among the steps and their corresponding

objects is a dis- tinctive property of repair manuals. When we detach a component from a
device using a tool, eventually, typically after multiple intermediate steps, we have to
reattach that component, most likely with the same tool. The specific order of
components in the devices, which is partially shared among devices in a category, makes
it feasible to attempt predicting the next step in the repair task, e.g., by using pre- dictive
models for learning statistical scripts, such as Hid- den Markov Models (Orr et al., 2014)
or LSTM Neural Net- works (Pichotta and Mooney, 2016). Finally, we plan to use the
extracted information as the context for a task-oriented dialog in a human-robot
interaction scenario and we en- visage that this dataset and associated baseline
methods are similarly beneficial for work on other smart assistance systems and their
constituent NLP and task-understanding components.

BIBLIOGRAPHY
1. Shailza Chaudhary, Pardeep Kumar, Abhilasha Sharma, Ravideep Singh, "Lexicographic

Logical Multi-Hashing For Frequent Itemset Mining", International Conference on
Computing, Communication and Automation (ICCCA2015)
2. Lei Xu, Chunxiao Jiang, Jian Wang, Jian Yuan, Yong Ren,"Information Security in Big
Data: Privacy and Data Mining", 2014 VOLUME 2, IEEE 29th International
Conference on Information Security in Big Data O.Jamsheela, Raju.G, "Frequent Itemset
Mining Algorithms :A Literature Survey", 2015 IEEE International Advance Computing
Conference (IACC)
3. Android. (2021, 04 27). Android Open Source. Retrieved from source.android.com:

https://source.android.com/security/encryption /full-disk
4. Android. (2021, 05 20). Android Open Source. Retrieved from source.android.com:
https://source.android.com/security/encryption /file-based
5. Aya Fukami, K. N. (2019, July). Forensic Analysis of Water Damaged Mobile
Devices. Digital Investigation, Volume 29, S71-S79. Retrieved from
https://www.sciencedirect.com/science/article/ pii/S1742287619301586
6. Dongan, S., & Akbal, E. (2017, July 13). Analysis of mobile phones in digital
forensics. Retrieved from ieeexplore.ieee.org:
https://ieeexplore.ieee.org/document/7973613
7. McSweeney, K. (2020, January 31). Burn, drown, or smash your phone: Forensics can
extract data anyway. Retrieved from www.zdnet.com:
https://www.zdnet.com/article/burn-drown-
8. Cichocki and R. Unbehaven. Neural Networks for Optimization and Signal Processing,
1st ed. Chichester, U.K.: Wiley, 1993, ch. 2, pp. 45-47.
9. Low, Yucheng, et al. "Distributed GraphLab: a framework for machine learning and data
mining in the cloud." Proceedings of the VLDB Endowment.

Project Report Toshan

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Report Toshan

Uploaded by

Copyright:

Available Formats

An Annotation Tools Base Line Methods Information Extraction from Repair Guides

GCoE Computer Department 1

1.3 PROBLEM DEFINITION

GCoE Computer Department 2

1.5 OBJECTIVES AND SCOPE

GCoE Computer Department 3

2.1 PHYSICAL SURVEY

GCoE Computer Department 4

2.2 WEB BASED SURVEY

Figure 1: Number of collected manuals in different device categories.

GCoE Computer Department 5

3.1 PROPOSED SYSTEM

GCoE Computer Department 6

Figure 1: Damaged Samsung Mobile Phone as delivered to the laboratory

3.2 METHODS AND MATERIAL

Whenever any mobile phone is subjected to data extraction, standard laboratory

GCoE Computer Department 7

Manual/ Physical Examination:

3.2 FEASIBILITY STUDY

3.1.1 TECHNICAL FEASIBILITY

GCoE Computer Department 8

A 19”DISPLAY LCD 10,200/

Multimedia keyboard 800/-

Optical mouse.. 400/-

160GB HDD 1850/-

2GB RAM(DDR 2) 2300/-

A Pentium D(2.8ghz)processor 7000/-

A intel chipset motherboard(915) 8000/-

HTML, CSS, JAVA SCRIPT 5000/-

3.1.2 ECONOMICAL FEASIBILITY

ECONOMICAL FEASIBILITY is one of the most important factors while

GCoE Computer Department 9

Economical feasibility using COCOMO Model:

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

GCoE Computer Department 10

3.1.3 OPERATIONAL FEASIBILITY

GCoE Computer Department 11

ii. September Month

Work Tasks Week 1 Week 2 Week 3 Week 4

iii. October Month

GCoE Computer Department 12

GCoE Computer Department 13

GCoE Computer Department 14

4.1 HARDWARE REQUIREMENT

4.2 SOFTWARE REQUIREMENT

2. Javascript- The Javascrip is use for popup front end.

3. HTML, CSS - It is a language use to develop a code of website.

4.3 FUNCTIONAL REQUIREMENTS

4.3.1 EXTERNAL INTERFACE REQUIRMENTS

4.3.1.1 User Interfaces

GCoE Computer Department 15

4.4 NON FUNCTIONAL REQUIREMENTS

GCoE Computer Department 16

5.1 SYSTEM ARCHITECTURE

Customer Customer Mobile Information Cluster analysis

Personal Details Mobile Handset

Fig 5.1: System Architecture

In the architecture, once Customer login to website list of possible Mobile

GCoE Computer Department 17

3. Entering the name

GCoE Computer Department 18

5.2 FUNCTION DESIGN: