PRACTICAL: - 1

AIM: - Introduction to basic concepts used in Project Managment.

A Project is a series of activities leading to defined goals achieved in a specific timeframe. A
project always has a specific start date and end date. These activities (tasks) have to be
accomplished in a distinct order by the means of a allocated resources (manpower, machines,
materials, costs) so that the framework of time, cost and deliverables is met. Generally
speaking a project should have the following characteristics:a) Time Limitation: - Both a start point and an endpoint must be defined for a project.
Initially it is common for just a start date to be specified and resultant project plan will
determine the end date.
b) Clear Objective: - The objective to be achieved by the project must be clearly
defined.
c) Process Structure: - The project must split up into clearly defined tasks. It should not
represent a singular process from beginning to end, but broken down into distinct
stages.
d) Organizational Structure: - The projects often require an established organizational
structure with unique skills sets to be effective, but this does depend somewhat on the
scale of project.
The Project Management is the planning and control of a project. It allows the user to
resolve conflicts in a a continusoly changing environment and is necessary to continusoly
drive towards the achievements of the baseline project goals. Because project management
should ideally result in the fulfilment of all set targets, a significant part of the project
managers work is dealing with conflicts arising from unforeseen resource and task
variations. Due to absence of planned staff, the project cannot be completed within the
allotted time (schedule variance). The increase of working capacity through overtime would
cause additional costs (cost variance) or a possible reduction of scope would change the
project deliverables (scope variance). The certain terminology is used in project management
so it would be useful to familiarize with some of these phrase now.

Tasks: - The partial activities from which the overall project is composed are called
tasks. They are the smallest units/steps in a project.

Duration: - The period between the start time and the finish time of tasks.

Predecessors: - A task must be processed before a future dependent tasks can be

started.

Successors: - A tasks that can only be started if a previous dependent tasks has been
processed.

Milestones: - The milestones are important intermediate objectives. They often define
a phase transitions, critical project stages or intermediate results. They are usually
represented as tasks that have no durations.

Summary Tasks: - Each chunk of a project with multiple tasks should be headed by
parent task which is known as summary tasks. The summary tasks usually terminates
with a milestones and have a fixed result (output). The summary tasks have a duration
assigned automatically from their subtasks duration and dependencies.

Slack: - Free slack is how much a task can delay without impacting the other tasks.
The total slack is how much tasks can delay without impacting on the end dates of
project.

Critical Paths: - The shortest path from beginning to end of the project. Only tasks
without slack exists on this path (critical path) and are called critical tasks. The
project end date is automatically extended if a task on the critical path slips or has an
extended duration.

Resources: - The resources refer to all people, time, production, and materials
required to deliver the project. A mapping of required resources can be performed for
each task. The reliable cost planning is the only possible when real resources and
costs are mapped to tasks.

Forward Schedule: - This is where a start date is set for the project and the end date
is automatically calculated from the duration of operations and the tasks
dependencies.

Backward Schedule:- This is where a deadline is set for the project and the latest
possible project start is automatically calculated from the duration of operations and
the task dependencies.

Fixed Duration Tasks: - The duration of tasks is set, regardless of how many
resources are assigned to it.

Effort driven Tasks: - The duration of task is dependent on how many resources of
the same type assigned to it. For e.g. a deliverables is produced in less time with three
employees than with one.

PRACTICAL: - 2
AIM: - Introduction to OpenProj Software.
OpenProj is a free, open-source project management solution. OpenProj is ideal for desktop
project management and supports opening Microsoft or Primavera files. OpenProj 1.4 is an
open source desktop project management application.This application is an alternative to
Microsoft Project. OpenProj provides control, tracking and management of projects. To
create a new project the only field required is the Project Name on the Create New Project
window and the start date of the project can be change it if you dont want to start the day
that youre creating your project. You can add tasks in the Gantt diagram providing the start
and end dates of each task; also you can add information to each task such the predecessors
and successors tasks, resources, notes, etc. One great feature is that provides the Work
Breakdown Structure (WBS) to order and control the tasks of the project for people who
manages projects this is a very important tool. Another great feature is the Resources
Breakdown Structure (RBS) to define the structure of the resources, teams, providers, etc.
Task Usage and Resource Usage are features to control your project and provide a good track
on it. The Report tool provides information about the current status of your project.

