INDEX

Practical Date Practical Signature

No. Name
1. (i) Implement Receipt Acknowledgement and updation of
Inventory(RAUP)
a) Find unadjusted Functional points (UFP)
b) Calculate FPC by Mark II Method
(ii) To estimate effort and schedule
Calculate the compression factor and the manpower required
based on given information of software
2. Suggest an action plan for the following risks without
compromising the project, process or product parameters
a) Language skills inadequate in two people in a team of five.
b) Specially ordered hardware and software likely to be
delivered three Months late.
c) Customer and end user not convinced on new technology
implementation as a correct choice.
d) Software required interface with other technologies on
which the project team has no experience.
3. Implement a Testing strategy for the following software
development cases:
(a) Rule based deterministic closed large but simple payroll
system for a company.
(b) Development or a customer relation management system
lor a retail distribution chain. The retail organization is not sure
about the scope, and failure feature.
(c) Modification to existing order processing system for a multi-
location, multi-product company.
4. Build a work breakdown structure for the following
a) Delivery Orthe software, initiation to development covering
lifecycle.
b) Development of prototype
c) Development of a process for a function
5. In a hospital management system develop the following
diagrams for a Ward Service Management System (SMW).
(a) Work Flow
(b) System Flow
(c) DFD Develop on effective modular design of SMW using
these diagrams.
6. Draw three level DFDs for CLPS. Modl1larize the CLPS and
structure them top-down as functional model.
7. Conduct a task analysis for the following users:
(a) officer at railway ticket reservation window
(b) Officer at insurance claim settlement desk.
(c) Clerk at call center. answering queries of customers who
have purchased cars from the company
8. Based on the business model of DEL develop a modular
structure for a business system model. Draw a complete
system flowchart.

MIET Mohri, Kurukshetra Page | 1

 PRACTICAL NO.1

Objective: - Implement the receipt acknowledgement and Updation of inventory

1. Find unadjusted functional point (UFP)
2. Calculate (FPC) by mark-2 method
3. To estimate effort and schedule. Calculate comparison factor man power required
based upon given

Information of software

Acknowledgment

Data
Sender Receiver

Update

Data Data
Base Base

The original formulation for computing the function point uses the count of five different parameters,
namely external input types, external output types, logical internal files, external interface file, external
inquiry types. According to the function approach, these five parameter capture the entire functionality
of system. However, two element of the same amount to the functionality of the system. To account
for complexity, each parameter in a type is classified as simple, average or complex. The definition of
each of these types and the interpretation of their complexity level.

Each unique input type that is given as input to the application from outside is considered of external
input type and is counted. An external is considered unique if the format is different from other or if the
specification requires a different processing for this type from other inputs of requires a different
processing for this type from other inputs of the same format. The source of external input can be the
user or different application, files.
An external type is considered simple if it has a few data element and affects only a few internal files of
application. It is considered as complex if it has many internal logical files are needed for processing
them. The complexity is average if it is in between. Note that files needed by operating system or
hardware are not counted as external input files because they do not belong to application but are
needed due to the underlying technology.

MIET Mohri, Kurukshetra Page | 2

Similarly, each unique output that leaves the system boundary is counted as an external out put type.
Again, an external output type is considered unique if its format or processing is different. Report
message to the use or other application are counted as external input type for a report, if it contain a few
columns it is considered simple, if it has multiple columns it is considered average, and if it contain
complex structure of data and references many files for production it is considered complex.

Each application maintains information internally for performing its functions. Each logical group of
data or control information that is generated, used and maintained by application is counted as logical
internal file type .a logical internal file is simple if it contain a few record types, complex if it has many
record type, and average if it is in between. Files are passed or shared between applications are count
external interface file type. Note that each such type file is counted for all the application sharing it. The
complexity levels are defined as for logical file type.

A system may queries also, where a query is defined as an input output combination where the input
causes the output to be generated almost immediately. Each unique input output pair is counted as an
external inquiry type. a query is unique if it differ from other in format of input or output or if it requires
different processing .for external output type, respectively .the query complexity is the larger of the two.

Once the counts for all five different types are known for all three different complexity classes, the raw
or unadjusted function point (UFP) can be computed as a weighted sum as follows:

Where I reflects the row and j reflects the column, wij is the entry in the ithrow and jth column of the
table and cij is the count of the number of element of type that have been classified as having the
complexity corresponding to column j,

