IT VT Report

CENTRAL INDIA INSTITUTE OF TECHNOLOGY

INDUSTRIAL TRAINING REPORT

Submitted By

Student Name:Bhavna Thakre STUDENT ROLL NO: 0819IT061013

RAJIV GANDHI PROUDYOGIKI VISHWAVIDYALAYA, BHOPAL

(Fulfillment of course curriculum of Bachelor of Engineering)

July 2009

STUDENT DETAILS

ENROLLMENT NO. : 0819IT061013

NAME : BHAVNA THAKRE

FATHER’S NAME : Mr. BHOJRAJ THAKRE

BRANCH : INFORMATION TECHNOLOG & ENGINEERING

SEMESTER : 7th

SUBJECT CODE & NAME : IT 704-INDUSTRIAL TRAINING

Signature of trainee

Signature of TPO

Signature of HOD

DETAILS OF COMPANY

NAME : JS Informatics

ADDRESS : 124 B, Trade Center, South tukoganj, Indore

TELEPHONE : 0731-4263751

WEB SITE : www.jsinformatics.com

NATURE : Training and Development

DETAILS OF CEO

NAME : Mr. Kumar Umang Gupta

DETAILS OF GUIDE

NAME : Mr. Prashanna Gupta

DESIGNATION : TRAINER

QUALIFICATION : BE(IT)

DEPARTMENT : DEVELOPMENT AND TRAINING SECTION

COMMENTS OF GUIDE

Signature of guide

AIM OF TRAINING

To acquaint with the environment of industries.

To understand organizational hierarchies.

To understand information flow in organization.

To understand the work culture in industry.

To adopt the work methodology of department.

To inculcate the habit of systematic recording of learning experiences and events.

To be initiative and participative at work.

SUPERVISION GUIDLINE

One faculty member or TPO will plan industrial training of students in consultation with

training manager of the industry (work place) as per the predefined objectives of training.

The trainee will maintain a proper daily diary (Format enclosed). The section in-charge of the

industry is requested to sign the daily diary at the end of the week and offer his comments

about the initiative and the institute provides participative attitude of trainee during training

in this daily diary witch.

Attendance records of each trainee may please be kept in the industry. Absence without

permission may please be communicated to the institute.

ATTENDENCE RECORD

WEEK Day-1 Day-2 Day-3 Day-4 Day-5 Day-6

Date

ONE Sign

Date

TWO Sign

Date

THREE Sign

Date

FOUR Sign

Date

FIVE Sign

Date

SIX Sign

Date

TOTAL NO. OF DAYS ……………………

NO OF DAYS ATTENDED ………………………% OF ATTENDENCE

………………………

Signature of Guide

DETAILS OF PROBLEM/PROJECT UNDERTAKEN

The project that we were out sourced was one of the commercial projects that were available at the

company.

After analyzing the proposed software we decomposed it into a number of modules. The project was

divided into 5 modules.

Personal data records.

Searching the records.

Birthday reminder.

Daily diary maintenance.

Future diary maintenance.

We pondered on the available technologies and which one is the best suited for the proposed

software; and then we came up with the idea of employing JAVA as the platform.

The key reason behind choosing JAVA is one of its unique properties of being platform independent

and secure. Platform independence means that our same JAVA program can execute on various

platforms and will provide the same result , While JAVA Applets can be safely downloaded

without fear of viral infection .JAVA achieves this protection by confining a JAVA program to the

JAVA execution environment and not allowing it to access to other parts of the computer. Thus they

are secure. The magic of Byte code is also provided by JAVA.

Byte codes are a set of instructions that look a lot like machine code, but are not specific to any one

processor. Normally, when we compile a program written in C or in most other languages, the

compiler translates our program into machine codes or processor instructions. Those instructions are

specific to the processor our computer is running—so, for example, if we compile our code on a

Pentium system, the resulting program will run only on other Pentium systems. If we want to use the

same program on another system, we have to go back to our original source, get a compiler for that

system, and recompile our code.

DAILY REPORT

Week No. : 1 Day: 1 Date: 01.07.2009

Topic (Problem): Introduction

Discussion Held:

Completed my vocational training from Epsilon I.T. Solutions. Epsilon IT Solution is in Hyderabad.

My vocational training is on SDLC with a complete study on a live project of “LIFE CARE MULTI

SERVICES PVT.LTD”. SDLC is the Software Development Life cycle. It is the project for the

Epsilon to make a software which reduces the overall paper work of the Life care Multi Services. So

we are work on the project to make the software for the Life care company. Life Care Multi Services

works on Life Care Carrier Plan with Service Card. Its head office is at AKOLA. Akola is in

Maharashtra.

I

Signature of Trainee

DAILY REPORT

Week No: 1 Day: 2 Date: 02.07.2009

Topic (Problem): Introduction Of SDLC Model

Discussion Held:

This document describes the Software Development Life Cycle (SDLC) for small

to medium database application development efforts. This report presents an

Overview of the SDLC, alternate lifecycle models, and associated references. The

following topics describes the internal processes that are common across all

stages of the SDLC, and then describes the inputs, outputs, and

processes of each stage. Finally, the conclusion describes the four core concepts