OpenProj provides tools to open at the bottom of the window and provide different views of
the project at the same time; Histogram, Chart, Task Usage and Resource Usage are the tools
that you can open at the bottom of the window to have a better perspective of the advance or
delay on you r projects.
Any company may benefit from the use of OpenProj. Customers from Fortune 500
companies to small businesses have used the software to improve business processes and
efficiency. Examples of companies that have used the product include: AT&T, Tyson, ADP,
Nokia, UBS, Lockheed Martin, Thomson Reuters, Johnson & Johnson, Pfizer, Virgin, GE
Medical and Panasonic. Each company has benefitted from this free open source software
and over 100 more have used the software as well. This project management software
provides the tools needed to keep a good project management.
The GUI is friendly and easy to use, very intuitive if you are get use to work managing
projects. The installation process is very easy to perform and it requires Java 5 minimum or
Java 6 recommended.OpenProj works on Linux, Unix, Mac or Windows platforms, and it's
free.
The features of OpenProj are as follows: Gantt chart:- A Gantt chart is a type of bar chart, developed by Henry Gantt in the
1910s, that illustrates a project schedule. Gantt charts illustrate the start and finish
dates of the terminal elements and summary elements of a project. Terminal elements
and summary elements comprise the work breakdown structure of the project. Modern
Gantt charts also show the dependency (i.e. precedence network) relationships
between activities.
PERT graph:- The Program (or Project) Evaluation and Review Technique,
commonly abbreviated PERT, is a statistical tool, used in project management, that is
designed to analyze and represent the tasks involved in completing a given project.
First developed by the United States Navy in the 1950s, it is commonly used in
conjunction with the critical path method (CPM).
Resource Breakdown Structure (RBS) chart:- In project management, the resource
breakdown structure (RBS) is a hierarchical list of resources related by function and
resource type that is used to facilitate planning and controlling of project work.[1] The
Resource Breakdown Structure includes, at a minimum, the personnel resources
needed for successful completion of a project, and preferably contains all resources on

which project funds will be spent, including personnel, tools, machinery, materials,
equipment and fees and licenses. Money is not considered a resource in the RBS; only
those resources that will cost money are included. Assignable resources, such as
personnel, are typically defined from a functional point of view: "who" is doing the
work is identified based on their role within the project, rather than their department
or role within the parent companies. In some cases, a geographic division may be
preferred. Each descending (lower) level represents an increasingly detailed
description of the resource until small enough to be used in conjunction with the work
breakdown structure (WBS) to allow the work to be planned, monitored and
controlled.
Work Breakdown Structure (WBS) chart: - A work breakdown structure (WBS),
in project management and systems engineering, is a deliverable oriented
decomposition of a project into smaller components.A work breakdown structure
element may be a product, data, service, or any combination thereof. A WBS also
provides the necessary framework for detailed cost estimating and control along with
providing guidance for schedule development and control.

PRACTICAL:-3
AIM:- To create projects in OpenProj Software.
1. Having downloaded and installed the OpenProj software; start OpenProj from the start
menu of Windows or via the icon on your desktop. After the license agreement, OpenProj
starts with a choice of creating a new project or opening an existing one. Choose Create
Project

2. Enter a name for the project, the project managers name and a start date (which can also
be modified later if required). Provide a description in the Notes section as you see fit.

3. The application window will be displayed consisting of following main components:

Indicator Column:- In this column, symbols are displayed to show the status
of the corresponding tasks (see right).

Task Number Column:- Task numbers are assigned by OpenProj

automatically when data is entered. The user does not enter information into
this box.

Time Scale. In many views, OpenProj shows a timeline whose scale can be
changed via the + and - magnifying glass icon on the menu above.

Information View Type:- The area along the left side of the window lists a
number of buttons representing the available views. Gantt, Network,
Resources, WBS (work breakdown structure), RBS (resource breakdown
structure), Reports, Task Usage and Resource Usage.

The lower view buttons open a split-screen where resource mapping tables and resource
utilization as a graphic can be displayed. You can toggle views on and off by clicking the
same button repeatedly.

PRACTICAL :-4
AIM:- To adjust the calendar while creating project in OpenProj Software.
For accurate tracking of your project it is essential to first set up the OpenProj calendar to
reflect the working hours in your organization. OpenProj offers three default calendars:

Standard Calendar (Mon-Fri, 08:00 to 17:00 with 1hr lunch break at noon)

Night Shift (Mon-Sat 23:00 to 08:00 with a 1hr break from 03:00 to 04:00)

24-Hour Calendar (24/7 schedule)

You can assign any one of these to be your project calendar; however none of the default
calendars contain public holidays so it is often necessary to create your own custom calendar
to reflect your companys general working hours.
1. Open the Calendar with the menu tool Tools Change Working Calendar .

Standard Calendar

24 Hours Calendar

Night Shift Calendar

2. Click on New to create a new calendar.

3. Enter a name for your new calendar and click OK.
4. Mark the days for which you want to change the working time (e.g. for all Fridays
you can click the column header F, or you can hold ctrl and click to select
individual days). To make a global selection you would hold ctrl and click
S,M,T,W,F,S in turn.
5. Click Non-default working time on the left and change the working hours
within the fields below.
6. To mark company or public holidays, select the relevant days as above and click
Non-working time.
7. Edited calendar entries will appear in red.
8. Click Options at the bottom to set the corresponding working hours per day,
hours per week and days per month. If you do not do this, OpenProj will not
schedule the tasks correctly.
9. Confirm changes by clicking OK.

10. You must now assign your custom Project calendar to your project. To do this,
click Project Project Information from the top menu and set the Base
Calendar to your new custom base calendar name. This is also the screen where
you enter the Project Start Date. Click close when done.

OpenProj can also associate calendars to individuals and to specific tasks. In this way you can
designate individual vacation periods or you can specify a task to follow a different schedule
to the one in your base calendar. So, in fact you can use three different types of calendars
within your project:
1. Project calendar (your base calendar for the project as defined above)
2. Resource calendar (for individuals working time and vacation days)
3. Task calendar (for tasks that do not follow the regular working hours, e.g. a task cannot
start on a Friday because it would be interrupted by the weekend or maybe a task that runs
continuously for 24hrs).
The calendar is stored with the particular project file, so if you start another project it is
necessary to create the user defined calendar again.

PRACTICAL: - 5
AIM:- To create Gantt Charts and Network charts in OpenProj Software.
When you create a new project, OpenProj by default opens the Gantt chart view on the right
pane and the task input table on the left pane. You can drag the vertical line dividing the two
panes to fit your monitor as you desire. To enter a task:
1. Click in the Name column in the first row.
2. Enter a name for the task.
3. Confirm the input by clicking the mouse or pressing the tab button which takes you to
the duration entry field.
4. If you do not know the duration at this stage you do not have to input it. OpenProj
enters a default value of 1day? which you can alter at a later stage.
5. If you have an estimate of the duration, then feel free to enter it into the cell.
OpenProj automatically converts the duration to days. For example, enter 1w (1 week)
and OpenProj will set the duration to 5 days. The input of 1 month would result in a
display of 20 days and 1 hour would be displayed as 0.125 days (or 1/8th of a day).
6. Confirm the input by pressing Enter or clicking on the next row.
7. It is important that you enter only task names and durations at this stage. Do not be
tempted to enter any other information right now. Especially not a starting date.
8. Its good practice even at this stage to enter general headings (phases) for tasks e.g
Design and then more specific tasks underneath, but never enter a duration for a
general heading.

1. GANTT CHARTS
A Gantt chart, commonly used in project management, is one of the most popular and useful
ways of showing activities (tasks or events) displayed against time. On the left of the chart is
a list of the activities and along the top is a suitable time scale. Each activity is represented by
a bar; the position and length of the bar reflects the start date, duration and end date of the
activity. This allows you to see at a glance:

What the various activities are

When each activity begins and ends

How long each activity is scheduled to last

Where activities overlap with other activities, and by how much

The start and end date of the whole project

To summarize, a Gantt chart shows you what has to be done (the activities) and when (the
schedule).

Gantt Chart

2. Network Chart
A network diagram is essentially a flow chart that includes all of the project elements and
how they relate to one another. It shows parallel activities and the links between each
activity. Network logic is the collection of activity dependencies that make up a network
diagram for a particular project. In other words, certain tasks are dependent on one another to
complete the project. This creates a logical stream of events that will lead to completion of
the project. The network diagram lets you do the following:

Define the project's path

Determine the sequence of tasks to be completed