Once the UFP is obtained, it is adjusted for the environment complexity. For this, 14 different
characteristics of the system are given. These are data communication, distributed processing,
performance objective, operation configuration load, transaction rate, on line data entry, end user
efficiency, on line update, complex processing logic, re-usability, installation ease, operational ease,
multiple sites, and desire to facilitate change, the degree of each of these factor is taken to be from 1 to
5,representing the six different level,

Function Type Simple Average Complex

External Input 3 4 6

External Output 4 5 7

Logic Internal file 7 10 15

External Interface file 5 7 10

External Inquiry 3 4 6

Function point contribution of an element

MIET Mohri, Kurukshetra Page | 3

 Not represent (0), is significant influence (1), moderate influence (2), average influence (3),
significant influence (4), and strong influence (5). The 14 degrees of influence for the system are
then summed, giving a total N (N rages 1 to 14*5=0). This N is used to obtain a complexity
adjustment factor (CAF) as follow:

Caf=0.65+0.01N

With this equation, the value of CAf ranges between 0.65and 1.35. The delivered function points
(DFP)
Are simply computed by multiplying the UFP by CAF. That is:

Delivered Function Points=CAF*Unadjusted Function Points.

As we can see, by adjustment for environment complexity, the DFP can differ from the UFP at
most by at 35%. The final function is the computed DFP.

MIET Mohri, Kurukshetra Page | 4

 PRACTICAL NO. 2

OBJECTIVE: Suggest an action plan for the following risk without compromising the project,
process or product parameters.

a) Language skills inadequate in two people in a team of five.

b) Specially ordered hardware and software likely to be delivered three Months late.
c) Custom and end user not convinced on new technology implementation as a correct choice.
d) Software required interface with other technologies on which the project team has no
experience.

HARDWARE AND S/W REQUIREMENTS: Pentium 90-MHz or better, 2GB RAM,

Windows7 or above, Ms-Word.

SOLUTION:
a) The two people have full knowledge in their field. They have only language skill problem.
So shifting them to other department will create shortage of personnel. Taking two new
appointments will increase cost. Some ways to manage this risk is to get top talent possible
to match the needs of the project with skills of available personnel. Some key personnel
for critical areas of the project should be appointed. In this case to maintain the budget
proper training should be given to these two people according to project.
b) If project depends on these H/W & S/W either to be provided by client or to be procured,
the project runs some risk. Schedule will be disturbed by the late delivery. By the time
when they are available, project will also suffer if quality of these components is poor or
components turns out to be incompatible with the project component or with the
environment in which s/W is developed.
c) This type of risk occurs if requirement analysis is not done properly and if development
begins too early or there is improper user interface is developed. To reduce this type of
risk proper SRS and User interface should be prepared in advance. This risk requires
extension rework of user interface later. This need adding some features is S/W for this
requirement changes should be applied. This affects the cost and schedule.
d) Staff should be given proper training according to new technology. Time to time inspect ion
and compatibility analysis should be done.

MIET Mohri, Kurukshetra Page | 5

 PRACTICAL NO.3

Objective: Implement a Testing strategy for the following software development cases:
(a) Rule based deterministic closed large but simple payroll system for a company.
(b) Development or a customer relation management system lor a retail distribution chain. The retail
organization is not sure about the scope, and failure feature.
(c) Modification to existing order processing system for a multi-location, multi-product company.

SOLUTION:
To perform testing in a planned and systematic manner, software testing strategy is developed. A testing
strategy is used to identify the levels of testing which are to be applied along with the methods, techniques, and
tools to be used during testing. This strategy also decides test cases, test specifications, test case decisions, and
puts them together for execution.
Developing a test strategy, which efficiently meets the requirements of an organization, is critical to the
success of software development in that organization. Therefore, a software testing strategy should contain
complete information about the procedure to perform testing and the purpose and requirements of testing.
The choice of software testing strategy is highly dependent on the nature of the developed software. For
example, if the software is highly data intensive then a strategy that checks structures and values properly to
ensure that all inputs given to the software are correct and complete should be developed. Similarly, if it is
transaction intensive then the strategy should be such that it is able to check the flow of all the transactions. The
design and architecture of the software are also useful in choosing testing strategy. A number of software testing
strategies are developed in the testing process. All these strategies provide the tester a template, which is used
for testing. Generally, all testing strategies have following characteristics.
Testing proceeds in an outward manner. It starts from testing the individual units, progresses to integrating these
units, and finally, moves to system testing.
Testing techniques used during different phases of software development are different.
Testing is conducted by the software developer and by an ITG.
Testing and debugging should not be used synonymously. However, any testing strategy must accommodate
debugging with itself.