that form the basis of this SDLC.

In SDLC there are following models are:-

(1)Water fall model

(2) Prototype model

(3) RAD model

(4) Spiral model


WEEKLY PROGRESS REPORT

Name: STUDENT NAME

Week No: 2 Day 3 Date: 03-07-09

Topic: Water Fall Mode

Discussion Held: Small to medium database software projects are generally broken down into six

stages:

ProjectPlanning

Developement

Installation &Acceptance

RequirementDefinition

Desing

Intregration &

Testing

The relationship of each stage to the others can be roughly described as a

waterfall, where the outputs from a specific stage serve as the initial inputs for the

following stage.

During each stage, additional information is gathered or developed, combined

with the inputs, and used to produce the stage deliverables. It is important to note

that the additional information is restricted in scope; “new ideas” that would take

The Software Development Life Cycle (SDLC) REF-0-02

the project in directions not anticipated by the initial set of high-level

requirements are not incorporated into the project. Rather, ideas for new

capabilities or features that are out-of-scope are preserved for later consideration.

After the project is completed, the Primary Developer Representative (PDR) and

Primary End-User Representative (PER), in concert with other customer and

development team personnel develop a list of recommendations for enhancement of the current

software.

Literature Consulted:


DAILY REPORT

Week No: 2 Day: 4 Date: 04.07.2009

Topic (Problem): Prototype Model

Discussion Held: The software development team, to clarify requirements and/or design

elements, may generate mockups and prototypes of screens, reports, and processes.

Although some of the prototypes may appear to be very substantial, they're

generally similar to a movie set: everything looks good from the front but there's

nothing in the back.

When a prototype is generated, the developer produces the minimum amount of

code necessary to clarify the requirements or design elements under

consideration. No effort is made to comply with coding standards, provide robust

error management, or integrate with other database tables or modules. As a result,

it is generally more expensive to retrofit a prototype with the necessary elements

to produce a production module then it is to develop the module from scratch

using the final system design document.

For these reasons, prototypes are never intended for business use, and are

generally crippled in one way or another to prevent them from being mistakenly

used as production modules by end-users.

ALLOWED VARIATIONS

In some cases, additional information is made available to the development team

that requires changes in the outputs of previous stages. In this case, the

development effort is usually suspended until the changes can be reconciled with

the current design, and the new results are passed down the waterfall until the

project reaches the point where it was suspended.

The PER and PDR may, at their discretion, allow the development effort to

continue while previous stage deliverables are updated in cases where the impacts

are minimal and strictly limited in scope. In this case, the changes must be

carefully tracked to make sure all their impacts are appropriately handled.

Work Done


DAILY REPORT

Week No. : 2 Day: 4 Date: 06.07.2009

Topic (Problem):Spiral Model

Discussion Held:The waterfall model is one of the three most commonly cited lifecycle models.

Others include the Spiral model and the Rapid Application Development (RAD)

model, often referred to as the Prototyping model.

SPIRAL LIFECYCLE

The spiral model starts with an initial pass through a standard waterfall lifecycle, using a subset of

the total requirements to develop a robust prototype. After an evaluation period, the cycle is initiated

again, adding new functionality and releasing the next prototype. This process continues, with the

prototype becoming

larger and larger with each iteration. Hence, the “spiral.”

The theory is that the set of requirements is hierarchical in nature, with additional

functionality building on the first efforts. This is a sound practice for systems

where the entire problem is well defined from the start, such as modeling and

simulating software. Business-oriented database projects do not enjoy this

advantage. Most of the functions in a database solution are essentially

independent of one another, although they may make use of common data. As a

result, the prototype suffers from the same flaws as the prototyping lifecycle

described below. For this reason, the software development team has decided

against the use of the spiral lifecycle for database projects.

Work Done


DAILY REPORT

Week No. : 2 Day: 6 Date: 07.07.2009

Topic (Problem):RAD Model

Discussion Held: RAPID APPLICATION DEVELOPMENT (RAD) / PROTOTYPING LIFECYCLE

RAD is, in essence, the “try before you buy” approach to software development.

The theory is that end users can produce better feedback when examining a live

system, as opposed to working strictly with documentation. RAD-based

development cycles have resulted in a lower level of rejection when the

application is placed into production, but this success most often comes at the

expense of a dramatic overruns in project costs and schedule.

The RAD approach was made possible with significant advances in software

development environments to allow rapid generation and change of screens and

other user interface features. The end user is allowed to work with the screens

online, as if in a production environment. This leaves little to the imagination, and

a significant number of errors are caught using this process.

The down side to RAD is the propensity of the end user to force scope creep into

the development effort. Since it seems so easy for the developer to produce the

basic screen, it must be just as easy to add a widget or two. In most RAD lifecycle

failures, the end users and developers were caught in an unending cycle of

enhancements, with the users asking for more and more and the developers trying

to satisfy them. The participants lost sight of the goal of producing a basic, useful

system in favor of the siren song of glittering perfection.


For small to medium database applications Version 1.0d

7

For this reason, the software development team does not use a pure RAD

approach, but instead blends limited prototyping in with requirements and design

development during a conventional waterfall lifecycle. The prototypes developed