Look at the relationship between activities

Determine the dependencies

Make adjustments as tasks are completed

Take a broad look at the project path and clearly see the relationships and dependencies
between tasks

CLICK View and then Network diagram. It wiil then generate the diagram shown
below.

Network Chart

PRACTICAL:- 6
AIM :- To set dependencies and establishes deadlines in OpenProj software.
Dependencies allow you to show the relationships between tasks and set rules for when tasks
can be started or finished. OpenProj uses four types of dependencies:

FS (Finish-to-Start):- This is the default relationship in OpenProj. It defines that one

task has to finish before the next one can start. For Example, printing a document
cannot start until editing the document is finished.

SS (Start-to-Start):- The start of a task is dependent on the start of its predecessor. In

other words, the task can only start after the predecessor task has started (or at a later
date)

FF (Finish-to-Finish):- The completion of a task is dependent on the completion of

its predecessor. In other words, the task can only finish at the same time (or after) the
previous task has finished

SF (Start-to-Finish):- The finish of the next task depends on the start of the previous
task. In other words, the first task begins after the second task ends.

When dependencies are created, the start and finish dates of tasks are usually affected.
OpenProj automatically edits start and finish dates so that they adhere to these new
constraints. Any change to dependencies will update task dates and Gantt bars automatically.
You can link tasks listed below. If you make a mistake at any time you can undo with the
menu: Edit-Undo or press Ctrl-Z. The following steps are taken to set dependencies.
1. Select the task rows in the table that are to be linked with a dependency. In the
example above we know all the tasks are dependent on each other, so we will select
rows 2,3,4,5 & 6 with the mouse and click (menu: Edit / Link) or simply click the
task linking icon .
2. You will see that all the tasks have now become dependent on each other with one
click, rather than typing each individual task dependency in manually. You can select
multiple or separated rows by using the CTRL-click action (for multiple selections).

You can delete dependencies by clicking on the number in the predecessors box and
deleting it with the delete key. Alternatively you can select the linked tasks in the table and
use the menu item Edit Unlink or click the icon or click the link line between the two tasks
in the Gantt chart and select the Remove option in the pop-up menu.

All task-related information is managed centrally via the Task Information window. For
every task you have the ability to modify information and task settings within six tabs. Its
good practice to edit information in this menu rather than in the columns in the table view of
the spreadsheet. The editing window consists of following tabs as follows.

General: - General task date information and percentage complete information.

Predecessors: - List of all predecessor tasks and dependency type settings.
Successors: - Information about successor tasks and dependency type settings.
Resources: - Shows the assigned resources and allocations for this task.
Advanced: - Task type and date constraint information.
Notes Allows entry of notes about the task.

Deadlines are used to monitor the progress of individual tasks. A deadline set for a particular
date will trigger a notification as soon as that date slips and an icon in the indicator column is
displayed. Deadlines also appear in the Gantt chart as yellow diamonds. To set a deadline:
1. Select the task in Name column for which youd like to apply a deadline.
2. Open the task information Dialog Box by double-clicking the task name, or click the
icon.
3. Select the Advanced tab and enter the desired date into the Deadline: field.
4. Confirm your entry and click Close.

PRACTICAL 7

AIM: To study the Data Flow Diagrams of various case studies.

DATA FLOW DIAGRAM

A data flow diagram, also known as bubble chart has the purpose of clarifying system
requirements and identifying major transformation that will become programs in system
design. It is a graphic representation of a system or portion of system. A DFD consists of a
series of bubbles joined by lines. It consists of data flows, processes, sources, destinations
and stores all described through the use of easily understood symbols. An entire system can
be described from the viewpoint of the data it processes with only four symbols. The DFD is
also powerful enough to show parallel activities.

TYPES OF DATA FLOW DIAGRAM

Physical data flow diagram: - Physical data flow diagram is implementation

dependent. They show the actual devices, department, people etc. involved in the
current system.

Logical data flow diagram: - It describes the system independently of how it is

actually implemented, that is , they show what takes place, rather than how an activity
is accomplished.