Types of Software Testing Strategies

There are different types of software testing strategies, which are selected by the testers depending upon the
nature and size of the software. The commonly used software testing strategies are listed below.

MIET Mohri, Kurukshetra Page | 6

Analytic testing strategy: This uses formal and informal techniques to access and prioritize risks that arise
during software testing. It takes a complete overview of requirements, design, and implementation of objects to
determine the motive of testing. In addition, it gathers complete information about the software, targets to be
achieved, and the data required for testing the software.
Model-based testing strategy: This strategy tests the functionality of the software according to the real world
scenario (like software functioning in an organization). It recognizes the domain of data and selects suitable test
cases according to the probability of errors in that domain.

Methodical testing strategy: It tests the functions and status of software according to the checklist, which is
based on user requirements. This strategy is also used to test the functionality, reliability, usability, and
performance of the software.

Process-oriented testing strategy: It tests the software according to already existing standards such as the
IEEE standards. In addition, it checks the functionality of the software by using automated testing tools.

Dynamic testing strategy: This tests the software after having a collective decision of the testing team. Along
with testing, this strategy provides information about the software such as test cases used for testing the errors
present in it.

Philosophical testing strategy: It tests the software assuming that any component of the software can stop
functioning anytime. It takes help from software developers, users and systems analysts to test the software.
A testing strategy should be developed with the intent to provide the most effective and efficient way of testing
the software. While developing a testing strategy, some questions arise such as: when and what type of testing is
to be done? What are the objectives of testing? Who is responsible for performing testing? What outputs are
produced as a result of testing? The inputs that should be available while developing a testing strategy are listed
below.

Type of development project

Complete information about the hardware and software components that are required to develop the software
Risks involved
Description of the resources that are required for testing.
Description of all testing methods that are required to test various phases of SDLC.
Details of all the attributes that the software is unable to provide. For example, software cannot describe its own
limitations.
The output produced by the software testing strategy includes a detailed document, which indicates the entire
test plan including all test cases used during the testing phase. A testing strategy also specifies a list of testing
issues that need to be resolved.
An efficient software testing strategy includes two types of tests, namely, low-level tests and high-level tests.
Low-level tests ensure correct implementation of small part of the source code and high-level tests ensure that
major software functions are validated according to user requirements. A testing strategy sets certain milestones
for the software such as final date for completion of testing and the date of delivering the software. These
milestones are important when there is limited time to meet the deadline.
In spite of these advantages, there are certain issues that need to be addressed for successful implementation of
software testing strategy. These issues are discussed here.
In addition to detecting errors, a good testing strategy should also assess portability and usability of the
software.
It should use quantifiable manner to specify software requirements such as outputs expected from software, test
effectiveness, and mean time to failure which should be clearly stated in the test plan.
It should improve testing method continuously to make it more effective.
Test plans that support rapid cycle testing should be developed. The feedback from rapid cycle testing can be
used to control the corresponding strategies.
It should develop robust software, which is able to test itself using debugging techniques.
It should conduct formal technical reviews to evaluate the test cases and test strategy. The formal technical
reviews can detect errors and inconsistencies present in the testing process.

MIET Mohri, Kurukshetra Page | 7

 PRACTICAL NO.4

Objective: Build a work breakdown structure for the following.

a) Delivery of the software, initiation to development covering lifecycle
b) Development of prototype.
c) Development of a process for a function.

Hardware and S/W Requirements: Pentium 90-MHz or better, 2GB RAM, Windows 7 or above,
Ms-Word.

SOLUTION:
a) The software to be delivered should be of high quality and according to the needs of the
customers. Software development includes a series of steps known as a software development
life cycle. Each phase has a defined output, entry criteria and exit criteria. The entry criteria of
a phase specify the condition that the input to the phase should satisfy in order to initiate the
activities of that phase. The exit criteria specify the condition that the work product of this
phase should satisfy to terminate the activities of the phase. There are various models for
developing software, each having its own version. Following are the main steps to be followed
in each model:

1) Requirement Analysis: Requirement Analysis is done in order to understand the problem