are specifically focused on a subset of the application, and do not provide an

integrated interface. The prototypes are used to validate requirements and design

elements, and the development of additional requirements or the addition of user

interface options not readily supported by the development environment is

actively discouraged.

Work Done:


DAILY REPORT

Week No. : 2 Day: 7 Date: 08.07.2009

Topic (Problem): GENERIC STAGE(1) Kickoff

Discussion Held: Each of the stages of the development lifecycle follow five standard internal

processes. These processes establish a pattern of communication and

documentation intended to familiarize all participants with the current situation,

and thus minimize risk to the current project plan. This generic stage description

is provided to avoid repetitive descriptions of these internal processes in each of

the following software lifecycle stage descriptions. The five standard processes

are Kickoff, Informal iteration, Formal iteration, In-stage assessment, and Stage

exit:

KickoffProcess

InformalIteration

FormalIteration

In-StageAssessment

StageExit

SDLC Stage

KICKOFF PROCESS

Each stage is initiated by a kickoff meeting, which can be conducted either in

person, or by Web teleconference. The purpose of the kickoff meeting is to

review the output of the previous stage, go over any additional inputs required by

that particular stage, examine the anticipated activities and required outputs of the

current stage, review the current project schedule, and review any open issues.

The PDR is responsible for preparing the agenda and materials to be presented at

this meeting. All project participants are invited to attend the kickoff meeting for

each stage.

Work Done Signature of Trainee

DAILY REPORT

Week No. : 2 Day: 8 Date: 09.07.2009

Topic (Problem): ): GENERIC STAGE

(2) INFORMAL ITERATION PROCESS

(3) FORMAL ITERATION PROCESS

Discussion Held: INFORMAL ITERATION PROCESS

Most of the creative work for a stage occurs here. Participants work together to

gather additional information and refine stage inputs into draft deliverables.

Activities of this stage may include interviews, meetings, the generation of

prototypes, and electronic correspondence. All of these communications are

deemed informal, and are not recorded as minutes, documents of record,

controlled software, or official memoranda.

The intent here is to encourage, rather than inhibit the communication process.

This process concludes when the majority of participants agree that the work is

substantially complete and it is time to generate draft deliverables for formal

review and comment.

FORMAL ITERATION PROCESSIn this process, draft deliverables are generated for formal review and comment.

Each deliverable was introduced during the kickoff process, and is intended to

satisfy one or more outputs for the current stage. Each draft deliverable is given a

version number and placed under configuration management control.

As participants review the draft deliverables, they are responsible for reporting

errors found and concerns they may have to the PDR via electronic mail. The

PDR in turn consolidates these reports into a series of issues associated with a

specific version of a deliverable. The person in charge of developing the

deliverable works to resolve these issues, then releases another version of the

deliverable for review. This process iterates until all issues are resolved for each

deliverable. There are no formal check off / signature forms for this part of the

process. The intent here is to encourage review and feedback.

At the discretion of the PDR and PER, certain issues may be reserved for

resolution in later stages of the development lifecycle. These issues are

disassociated from the specific deliverable, and tagged as "open issues." Open

issues are reviewed during the kickoff meeting for each subsequent stage.

Once all issues against a deliverable have been resolved or moved to open status,

the final (release) draft of the deliverable is prepared and submitted to the PDR.

When final drafts of all required stage outputs have been received, the PDR

reviews the final suite of deliverables, reviews the amount of labor expended

against this stage of the project, and uses this information to update the project

plan.

(out stages) in the project plan are updated to include a high level estimate of

schedule and level of effort, based on current project experience.

Out stages are maintained at a high level in the project plan, and are included

primarily for informational purposes; direct experience has shown that it is very

difficult to accurately plan detailed tasks and activities for out stages in a software

development lifecycle. The updated project plan and schedule is a standard

deliverable for each stage of the project. The PDR then circulates the updated

project plan and schedule for review and comment, and iterates these documents

until all issues have been resolved or moved to open status.

Work Done: Signature of Trainee

DAILY REPORT

Week No. : 2 Day: 9 Date: 10.07.2009

Topic (Problem): GENERIC STAGE

(4) IN-STAGE ASSESSMENT PROCESS

Discussion Held: IN-STAGE ASSESSMENT PROCESS

This is the formal quality assurance review process for each stage. In a small

software development project, the deliverables for each stage are generally small

enough that it is not cost effective to review them for compliance with quality

assurance standards before the deliverables have been fully developed. As a

result, only one in-stage assessment is scheduled for each stage.

This process is initiated when the PDR schedules an in-stage assessment with the

independent Quality Assurance Reviewer (QAR), a selected End-user Reviewer

(usually a Subject Matter Expert), and a selected Technical Reviewer.

These reviewers formally review each deliverable to make judgments as to the

quality and validity of the work product, as well as its compliance with the

standards defined for deliverables of that class. Deliverable class standards are

defined in the software quality assurance section of the project plan.

The End-user Reviewer is tasked with verifying the completeness and accuracy of

the deliverable in terms of desired software functionality. The Technical

Reviewer determines whether the deliverable contains complete and accurate

technical information.

The QA Reviewer is tasked solely with verifying the completeness and