COMPONENTS OF DATA FLOW DIAGRAM:a) Source or Destination: - The source or destination is graphically represented as a
rectangle. Source or destination external entities with which the system communicates. A
source or destination is a person or a group of persons that are outside the control of the
system being modeled.
b) Data Flow: - The flow is represented graphically by an arrow into or out of a process. The
flow is used to describe the movement of chunks or packet of information from one part of
the system to another part. The flow represents data in motion.
c) Process: - The process shows a part of the system that transforms input into output. The
process is represented graphically as a circle or bubble.
d) Data Store: - The data store is used to model a collection of data packet at rest. The
notation of a data store is two parallel lines. Data stores are typically implemented as files or
databases in computerized system. Data stores are connected by flow to processes.

Data Stores have two types of flow:Basic Symbols for Data Flow Diagram:-

1.
or

= Source or destination of data

2.
= Data Flow

3.

or

= Process that transforms data flow

or

4.

Data Store

In data flow diagrams a single process node on a high level diagram expanded to show a
more detailed data flow diagram. The first level DFD shows the main processes within the
system. Each of these processes can be broken into further processes until we reach pseudo
code.
The various elements used for drawing structure chart using Smart Draw are the following:
1. Circles: Circles are used to represent the process
2. Rectangles: Rectangles are used to represent the external entity.

3. Straight Line: Straight line is formatted to arrow head to show the flow of control from
one process to another and also represents the data flowing from one process to another.
4. Edit Text: To add text to various processes and to define data flowing from one process to
another

CASE STUDY ON RAILWAY RESERVATION SYSTEM

INTRODUCTION
The Railway Reservation system has the following main features :
Traveller may be able to book tickets from any station to any station
Availability of seats can be known at any time
Status of trains can be easily checked
Previous bookings can be easily seen
The system requires the traveler to give the specific details about traveling schedule, it
includes date of journey , source station , destination station, class of traveling , number of
seats to be reserved etc. Clerk will then send the account details to the accountant , who
calculates the actual fare.Supervisor then checks all the details like availability of seat etc and
pass it to the management.

Level1

Level2
CASE STUDY ON UNIVERSITY MANAGEMENT SYSTEM

INTRODUCTION

University is created to provide quality education to the people. A lot of colleges come under
a single university. The administrator & bindings of different colleges is its primary goal. The
secondary goals would be designed to achieve better results of its primary goal.
In order to achieve its goals a proper management system is must. Because its this system
that develops interrelationship b/w different departments and colleges that come under a
university and also between different universities

DATA FLOW DIAGRAM

Level1

Level 2
Hospital management system

Level 1

Inventory dfd
Level 1

Level2
TYPES OF
STOCK

Kinds Of
Items
Avai lable

CUSTOME R

Makes
Request

1. 0
Stock In
Store

Sales

Profit
Earned

NO. OF ITEMS
IN EACH TYPE

Qu antity Of
Items

Items
Brought

AMOUNT
SPENT INFO

Money
Spent

1. 1
Stock
Brou gh t

Pick Type

TRANSPORTATION
CHARGES

Decide
Charges

2.0
Delivery

Pick
Address

STOCK TYPE
1.2
Stock
Sold Out

PROFIT
MADE
Pi ck Type

SOLD OUT
TYPE

Delivery Process
CUSTOMER'S
ADDRESS

PRACTICAL:8

AIM: To study Unified Modeling Language (UML) .

In the field of software engineering, the Unified Modeling Language (UML) is a

standardized visual specification language for object modeling. UML is a general-purpose
modeling language that includes a graphical notation used to create an abstract model of a
system, referred to as a UML model. The Unified Modeling Language or UML is a mostly
graphical modeling language that is used to express designs. It is a standardized language in
which to specify the artifacts and components of a software system. It is important to
understand that the UML describes a notation and not a process. It does not put forth a single
method or process of design, but rather is a standardized tool that can be used in a design
process.
UML diagrams represent three different views of a system model:

Various Diagrams Are:

1.Structural (static) Diagrams:

a) Class diagram:

The class diagram shows how the different entities (people, things, and data) relate to each
other; in other words, it shows the static structures of the system.
Various relationships are:
Dependency represnted by ------------>
Association represented by
Generalization represented by
Realization represented by -----------Boxes represent the class as shown below:

Where the first section gives the class name and the second one gives the attributes and
the last section gives the class operations(methods).
Example: Class diagram of university system.

b) Component Diagram:

A component diagram provides a physical view of the system. Its purpose is to show the
dependencies that the software has on the other software components.