the software is to solve. The problem could be automating an existing manual process,
developing new automated software or a combination of both. The emphasis is on
identifying what is needed from the system, not how the system will achieve its goals.
There are two steps in it: - Requirement Analysis and Requirement specification.
Requirement Analysis is to collect and analyze all related data and information with a view
to understanding the customer needs clearly and weeding out inconsistency and
incompleteness in these requirements. So it starts with the collection of relevant data though
questionnaire, interviews, on site observations, discussions etc. contradictions and all the
ambiguities are identified. In requirement specification all the user requirements are
properly organized and documented in a SRS document. It contains all the functional, non-
functional requirements, formats of the input, outputs, any required standards to be
followed and all the design constraints.

2) Feasibility Study: depending on the results of the initial investigation, the survey is
expanded to the more detailed feasibility study. It is a test of a software proposal according to
its workability, impact on users, and effective use of resources it focuses on:
i) What are the users needs and how does new software meets them?
ii) What resources are available for given software? Is the problem worth solving?
iii) What is the impact on the organization?
It does the following studies:

3) Economic Feasibility: It is known as cost/benefit analysis, the procedure to determine the

benefits and savings that are expected from a software and compare them with cost If benefit
outweighs costs then the decision is made to design and implement the software. Otherwise
further justification or alternation sin proposed software will have to be made it is to retain.
It is ongoing effort that improves the accuracy at each phase. .

4) Technical Feasibility: It studies that whether the new software is feasible or not mean all
the tools, developer, or the required environment is available or not. In future it can adopt
changes or not.

MIET Mohri, Kurukshetra Page | 8

 Steps in Feasibility Study :

a) Form a project team and appoint a project leader

b) Prepare software flowcharts
c) Enumerate potential candidate softwares
d) Describe and identify the characteristics of candidate software
e) Evaluate the performance and cost effectiveness of each candidate software
f) Weigh software performance and cost data
g) Select the best candidate software
h) Prepare and submit the following reports to the management:
i) Statement of the problem
j) Summary of findings and recommendations
k) Details of findings
l) Conclusion about target dates, cost

3) Software Design: It is first step in moving from the problem domain to the solution domain. Starting
with what is needed; design takes us toward how to satisfy the needs. Design activity is divided in two
parts: System design and detailed design. System design is also called top level design aims to identify the
modules that should be in the system, specifications of these modules and how they interact with other to
produce the result. At the end of design all the major data structure, file format, output formats and major
modules and their specifications are decided. Detailed design, the internal logic of the system is decided.
During this phase further details of data structures and algorithms of each module are decided logic is
specified in high level language. Design can be function oriented or object oriented.

4) Coding: the goal of the coding phase is to translate the design of the system into code in a given
programming language. During coding the focus should be on developing programs that are easy to read
and understand and not simply on developing programs that are easy to write. Simplicity and clarity should
be there. The coding affects the both testing and maintenance.

5) Testing: After coding phase computer programs are available for execution. For testing purpose. This
implies that testing not only has to uncover errors introduced during coding but also errors introduced
during previous phases.
Thus its goal is to uncover requirement, design and coding errors in the programs. The starting point of
testing is unit testing. In it a module is tested separately and is often performed by the coder himself. The
purpose is to exercise the different parts of the module code to detect coding errors. After this modules are
gradually integrated into subsystems which are then integrated to form the entire system. It finds the design
errors. So integration testing is performed.

After the system is put together system testing is performed .here the system is tested against the system
requirement to see if all the requirements are met and if the system performs as specified by the
requirements. Finally acceptance testing is performed to demonstrate to the client, real life data of the
client, the operation of the system.

TESTING
6)Maintenance: Software maintenance denotes the process of modifying a software product after it has
been delivers to the customer. Due to hardware obsolescence, the immortality of a software product and the
demand of the user community to see existing software products run on newer platforms, run in newer
environments and with enhanced features gives birth to the maintenance phase. When hardware changes
and a software product performs some low level functions maintenance is necessary. Whenever the
software support environment changes the software product requires rework to cope with new interface eg.,
when operating system changes the software product need to be maintained. It is needed due to following
reasons:
a) Corrective: it is necessary either to rectify some bugs observe while the system is in use
or to enhance the performance of the system.
b) Adaptive: A software product might need maintenance when the
MIET Mohri, Kurukshetra Page | 9
 Software development