compliance of the deliverable against the associated deliverable class standard.

The QAR may make recommendations, but cannot raise formal issues that do not

relate to the deliverable standard.

Each reviewer follows a formal checklist during their review, indicating their

level of concurrence with each review item in the checklist. Refer to the software

quality assurance plan for this project for deliverable class standards and

associated review checklists. A deliverable is considered to be acceptable when



11

each reviewer indicates substantial or unconditional concurrence with the content

of the deliverable and the review checklist items.

Any issues raised by the reviewers against a specific deliverable will be logged

and relayed to the personnel responsible for generation of the deliverable. The

revised deliverable will then be released to project participants for another formal

review iteration. Once all issues for the deliverable have been addressed, the

deliverable will be resubmitted to the reviewers for reassessment. Once all three

reviewers have indicated concurrence with the deliverable, the PDR will release a

final in-stage assessment report and initiate the next process.



Name: STUDENT NAME

Week No. : 2 Day:10 Date:11.07.09

Topic:- GENERIC STAGE

(5) STAGE EXIT PROCESS

Discussion Held: STAGE EXIT PROCESS

The stage exit is the vehicle for securing the concurrence of principal project

participants to continue with the project and move forward into the next stage of

development. The purpose of a stage exit is to allow all personnel involved with

the project to review the current project plan and stage deliverables, provide a

forum to raise issues and concerns, and to ensure an acceptable action plan exists

for all open issues.

The process begins when the PDR notifies all project participants that all

deliverables for the current stage have been finalized and approved via the In-

Stage Assessment report. The PDR then schedules a stage exit review with the

project executive sponsor and the PER as a minimum. All interested participants

are free to attend the review as well. This meeting may be conducted in person or

via Web teleconference.

The stage exit process ends with the receipt of concurrence from the designated

approvers to proceed to the next stage. This is generally accomplished by entering

the minutes of the exit review as a formal document of record, with either

physical or digital signatures of the project executive sponsor, the PER, and the

PDR


DAILY REPORT

Week No. : 3 Day: 11 Date: 13.07.2009

Topic (Problem): SDLC STAGES

Discussion Held: OVERVIEW

The six stages of the SDLC are designed to build on one another, taking the

outputs from the previous stage, adding additional effort, and producing results

that leverage the previous effort and are directly traceable to the previous stages.

This top-down approach is intended to result in a quality product that satisfies the

original intentions of the customer.

Project Planning

Requirements Definition

Design

Development

Integration & Test

Installation & Acceptance

Too many software development efforts go awry when the development team and

customer personnel get caught up in the possibilities of automation. Instead of

focusing on high priority features, the team can become mired in a sea of “nice to

have” features that are not essential to solve the problem, but in themselves are

highly attractive. This is the root cause of a large percentage of failed and/or

abandoned development efforts, and is the primary reason the development team

utilizes the Waterfall SDLC.


DAILY REPORT

Week No. : 3 Day: 12 Date: 14.07.2009

Topic (Problem): PLANNING STAGE

Discussion Held: PLANNING STAGEThe planning stage establishes a bird's eye view of the intended software product,

and uses this to establish the basic project structure, evaluate feasibility and risks

associated with the project, and describe appropriate management and technical

approaches.

Software Configurationmanagement

Plane

Software QualityAssurance

Plan

Project Plane&

Schedule

PlanningStages

ApplicationGoal

LifecycleModel

The most critical section of the project plan is a listing of high-level product

requirements, also referred to as goals. All of the software product requirements

to be developed during the requirements definition stage flow from one or more

of these goals. The minimum information for each goal consists of a title and

textual description.

.The outputs of the project planning stage are the configuration management plan,

the quality assurance plan, and the project plan and schedule, with a detailed

listing of scheduled activities for the upcoming Requirements stage, and highlevel

estimates of effort for the out stages.


DAILY REPORT

Week No. : 3 Day: 13 Date: 15.07.2009

Topic (Problem): REQUIREMENTS DEFINITION STAGE

Discussion Held: REQUIREMENTS DEFINITION STAGE

The requirements gathering process takes as its input the goals identified in the

high-level requirements section of the project plan. Each goal will be refined into

a set of one or more requirements.

These requirements define the major functions of the intended application, define

operational data areas and reference data areas, and define the initial data entities.

Major functions include critical processes to be managed, as well as mission

critical inputs, outputs and reports. A user class hierarchy is developed and

associated with these major functions, data areas, and data entities.

Each of these definitions is termed a Requirement. Requirements are identified by

unique requirement identifiers and, at minimum, contain a requirement title and

textual description.

The title of each requirement is also placed into the first version of the RTM,

along with the title of each goal from the project plan. The purpose of the RTM is

to show that the product components developed during each stage of the software

development lifecycle are formally connected to the components developed in

prior stages.



15

RequirementDefinition

Stage

RequirementDocument

Project Plan&

Scheduling

RequirementTracability

matrix

High LevelRequirement(Project Plan)

In the requirements stage, the RTM consists of a list of high-level requirements,

or goals, by title, with a listing of associated requirements for each goal, listed by

requirement title. In this hierarchical listing, the RTM shows that each

requirement developed during this stage is formally linked to a specific product