Example: component diagram of university system

c) Object Diagram:

In the Unified Modeling Language (UML), an object diagram is a diagram that shows a
complete or partial view of the structure of a modeled system at a specific time. This
snapshot focuses on some particular set of object instances and attributes, and the links
between the instances. A correlated set of object diagrams provides insight into how an
arbitrary view of a system is expected to evolve over time. Object diagrams are more
concrete than class diagrams, and are often used to provide examples, or act as test cases for
the class diagrams. Only those aspects of a model that are of current interest need be shown
on an object diagram.
Each object and link on an object diagram is represented by an InstanceSpecification. This
can show an object's classifier (e.g. an abstract or concrete class) and instance name, as well
as attributes and other structural features using slots. Each slot corresponds to a single
attribute or feature, and may include a value for that entity.
The name on an instance specification optionally shows an instance name, a ':' separator, and
optionally one or more classifier names separated by commas. The contents of slots, if any,
are included below the names, in a separate attribute compartment. A link is shown as a solid
line, and represents an instance of an association.
Example: object diagram of university system

d) Deployement Diagram:

The deployment diagram shows how a system will be physically deployed

in the hardware environment. Its purpose is to show where the different
components of the system will physically run and how they will
communicate with each other. Since the diagram models the physical
runtime, a system's production staff will make considerable use of this
diagram. The notation in a deployment diagram includes the notation
elements used in a component diagram, with a couple of additions,
including the concept of a node. A node represents either a physical
machine or a virtual machine node (e.g., a mainframe node). To model a
node, simply draw a three-dimensional cube with the name of the node at
the top of the cube. Use the naming convention used in sequence
diagrams: [instance name] : [instance type].
Example: deployement diagram of university system

2. Functional(Dynamic) Diagrams:

a) Sequence Diagrams:

Sequence diagrams show a detailed flow for a specific use case or even just part of a specific
use case. They are almost self explanatory; they show the calls between the different objects
in their sequence and can show, at a detailed level, different calls to different objects.

A sequence diagram has two dimensions: The vertical dimension shows the sequence of
messages/calls in the time order that they occur; the horizontal dimension shows the object
instances to which the messages are sent.
A sequence diagram is very simple to draw. Across the top of your diagram, identify the class
instances (objects) by putting each class instance. Reading a sequence diagram is very
simple. Start at the top left corner with the "driver" class instance that starts the sequence.
Then follow each message down the diagram.
Example: Sequence diagram of university system

b) Use Case Diagram:

A use case illustrates a unit of functionality provided by the system. The main purpose of the
use-case diagram is to help development teams visualize the functional requirements of a
system, including the relationship of "actors" (human beings who will interact with the
system) to essential processes, as well as the relationships among different use cases. Usecase diagrams generally show groups of use cases -- either all use cases for the complete
system, or a breakout of a particular group of use cases with related functionality. To show a
use case on a use-case diagram, you draw an oval in the middle of the diagram and put the
name of the use case in the center of, or below, the oval. To draw an actor (indicating a
system user) on a use-case diagram, you draw a stick person to the left or right of your
diagram. Use simple lines to depict relationships between actors and use cases.
Example: use case diagram of university system

c) Activity Diagram:

Activity diagrams show the procedural flow of control between two or more class objects
while processing an activity. Activity diagrams can be used to model higher-level business
process at the business unit level, or to model low-level internal class actions. activity
diagrams are best used to model higher-level processes, such as how the company is currently
doing business, or how it would like to do business. This is because activity diagrams are
"less technical" in appearance, compared to sequence diagrams, and business-minded people
tend to understand them more quickly.
An activity diagram's notation set is similar to that used in a statechart diagram. Like a
statechart diagram, the activity diagram starts with a solid circle connected to the initial
activity. The activity is modeled by drawing a rectangle with rounded edges, enclosing the
activity's name. Activities can be connected to other activities through transition lines, or to
decision points that connect to different activities guarded by conditions of the decision point.
Activities that terminate the modeled process are connected to a termination point (just as in a
statechart diagram). Optionally, the activities can be grouped into swimlanes, which are used
to indicate the object that actually performs the activity.

Example : Activity diagram of university system

d) StateChart Diagram:

The statechart diagram models the different states that a class can be in and how that class
transitions from state to state. It can be argued that every class has a state, but that every class
shouldn't have a statechart diagram. Only classes with "interesting" states -- that is, classes
with three or more potential states during system activity -- should be modeled. the initial
starting point, which is drawn using a solid circle; a transition between states, which is drawn
using a line with an open arrowhead; a state, which is drawn using a rectangle with rounded
corners; a decision point, which is drawn as an open circle; and one or more termination
points, which are drawn using a circle with a solid circle inside it. To draw a statechart
diagram, begin with a starting point and a transition line pointing to the initial state of the
class. Draw the states themselves anywhere on the diagram, and then simply connect them
using the state transition lines.
Example: Statechart diagram of university system

e) Collaboration Diagram:
An interaction diagram captures the behaviour of a single case by showing the collaboration
of the objects in the system to accomplish the task. These diagrams show objects in the
system and the messages that are passed between them.In this the methods on the various
clasees are numberd.
Example: Collaboration diagram of university system

PRACTICAL 9

AIM: Introduction to Beta Testing.

BETA TEST
In software and Web development, a beta test is the second phase of testing in which a
sampling of the intended audience tries the product out. (Beta is the second letter of the
Greek alphabet.) Originally, the term alpha test meant the first phase of testing in a software
development process. The first phase includes unit testing, component testing, and system
testing. Beta testing can be considered "pre-release testing.

In software engineering, development stage terminology expresses how the development of a

piece of software has progressed and how much further development it may require. Each
major version of a product usually goes through a stage when new features are added (alpha
stage), then a stage when it is actively debugged (beta stage), and finally a stage when all
important bugs have been removed (stable stage). Intermediate stages may also be
recognized.

The software has reached "beta" stage when it is operating with most of its functionality, and
is ready for user feedback. During the beta test, end users who will likely use the software
perform testing and provide feedback to EPRI and the developers. EPRI requires obtaining
feedback from at least one beta tester who is an actual user outside EPRI. Recommended are
5-10 beta testers. EPRI Corporate Software Quality must review all beta software before it is
sent to beta testers

BETA TESTING

Beta testing is a common final check on system content and accuracy. When feature or defect
problems come back from beta testing, that's bad news, and we might have to freeze the code.
Therefore, treat beta testing as "business as usual".
The Purpose of Beta Testing
Most commonly, we do beta testing because someone somewhere wants a final check that
everything is OK. In XP terms, we fear that if we don't beta test, something bad will happen.
Beta testing is done to alleviate that fear.
One of the XP values is Courage. If the organization feels enough fear to want to do beta
testing, then I'd like to suggest that there is not enough courage. The response isn't just to
hold our chin up and say "Be brave, little Piglet," or "Damn the beta testing, full speed
ahead." But the response might be to examine the information that comes back to those who
hold this fear, and try to get it sooner.
Information from Beta
Beta gives us back two basic dimensions of feedback, which I'll call Defect Feedback and
Feature Feedback.
Defect Feedback
We might find actual defects in beta. The system might not run correctly on some user
configurations, or there might just be defects in the software. The technical term for this is
"bad".
Beta testing, in its common form, is done very late in the development cycle. We think we are
done and just want to be sure. This is a very bad time to be finding defects. Whenever a
defect escapes from a coding cycle or from an iteration, an XP team improves its tests and its
practices to prevent that kind of escape from happening again. This is an application of the
XP value of Feedback.
A defect found during beta testing was probably injected, on the average, halfway from the
last beta test until the current one. By XP standards, where we expect testing feedback every
couple of hours, this is seriously open-loop, not the best case of the XP value Feedback.
Therefore, a wise XP team will do pre-beta testing or on-site configuration testing, or take
whatever measures are necessary to reduce the chance for Defect Feedback during beta. We
want beta to be a non-event.
Feature Feedback
Even if the software works as planned, we might also do beta testing to be sure that it is what
the customers want. We might not have built quite the features they asked for, it might be
harder to use than they like, and so on. This is, in essence, feedback to the XP Customer
about how good a job she has done.

As with Defect Feedback, a problem discovered in Feature Feedback was probably injected,
on the average, a long time back. As with programming defects, this feedback is too slow to
be really useful. The wise customer will find ways to be sure, long before beta-time, how
well her decisions match up with the needs and preferences of the buyers and users. The XP
Customer, too, wants beta to be a non-event.