life cycle

Requirement Feasibility study Testing Maintenance

Analysis

Design Coding

System design
Detailed Design

Fig.a. Work breakdown structure of software development life cycle

before development of actual software, a working prototype of the system should be built first. the model
starts with an initial requirements gathering phase. A quick design is carried out and prototype model is
built using several shortcuts which involve inefficient or dummy functions. The prototype is submitted to
the customer for his evaluation. Based on user feedback requirements are refined. This cycle is continued
until the user approves the prototype. The actual system is then developed using waterfall model. The
code for model is not written. An important purpose is to make input format, message, reports and user
interface.

MIET Mohri, Kurukshetra Page | 10

 Requirements
Gathering
nts Gathering
.
Quick Design

Refine Requirement Build Prototype

Customer
Customer Suggestions evaluation Acceptance by the
of customer
prototype

Design

Implement

Test

Maintain

Fig. b. work breakdown structure of prototype.

c) Development of a process for a function is done using evolutionary model. The system is
first broken down into several modules or functional units that can be incrementally
implemented and delivered as in fig c. The developer first develops the core modules of the
system. This initial product is refined into increasing levels of capability by adding new
features. Each successive version of the product is functioning system capable of
performing some more useful work. It is useful only for large systems. But isis difficult to
divide problem into several functional units. Eg., as in fig c, to develop a function c. make
core module A, make additions in it to ,make B then finally add all the feature and
complete the function C.

MIET Mohri, Kurukshetra Page | 11

 B

A
A A
B

Fig c. Work breakdown structure of a development of a process for a

function c

MIET Mohri, Kurukshetra Page | 12

 PRACTICAL NO.5

Objective: To Study the Object Model of Hospital Management System.

Hardware & S/W Requirements: Pentium 90-MHz or better, 2GB RAM, Windows7 or above, Ms-Word.

Solution:
Hospital management system has the following activities:
Connects people, processes and data in real time across all the hospital on a single platform.
Workflow routes documents and Information electronically.
Flexibility and Integration abilities manage change.
Customized Clinical data according to each Department, Laboratory etc
Access to Financial information and Performance indicators help in managing resources, costs and margins.
Fast and reliable information storage, querying and retrieval. Retrieval could be either for generation of reports
based on demographics, gender, and age or for research & library classification.
Features

Registration
every patient who approaches a hospital has to get registered prior to getting any consultation, treatment, and
investigations done from the hospital. Registration of patients involves accepting certain general and
demographic information about the patient and assigning a unique central registration number (CR No) to the
Patient.

Out-Patient-Management
The outpatient module deals with the entire gamut of activities pertaining to the management of out-patients. It
consists of the creating Patient Visit and storing details like complaints, history, clinical summary, provisional
diagnosis, drugs etc corresponding to each visit.

Pharmacy-Management
The Pharmacy Module deals with the maintenance of drugs and consumables in the hospital. The functions of
this module include, online drug prescription, inventory management of drugs, consumables and sutures.

MIET Mohri, Kurukshetra Page | 13

MIET Mohri, Kurukshetra Page | 14
MIET Mohri, Kurukshetra Page | 15
 PRACTICAL NO.6

Objective:-Draw three level DFDs for CLPS. Modularize the CLPS and structure them top-down
functional model.

Hardware and Software requirements:- Pentium 90-MHZ or better, 2GB RAM, Windows7 or above,
MS-Word.

CLPS (CONSTRAINTS & LOGIC PRORAMMING SYSTEM)

CLPS offers a very high level of abstraction & a declarative nature with an extreme flexibility in the
design of the execution model. CLPS allows variable to be constrained rather than bound.
For eg. In the game of ladders & snake, there are many ways to reach the goal. Either by steps & by ladders.
There is no particular path defined to win the game.
Solution to CLPS can be derived from the KB(knowledge base).CLPS incorporates various constraints solving
algorithm for the constraints allowed in the language. CLPS combines elements of constraints satisfaction
algorithm, logic programming & deductive database.

DFD (Data Flow Diagram)

The DFD (also known as the bubble chart) is a simple graphical notation that can be used to represent a system
in terms of the input data to the system, various processing carried out on these data and the output data
generated by the system.
The DFD model uses a very limited number of the primitive symbols to represent the function performed by a
system and data flow among the functions.

External Entity
Process
Data Flow

Data Store
Out Put