goal. In this format, each requirement can be traced to a specific product goal,

hence the term requirements traceability.

The outputs of the requirements definition stage include the requirements

document, the RTM, and an updated project plan.


DAILY REPORT

Week No. : 3 Day: 14 Date: 16.07.2009

Topic (Problem): Requirement Definition for Life Care Multi Services

Discussion Held:

In requirement definition of life care multi services, the hierarchy of employees of the life care multi

services is listed out for the screen designing of the project. This hierarchy is based on the posts of

the employees in the company. In this stage it also listed the crite area for the promotion, targets for

different percentages of bonus, types of cards and vouchers, parent and child ranks of the employees,

minimum selling etc.

The hierarchy of the employees of life care multi services according to their posts:

Carrier Planner (C.P.)

Deputy Carrier Planner (D.C.P.)

Senior Chief Executive (S.C.E.)

Chief Executive (C.E.)

Deputy Chief Executive (D.C.E.)

Senior General Manager (S.G.M.)

General Manager (G.M.)

Deputy General Manager (D.G.M.)

Marketing Manager (M.M.)

Deputy Marketing Manager (D.M.M.)

Senior Marketing Officer (S.M.O.)

Marketing Officer (M.O.)

Deputy Marketing Officer (D.M.O.)

Field Officer (F.O.)

Sales Officer (S.O.)

Requirement Analysis For Screen Design

Rank Management

Commission

Promotion

Define Parent Rank

Officer Management

Voucher

Service Card Entry

Master Table Entry

User Management

DAILY REPORT

Week No. : 3 Day: 15 Date: 17.07.2009

Topic (Problem): DESIGN STAGE

Discussion Held: The design stage takes as its initial input the requirements identified in the

approved requirements document. For each requirement, a set of one or more

design elements will be produced as a result of interviews, workshops, and/or

prototype efforts.

Design elements describe the desired software features in detail, and generally

include functional hierarchy diagrams, screen layout diagrams, tables of business

rules, business process diagrams, pseudocode, and a complete entity-relationship

diagram with a full data dictionary. These design elements are intended to

describe the software in sufficient detail that skilled programmers may develop

the software with minimal additional input.

Project Plan & Schedule

Requirements

Traceability Matrix

Design Stage

Requirements Document

Design Document

When the design document is finalized and accepted, the RTM is updated to show

that each design element is formally associated with a specific requirement. The

outputs of the design stage are the design document, an updated RTM, and an

updated project plan.


DAILY REPORT

Week No. : 3 Day: 16 Date: 18.07.2009

Topic (Problem): Designing for Life care multi services

Usecase Diagram

Discussion Held: Creating Use Case Diagrams

Over the previous two articles, we took a brief look at the nine UML diagrams and what

kind of tools you

can use to model UML diagrams. Now that we have our basics clear, we will start our study

of these nine

UML diagrams. Today we will cover the Use case diagram. We will learn the basics of

use case diagrams

and try our hand at drawing a use case diagram. In addition, we will see what a use case

specification is.

Finally, we will attempt to apply what we have learned of use cases and model the use

case diagrams for

our case study application—the Courseware Management System.

Elements of a Use Case Diagram

A use case diagram is quite simple in nature and depicts two types of elements: one

representing the

business roles and the other representing the business processes. Let us take a closer look

at use at what

elements constitute a use case diagram.

Actors: An actor portrays any entity (or entities) that performs certain roles in a given

system. The

different roles the actor represents are the actual business roles of users in a given system.

An

actor in a use case diagram interacts with a use case. For example, for modeling a banking

application, a customer entity represents an actor in the application. Similarly, the person

who

provides service at the counter is also an actor. But it is up to you to consider what actors

make an

impact on the functionality that you want to model. If an entity does not affect a certain

piece of

functionality that you are modeling, it makes no sense to represent it as an actor. An actor

is shown

as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in Figure

Figure 3.1: an actor in a use case diagram

To identify an actor, search in the problem statement for business terms that portray roles

in the

system. For example, in the statement "patients visit the doctor in the clinic for medical

tests,"

"doctor" and "patients" are the business roles and can be easily identified as actors in the

system.

Use case: A use case in a use case diagram is a visual representation of a distinct

business

functionality in a system. The key term here is "distinct business functionality." To choose a

business process as a likely candidate for modeling as a use case, you need to ensure that

the

business process is discrete in nature. As the first step in identifying use cases, you should

list the

discrete business functions in your problem statement. Each of these business functions

can be

classified as a potential use case. Remember that identifying use cases is a discovery

rather than a

creation. As business functionality becomes clearer, the underlying use cases become

more easily

evident. A use case is shown as an ellipse in a use case diagram (see Figure 3.2).

Figure 3.2: use cases in a use case diagram

Figure 3.2 shows two uses cases: "Make appointment" and "Perform medical tests" in the

use case

diagram of a clinic system. As another example, consider that a business process such as

"manage

patient records" can in turn have sub-processes like "manage patient's personal

information" and

"manage patient's medical information." Discovering such implicit use cases is possible

only with a

thorough understanding of all the business processes of the system through discussions

with

potential users of the system and relevant domain knowledge.