MIET Mohri, Kurukshetra Page | 16

Symbols used to construct DFDs
For drawing a DFD, a top down approach is suggested in the structured analysis method. In the structured
analysis method, a DFD is constructed from scratch when the DFD for the physical system is being drawn
and when the DFD for the new system is being drawn. The Second step largely performs transformation
the physical DFD. Drawing a DFD starts with a top level DFD called the context diagram, which lists all
the major inputs and outputs for the system. This diagram is then refined into a description of the different
parts of the DFD showing all details. This results in a leveled set of DFDs. During this refinement, the
analyst has to make sure consistency is maintained and that net input and output are preserved.

Example of a Restaurant
A restaurant owner feels that some amount of automation will help make her business more efficient. She also
believes that an automated system might be added attraction for the customers. So she wants to automate the
operation of her restaurant as much as possible. Here we will perform the analysis of this problem. Details
regarding interviews, questionnaires, or how the information was extracted are not described. First let us
identify the different parties involved.

Client: The restaurant owner.

Potential Users: Waiters, Cash register operation.

The context diagram for the restaurant is shown in the fig.
(a). The inputs and outputs of the restaurant are shown in the diagram.
However, no details about the functioning of the restaurant are given here. Using this as a starting point, a
logical DFD of the physical system is given in the fig.(b)(the physical DFD was avoided for this as the logical
DFD is similar to the physical and there were no special names for the data or the processes in the physical
system).Observing the operation of the restaurant and the interviewing the owner were the basic means of
collecting raw information for the DFD.
With the help of context diagram of the restaurant we simply come to know about the information of the input
and the output of the restaurant. Now we have to draw the DFD for the restaurant by sorting out the problem by
meeting and discussions with the restaurant owner.

a) Context Diagrams for the Restaurant

Now we must draw a DFD that models the new system to be built. After many meetings and discussions with
restaurant owner, the following goals for the new system were established:
Automate much of the order processing and billing.
Automate accounting.
Make supply ordering more accurate so that leftovers at the end of the day are minimized and the orders
that cannot be satisfied due to no availability are also minimized. This was currently being done without a
careful analysis of sales.
The owner also suspects that the staff might be stealing/eating some food/supplies. She wants the new
system to help detect and reduce this.
The owner would also like to have statistics about sales of different items.
With these goals, we can define the boundaries for the change in DFD. The DFD is largely self-explanatory.
The major files in the system are: supplies file, accounting file, order file and the start menu. Note that the
processes are consistent in that the input given to them are sufficient to produce the outputs.

The definitions of the different data flows and files are self-explanatory. Once this DFD and the data
dictionary have been approved by the restaurant owner, the activity of understanding the problem is
complete. After taking with the restaurant owner the man machine boundary was also defined (it is shown
in the DFD). Now remain such tasks as determining the details requirement of each bubble shown in the
DFD, determining the non-functional requirements, deciding codes for that task to perform can be done
with the help of DFD.

MIET Mohri, Kurukshetra Page | 17

 PRACTICAL NO.7

Objectives:- Conduct a task analysis for the following users:

(a) Officer at railway ticket reservation window

(b) Officer at insurance claim settlement desk
(c) Clerk at call center answering the queries of customers who have purchased cars from the
company.

Hardware and Software requirements:- Pentium 90-MHZ or better, 2GB RAM, Windows7 or above,
MS-Word.

Task Analysis:-
Task analysis analyzes what a user is required to do in terms of actions and/or cognitive processes to achieve a
task. A detailed task analysis can be constructed to understand the current system and the information flows
within it. These information flows are important to the maintenance of the existing system and must be
incorporated or substituted in new system. Task analysis makes it possible to design and allocate tasks
appropriately within the new system. The functions to be included within the system and the user interface can
then be accurately specified.
The aim of high level task decomposition is to decompose the high level tasks and break them down into their
constituent subtasks and operations. This will show an overall structure of main user tasks. At a lower level it
may be desirable to show the task flows, decision processes and even screen layouts.

(a) Officer at railway ticket reservation window:-

Officer sitting at reservation window do the reservation but besides he has to perform various functions. He
answers all the queries of the passengers about the reservation. He tells them about the accurate train and time
suitable to various passengers. Now we will explain some features, which will tell us the railway ticket
reservation.
Officer sitting at the reservation window do the following functions: -

Enquiry:-
Officer will answer all the questions of the passengers asked regarding ticket reservation. In this he tells about
the train name, train no., time of boarding etc and help the passenger to fill up the ticket reservation form
according to the requirements of the passengers. All the queries are made clear to the passengers.

Train Information:-
Train information includes the information regarding the train whether the train is super fast or an express train
and all the trains which are going to the destination from the source of the passengers. It also includes the
queries of boarding and reaching time at the destination. With the help of the train information the passenger
can easily fill the railway ticket reservation form.

Ticket Window:-
At the ticket window passenger will give the reservation form. Officer will give the ticket if there is seat in that
train on the required day. If there is no seat available he will tell the passenger you are getting so and so waiting
no. in this train. If the passenger wants then he will give the waiting no. Ticket otherwise he will suggest him
for other trains which are going to the same destination and give the ticket according to the satisfaction of the
passenger.

Ticket:-
In this section we can say that thatwhether the passenger got the ticket reserved or waiting.In which class he
gets the seats if he got a reserved ticket than simply get the train on the desired day otherwise he has to
check.The waiting no. If his no. is confined than he will get a seat otherwise he has to travel in a general class
coach or can cancel the ticket.

MIET Mohri, Kurukshetra Page | 18

b) Officer at insurance claim settlement desk:
Officer sitting at insurance settlement desk first of all check the case that under which category the case falls.
According to that category he will proceed towards the next step because there is lots of types insurance like
vehicle insurance, life insurance or any general insurance.
With the help of task analysis we can decompose the task into various sub steps and can solve the case. Fig(b)
shows the task flow diagram of the insurance settlement desk. According to the task analysis main task is
breakdown into the subtasks.

Settlement:-
According to the rules and regulation of the insurance company officer will proceed for the further verification
at the settlement table. As described above according to the category of the case he will asks the question. He
will verify according to the requirement of the insurance company. After the discussion of the case the
insurance settlement officer he will decide whether the case is approved for the insurance claim or not. If the
case had been approved by the officer than the company will do its own formalities and pay the amount
according to their insurance scheme.

Claim:-
Settlement officer after hearing the views and verifying the documents decide whether the case is approved for
the claim or not. So, after deciding that case is approved for the insurance claim or not, if case is approved for
the claim than the amount will be paid otherwise will be closed after proving that the case is invalid.

Amount Paid:-
At last after all the discussions made at the settlement table. For those cases which are approved for the claim of
the insurance, it is checked that whether the appropriate amount is paid or not.

MIET Mohri, Kurukshetra Page | 19

 Insurance

General Life
Vehicle Insurance
Insurance Insurance

SETTLEMENT

Amount
Claim
Paid

Valid Invalid Appropriate Inappropriate

Fig.(b) Task flow diagram of insurance settlement

MIET Mohri, Kurukshetra Page | 20

(c) Clerk at the call center answering the queries of customers who have purchased cars from the
company:-

After purchasing a car customer can have many queries related to the car. They may be technical as well as
general queries.We make task flow diagram in fig.( c) to explain the queries of the car.
With the help of task flow diagram we can easily understand the problem by decomposing.Firstaf all the queries
are categorized according to the technical and general queries.Further we divide them according to their
level.Following of thr levels of the task flow diagram.

Technical Queries:-
In this category we have the queries which are related to the technical problem. Under this category one can
have the queries about the mileage, top speed and wheel balancing etc. One can ask about the current mileage
and mileage after first servicing. He may ask about the queries related to the wheel balancing. After how much
kilometers one can go for the wheel balancing, also about the top speed the car on which it will give the better
mileage. So one can have many more queries related to the technical issues.

General Queries:-
In the general queries one can have many queries related to the accessories and its features. In this we can have
the queries related to the accessories like stereo system, safety guards, air bags etc. We can ask about any effect
on the car due to the respective accessories. We can ask about the stereo system in the car, how it is going to
effect the battery and also can ask about the time period of time forfilling up of water in the battery. One can
have the queries on the safety guards like air bags.Customer can also ask about queries related to the alloy
wheel of the car.In this way we can study the queries of a car with help of task flow diagram.

QUERIES

Technical General

Wheel Top Special

Mileage Accessories
Balancing Speed features

Safety
Alloys
Guards

Stereo
System

Fig.(b) Task flow diagram of queries of car

MIET Mohri, Kurukshetra Page | 21