System boundary: A system boundary defines the scope of what a system will be. A

system

cannot have infinite functionality. So, it follows that use cases also need to have definitive

limits

defined. A system boundary of a use case diagram defines the limits of the system. The

system

boundary is shown as a rectangle spanning all the use cases in the system.

Figure 3.3: a use case diagram depicting the system boundary of a clinic

application

Figure 3.3 shows the system boundary of the clinic application. The use cases of this

system are

enclosed in a rectangle. Note that the actors in the system are outside the system

boundary.

The system boundary is potentially the entire system as defined in the problem statement.

But this

is not always the case. For large and complex systems, each of the modules may be the

system

boundary. For example, for an ERP system for an organization, each of the modules such

as

personnel, payroll, accounting, and so forth, can form the system boundary for use cases

specific to

each of these business functions. The entire system can span all of these modules

depicting the overall system boundary.

DAILY REPORT

Week No. : 3 Day: 17 Date: 16.07.2009

Login

User Management

Rank Management

Service Card

Voucher

AdministratorOwner

OperatorOfficer

Life Care Insureance

Use Case Diagram

s

DAILY REPORT

Day: 18 Date: 20.07.2009

Topic (Problem): E-R Diagram for life care multi Services

Discussion Held: ) ENTITY-RELATIONSHIP DIAGRAM:

In software engineering, an Entity-Relationship Model (ERM) is an abstract and conceptual

representation of data. Entity-relationship modeling is a database modeling method, used to produce

a type of conceptual schema or semantic data model of a system, often a relational database, and its

requirements in a top-down fashion.

An entity may be defined as a thing which is recognized as being capable of an independent

existence and which can be uniquely identified. An entity is an abstraction from the complexities of

some domain. When we speak of an entity we normally speak of some aspect of the real world

which can be distinguished from other aspects of the real world.

An entity may be a physical object such as a house or a car, an event such as a house sale or a car

service, or a concept such as a customer transaction or order. Although the term entity is the one

most commonly used, following Chen we should really distinguish between an entity and an entity-

type. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type.

There are usually many instances of an entity-type. Because the term entity-type is somewhat

cumbersome, most people tend to use the term entity as a synonym for this term.

Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical

theorem. Entities are represented as rectangles.

A relationship captures how two or more entities are related to one another. Relationships can be

thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company

and a computer, a supervises relationship between an employee and a department, a performs

relationship between an artist and a song, a proved relationship between a mathematician and a

theorem. Relationships are represented as diamonds, connected by lines to each of the entities in the

relationship.

Entities and relationships can both have attributes.. Attributes are represented as ellipses connected

to their owning entity sets by a line.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes,

which is called the entity's primary key.

Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they

show entity sets and relationship sets. Example: a particular song is an entity. The collection of all

songs in a database is an entity set. The eaten relationship between a child and her lunch is a single

relationship. The set of all such child-lunch relationships in a database is a relationship set.

Lines are drawn between entity sets and the relationship sets they are involved in. If all entities in an

entity set must participate in the relationship set, a thick or double line is drawn. This is called a

participation constraint. If each entity of the entity set can participate in at most one relationship in

the relationship set, an arrow is drawn from the entity set to the relationship set. This is called a key

constraint. To indicate that each entity in the entity set is involved in exactly one relationship, a thick

arrow is drawn.

DAILY REPORT

Week No. : 3 Day: 19 Date: 21.07.2009

Topic (Problem): E-R Diagram for life care multi Services

Discussion Held:

s

DAILY REPORT

Week No. : 3 Day: 20 Date: 22.07.2009

Topic (Problem): Data Flow Diagram for lifecare multi services

Discussion Held: ) DATA FLOW DIAGRAM:

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an

information system. DFDs can also be used for the visualization of data processing (structured

design).

On a DFD, data items flow from an external data source or an internal data store to an internal data

store or an external data sink, via an internal process.

A DFD provides no information about the timing or ordering of processes, or about whether

processes will operate in sequence or in parallel. It is therefore quite different from a flowchart,

which shows the flow of control through an algorithm, allowing a reader to determine what

operations will be performed, in what order, and under what circumstances, but not what kinds of

data will be input to and output from the system, nor where the data will come from and go to, nor

where the data will be stored.

Context Level Diagram

DAILY REPORT

Week No. : 3 Day: 21 Date: 22.07.2009

LEVEL 0:

This level shows the overall context of the system and its operating environment and shows the

whole system as just one process. It does not usually show data stores, unless they are "owned"

by external systems, e.g. are accessed by but not maintained by this system, however, these

are often shown as external entities.

SYSTEMDatabaseManager

INPUT OUTPUT

0 Level DFD

LEVEL 1:

This level (level 1) shows all processes at the first level of numbering, data stores, external

entities and the data flows between them. The purpose of this level is to show the major high-

level processes of the system and their interrelation. A process model will have one, and only

one, level-1 diagram. A level-1 diagram must be balanced with its parent context level diagram,

i.e. there must be the same external entities and the same data flows, these can be broken

down to more detail in the level 1, e.g. the "enquiry" data flow could be spilt into "enquiry

request" and "enquiry results" and still be valid.

DAILY REPORT

Week No. : 3 Day: 22 Date: 23.07.2009

Topic (Problem): Class Diagram

Discuss:

4.1.2 CLASS DIAGRAM

In software engineering, a class diagram in the Unified Modeling Language (UML), is a

type of static structure diagram that describes the structure of a system by showing the

system's classes, their attributes, and the relationships between the classes.

Elements of a Class Diagram

A class diagram is composed primarily of the following elements that represent the

system's business

entities:

Class: A class represents an entity of a given system that provides an encapsulated

implementation

of certain functionality of a given entity. These are exposed by the class to other classes as

methods. Apart from business functionality, a class also has properties that reflect unique

features

of a class. The properties of a class are called attributes. Simply put, individual members

of a family

of our family tree example are analogous to classes in a class diagram.

As an example, let us take a class named Student. A Student class represents student

entities in a

system. The Student class encapsulates student information such as student id #, student

name,

and so forth. Student id, student name, and so on are the attributes of the Student class.

The

Student class also exposes functionality to other classes by using methods such as

getStudentName(), getStudentId(), and the like. Let us take a look at how a class is

represented in

a class diagram.

A class is represented by a rectangle. The following diagram shows a typical class in a

class

diagram:

Figure 4.1.1—

Held: DAILY REPORT

Week No. : 3 Day: 23 Date: 24.07.2009

Topic (Problem): Class Diagram for lcms

DAILY REPORT

Week No. : 3 Day: 24 Date: 25.07.2009

Topic (Problem): Activity Diagram

Activity Diagram in UML

In the previous article, we learned about State diagrams, the notations to be

used in State diagrams,

their significance, and how to build a State diagram for a specific scenario in our

Courseware

Management system.

In this article, we will cover the next dynamic diagram—the Activity diagram. By

the end of this article,

you will know what an Activity diagram is, what its elements are, and you will

be able to create

Activity diagrams for your system.

Basics

The easiest way to visualize an Activity diagram is to think of a flowchart of a

code. The flowchart is

used to depict the business logic flow and the events that cause decisions and

actions in the code to

take place.

Activity diagrams represent the business and operational workflows of a

system. An Activity diagram is

a dynamic diagram that shows the activity and the event that causes the object

to be in the particular

state.

So, what is the importance of an Activity diagram, as opposed to a State

diagram? A State diagram

shows the different states an object is in during the lifecycle of its existence in

the system, and the

transitions in the states of the objects. These transitions depict the activities

causing these transitions,

shown by arrows.

An Activity diagram talks more about these transitions and activities causing

the changes in the object

states.

Defining an Activity diagramLet us take a look at the building blocks of an Activity diagram.

DAILY REPORT

Week No. : 3 Day: 25 Date: 23.07.2009

UpdateUser

displayerror

Manage User

Create NewUser

ModifyUser

Fenerate newList

Enter UserDetails

Generate userList

Edit aRow

Store Data

DAILY REPORT

Week No. : 3 Day: 26 Date: 27.07.2009

Topic (Problem): Sequence Diagram

Sequence Diagram in UML

In the last article, we saw Activity diagrams, the notations to be used in Activity

diagrams, their

significance, and how to build an Activity diagram. We then made an Activity

diagram for a specific

scenario in our Courseware Management system. One of the most widely used

dynamic diagrams in

UML is the Sequence diagram, which is the topic of our discussion today. By the

end of this article, you

will know what a Sequence diagram is, what its elements are, and, you will be

able to create Sequence

diagrams for your system.

Basics

A Sequence diagram depicts the sequence of actions that occur in a system.

The invocation of

methods in each object, and the order in which the invocation occurs is

captured in a Sequence

diagram. This makes the Sequence diagram a very useful tool to easily

represent the dynamic

behavior of a system.

A Sequence diagram is two-dimensional in nature. On the horizontal axis, it

shows the life of the

object that it represents, while on the vertical axis, it shows the sequence of the

creation or invocation

of these objects.

Because it uses class name and object name references, the Sequence diagram

is very useful in

elaborating and detailing the dynamic design and the sequence and origin of

invocation of objects.

Hence, the Sequence diagram is one of the most widely used dynamic diagrams

in UML.

Defining a Sequence diagram

A sequence diagram is made up of objects and messages. Objects are

represented exactly how they

have been represented in all UML diagrams—as rectangles with the underlined

class name within the

rectangle. A skeleton sequence diagram is shown in Figure 8.1. We shall discuss

each of these

elements in the next section:

DAILY REPORT

Week No. : 3 Day: 27 Date: 23.07.2009

DAILY REPORT

Week No. : 3 Day: 28 Date: 28.07.2009

Topic (Problem): Screen Layouts for lc

DAILY REPORT

Week No. : 3 Day: 29 Date: 29.07.2009

Topic (Problem): Screen Layouts

DAILY REPORT

Week No. : 3 Day: 30 Date: 30.07.2009

Topic (Problem): Screen Layout

DAILY REPORT

Week No. : 3 Day: 31 Date: 31.07.2009


DAILY REPORT

Week No. : 3 Day: 32 Date: 01.08.2009


DAILY REPORT

Week No. : 3 Day: 33 Date: 03.08.2009


DAILY REPORT

Week No. : 3 Day: 34 Date: 04.08.2009

Topic (Problem): Screen Layoot

DAILY REPORT

Week No. : 3 Day: 35 Date: 05.08.2009


DAILY REPORT

Week No. : 3 Day: 36 Date: 06.08.2009

Topic (Problem): DEVELOPMENT STAGE

Discussi DEVELOPMENT STAGE

The development stage takes as its primary input the design elements described in

the approved design document. For each design element, a set of one or more

software artifacts will be produced. Software artifacts include but are not limited

to menus, dialogs, data management forms, data reporting formats, and

specialized procedures and functions. Appropriate test cases will be developed

for each set of functionally related software artifacts, and an online help system

will be developed to guide users in their interactions with the software.

DesignDocuments

DevelopmentStages

Software Online Help Updated ProjectPlan &

Scheduling

Implimentationmap Test Plan

Updated Requirement&

Tracebility matrix

The RTM will be updated to show that each developed artifact is linked to a

specific design element, and that each developed artifact has one or more

corresponding test case items. At this point, the RTM is in its final configuration.

The outputs of the development stage include a fully functional set of software

that satisfies the requirements and design elements previously documented, an

online help system that describes the operation of the software, an implementation

map that identifies the primary code entry points for all major system functions, a

test plan that describes the test cases to be used to validate the correctness and

completeness of the software, an updated RTM, and an updated project plan



Name: STUDENT NAME

Week No. : 3 Day 37 Date:07.08.2009

Problem/Project Undertaken: INTEGRATION & TEST STAGE

Discussion Held: INTEGRATION & TEST STAGE

During the integration and test stage, the software artifacts, online help, and test

data are migrated from the development environment to a separate test

environment. At this point, all test cases are run to verify the correctness and

completeness of the software. Successful execution of the test suite confirms a

robust and complete migration capability.

During this stage, reference data is finalized for production use and production

users are identified and linked to their appropriate roles. The final reference data

and production user list are compiled into the Production Initiation Plan.

The outputs of the integration and test stage include an integrated set of software,

an online help system, an implementation map, a production initiation plan that

describes reference data and production users, an acceptance plan which contains

the final suite of test cases, and an updated project plan

Software Online Help ImplimentationMap Test Plan

Integration &Test Stages

IntegraatedSoftware

Implimentationmap Online Help

Production InitiationPlan

AcceptancePlan

UpdatedProject Plan

&Schedule

ra

Literature Consulted: Signature of Trainee


Name: STUDENT NAME

Week No. : 3 Day 38 Date:08.08.2009

Problem/Project Undertaken: INSTALLATION & ACCEPTANCE STAGE

Discussion Held: INSTALLATION & ACCEPTANCE STAGE

During the installation and acceptance stage, the software artifacts, online help,

and initial production data are loaded onto the production server. At this point, all

test cases are run to verify the correctness and completeness of the software.

Successful execution of the test suite is a prerequisite to acceptance of the

software by the customer.

After customer personnel have verified that the initial production data load is

correct and the test suite has been executed with satisfactory results, the customer

formally accepts the delivery of the software.

ProductionInitiation Plan

AcceptancePlan

IntegratedSoftware Online Help

Implementationmap

ProductionSoftware

CompleteAcceptance

Test

CustomerAcceptance

Memorandom

AchiveSoftware Artifact

Achive ProjectPlan &

Scheduling

Installation &Acceptance Stage

The primary outputs of the installation and acceptance stage include a production

application, a completed acceptance test suite, and a memorandum of customer

acceptance of the software. Finally, the PDR enters the last of the actual labor

data into the project schedule and locks the project as a permanent project record.

At this point the PDR "locks" the project by archiving all software items, the

implementation map, the source code, and the documentation for future reference.


Name: STUDENT NAME

Week No. : 3 Day 39 Date:10.08.2009

Problem/Project Undertaken: Testing

Discussion Held

Testing is the methodological approach to validate and verify any software product on the bases

of client requirement. There are four desirable characteristics :

(1) Requirement Coverage

(2) Deadline (with in time)

(3) Cost (Budget)

(4) Maintenance (flexibility)

Testing

White Box

Black Box

Unit/Component Testing

Integration Testing

Regression Testing

System Testing

User Acceptance Testing

Unit Testing: Test the single module of whole project

Integration Testing: Modules are combined and the test whole project.

Regration Testing: Retesting of product.

System Testing: In this functionality, hardware, software, and time are test according to cost.

User Expectance Testing: It includes two types of testing:

(1)Alpha Testing: It is performed on the client side in presence of developer.

(2)Beta Testing: It performed by organization but developer is not present.

Generally for testing Automation Testing Tools are used, it works on the principle of macros.

(1)Win Runner

(2)QTP

(3)Load Runner

(4)Test Director

For C language and Test scripting languages

Win Runner is used.

VB Scripting QTP is used

Examples of Testing

[1](4195835/3145727)*3145727-4195835

If ans = 0 then the processor is “NEW”

If ans != 0 then the processor is “OLD”

[2] In Microsoft word

=r and (100,100)

IT VT Report

Documents

Transcript of IT VT Report