402 Interview

8/7/2019 402 Interview

1/54


2/54

ACKNOWLEDGEMENT

On the successful completion of our project Paying

Guest Accommodation System, we would like to express

our sincere gratitude to all the teachers and friends

who helped us in the completion of this project.

We are sincerely thankful to Ms. Deepali Jain, the

project-in-charge for being a constant source of

help, knowledge and encouragement.

We are also grateful to Mr. Amit and Mr. Sanjay for

all the help they provided during the labs.

Akshay Khandelwal

Malavikka Sharma


3/54

CERTIFICATE

This is to certify that the project entitledPerformance appraisal system by Abhigya Jain and

Mahima Garg has been carried under our supervision.The project has been submitted as per therequirements in the fourth semester of computerscience (H)

Teacher-in-charge(Ms. Deepali Jain)


4/54

INDEX1.Introduction

2.Problem statement

3.Requirement analysis

3.1. Requirement elicitation

3.1.1. Interview

3.1.2. Questionnaire

3.1.3. Facilitated application

specification techniques

3.1.4. Quality function deployment

3.2. Software model used

3.3. Analysis modeling

3.3.1. Entity relationship diagram

3.3.2. Data flow diagram(for existing

system)

3.3.3. Use case diagram

3.3.4. Data definition(for existingsystem)

3.3.5. State transition diagram

3.4. Timeline chart

3.5. Feasibility study

3.6. Risk analysis


5/54

3.7. Software requirement specification

4.Design phase

4.1. Data flow diagram(for proposed

system)

4.2. Structure chart

4.3. Data definition (for proposed system)

5.Test cases

6.Screen shots

Bibliography


6/54

Synopsis

Problems faced by clients:

Today, paying guest accommodations have evolved

into a great business. Large number of students come

and stays over there from different parts of world

and with different economic backgrounds. Everybody

has different requirements accordingly. Some of them

need air conditioned room while others may need

just a non-A.C. Room but with the refrigerator or

Television. Moreover there is a limit that students

cannot stay out after a certain time. So as the

business is growing day by day.

It gets difficult for the families to keep the

record of students. The record of the raw material

used in the kitchen and the attendance. They get a


7/54

problem even in managing the collection of the money

from different students which have different rooms

different food demands.

Present Scenario

These days the families are manually recording

there data and do a lot of labour in keeping an

account of everything. The labour, the raw material

used, the students, the attendance and everything.Some even are unable to use the efficient use of

their resources.

What software will do?

The software we intend to make will be a

sufficient replacement for all the registers

maintained for keeping the records of various

students. Their identity will be maintained in the

software. The student will be allotted a registration

number, through which all his/her information will be

obtained. Fee collection will be very easy after the

software. Automatic bill will be generated by the

software according to the usage of resources by the

accommodant.


8/54

The Process model

Through the interview questions and interview, we

have analysed that our client has a legitimate need

of the software but is clueless about the details. So

we have decided to use the Prototyping model in our

project. None of the customer has ever asked of such

a software so even we, the developers don't have

enough idea that what the customer exactly wants, and

unsure about the algorithm.

So we (software developers) met the client and

decided on the overall objectives for the software,

identified whatever requirements are known, and

outlined areas where further definition is mandatory.

A quick design then occurs. This quick design is

called the Prototype. Our prototype will focus on

the aspects of the software that will be visible and

usable by the user.


9/54

This prototype is then evaluated by the

customer/user and used to refine requirements for the

software to be developed. Iteration occurs as the

prototype is tuned to satisfy the need of the

customer, while at the same time enabling us with

better understanding what needs to be done.

Requirement Analysis

Requirement analysis is a software engineering task

that bridges the system level requirements

engineering and software design. Requirement

engineering activities result in the specification of

software's operational characteristics, indicate

softwares interface with other system elements, and

establish constraints that software must meet.

Figure: Analysis as a bridge between system engineering and

software design.

System

engineering

Software

requirement

analysis

Sofware

design


10/54

For requirement analysis in our project, we also did

the interview with the client which lasted for about

1 and half hour. Through interview we got to know

about the clients requirements very clearly. Some of

the questions that were asked from the client

regarding the software were:-

Interview

Analyst: Who is going to get the benefit from the

software?

Client: The manager of our paying guest

accommodations, located in and around Delhi, is going

to get the benefit through this software. He has a

lot of manual work and has to maintain a lot of data

in the registers. He sometimes even makes mistakes in

the calculations of the fees at the end of the month.

Analyst:Who will use the end-user of the software?

Client: The manager and the residents of the paying

guest accommodation will be the user of the software.

Analyst: By what time do you need the delivery of the

software?

Client: Within 2 months.


11/54

Analyst: By what time you want to see the prototype of

the project?

Client: By the next 15 days.

Analyst:What are the educational qualifications of

the user of the software?

Client: The user of the software will be at least a

graduate.

Analyst: What all features do you need in thesoftware?

Client: I want the software to be made which would be

a full fledged replacement for the manual register

work that is done by the manager.

The software should keep the information of

the paying guests that are staying in and the

rooms and facilities that are being provided

to them.

The software should provide a unique

identification to each paying guest and a

unique bar code through which attendance can

be done easily using bar code reader devices.

The software should keep the account of the

raw materials that are used in the kitchen.

The software should even keep the attendance

record of cooks and maids.

The software should automatically generate

the bills at the end of month.


12/54

The website should be compatible with the

software and it should be capable of booking

the rooms online, according to the needs of

the person.

The software should be easy to use and a good

eye-candy.

Analyst:What is your budget for the software?

Client: The budget is under Rs. 1,00,000.

Analyst: Sorry, the budget of the software is

estimated to about Rs. 1,60,000. Are you comfortable

with this?

Client: That is fine.

Summary of the interview: This interview was beneficial to both the developer and client in

following ways:

The developer got to know the approximate

deadline for handing over the software.

Both client and developer mutually agreed on

the approximate budget of the software.

The developer was briefed by the client about

some special issues concerning the development

of the software.

The developer got to know that the software

should be a web based application.


13/54

The developer was briefed about the end-users

of the software; hence its development shall be

planned in a more directed manner.

Questionnaire

Questionnaire is one of the fastest and easiest ways

to know the requirements of the user. The persons who

are going to use the software know well what all his

major requirements would be in the software. The

persons also who come to stay in the paying guest who

will use the website to book his/her rooms should be

comfortable with the website. So questionnaire is the

only mode through which we can meet their

requirements too. We have attached one sample

questionnaire in the following page.

Q.) Have you ever booked paying guest rooms before

online?

Yes

No


14/54

Q.) Do you get any difficulty in finding the paying

guest suitable for you?

Yes

No

Q.) How do you often find a suitable paying guest for

you?

Dealers

Inspection

Friends

Pamphletes

Q.) What web browser do you generally use?

Internet explorer

Mozilla Firefox

Google chrome

Opera

Q.) Is the manual work a lot, so that the work needs

automation through computer software ?

Yes

No


15/54

Q.) On what the manual work done ?

Computer/Spreadsheet

Registers

Q.) What type of software do you want for the

replacement of manual work?

Software

software + website

website

Q.) Do the guests going to get any benefit from this

sofware?

.....................................................

.....................................................

.....................................................

.....................................................

Q.) You want the payment to be done on website

through:-

credit cards

debit cards

cash cards

through the banks

through net banking


16/54

Summary of the questionnaire: The survey brought

highlighted the following points:

Most of the end-users fall in the semi urban

category of population, therefore, the products

bought such users need to be given a priority.

The software so developed should be most

compatible with the Google Chrome internet

browser, since this is the most used web browser.

The end-users mostly have a broadband connection;

therefore software should be fine tuned for

handling bandwidth of a broadband connection.

People mostly go out for shopping on a monthly

basis. This fact needs to be accounted for when

developing the application.


17/54

Quality Function Deployment

QFD, i.e. Quality Function Deploymentis a customer-

oriented approach to product and service innovation.

It guides managers through the conceptualization,

creation, and realization of new products and

services.

QFD identifies 3 types of requirements:

1) Normal requirements: The objective and goals that

are stated for a product or system during meetings

with customer. If these requirements are present the

customer is satisfied. Examples of normal

requirements are requested types of graphical display

etc.


18/54

2) Expected requirements: These requirements are

implicit to the product or system and maybe so

fundamental that the customer does not explicitly

state them. Their absence will call cause great

dissatisfaction. For e.g.: ease of human/machine

interaction, etc.

3) Exciting requirements: These go beyond the

customer's expectation and prove to be very

satisfying when present.eg: word processing software

is requested with STD features.

The requirements and corresponding functionalities

(technical requirements) collected through interview

process and the questionnaire are classified as

follows:

Normal requirements:

The software should keep the information

of the paying guest that are staying in

and the rooms and facilities that are

being provided to them.

It will keep the attendance records.

It will keep the information about the

employees.

It will keep all the details and

spending of the kitchen/ mess.

Expected requirements:


19/54

user friendly interface

An eye candy interface that will be

very exciting to use.

Customization of employee journals

easy access

Links and tabs

Maintain records

Exciting requirements:

finger print interpreter

Automatic bar code generation for all

the accommodants and employees

Setting, helping and keeping a track of employee

goals by means of pie diagrams that help in employee

evaluation


20/54

DATA DICTIONARY

NAME: name of the accommodant/employee/local guardian

ALIASES: None

WHERE USED/HOW USED: Every employee/accommodant

provides for a page of personal information that

includes all his requirements and expectations from

paying guest accommodation, etc. that serves as the

basic level document maintained for every employee or

accommodant in the paying guest accommodation. The

accommodant also provides information about his local

guardians.


21/54

DESCRIPTION: name = a sequence of at most 20

characters.

Characters = (a-z)/ (A-Z)/blank space.

NAME: Fathers name

ALIASES: None

WHERE USED/HOW USED: Every accommodant provides for a

page of personal information that includes all his

requirements and expectations from paying guest

accommodation, etc. that serves as the basic level

document maintained for every accommodant in the

paying guest accommodation


characters.

Characters = (a-z)/ (A-Z)/blank space

NAME: College name

ALIASES: None




22/54




paying guest accommodation.


characters.

Characters = (a-z)/ (A-Z)/blank space

NAME: age

ALIASES: None







DESCRIPTION: age = maximum of 3 digit number, first

digit should not be 0.

Digit = 0, 1, 2, 3...9


23/54

NAME: gender

ALIASES: None







DESCRIPTION: gender= (M= male)/ (F = female).

NAME: permanent address

ALIASES: None






paying guest accommodation. The accommodant also

provides information regarding his local guardians

address.

DESCRIPTION: address = a sequence of at most 40

letters.

Letters = alphanumeric + special symbols.


24/54

Special symbols = blank space, comma, hyphen.

/, etc.

Alphanumeric = characters + digits

Characters = (a-z)/ (A-Z).

Digits = 0, 1, 2, 3...9.

NAME: mobile number

ALIASES: None






paying guest accommodation. The accommodant also

provides information regarding his local guardians

mobile number.

DESCRIPTION: contact number = a sequence of at most

10 digits.

Digits = 0, 1, 2, 3, 9.


25/54

NAME: Room number

ALIASES: None

WHERE USED/HOW USED: Every accommodant according to

his/her requirements chooses a room after which he is

allotted a room number.

DESCRIPTION: room number=a sequence of digits

(depending upon the number of rooms in the

accommodation).

Digits=0,1,2,3.,9.

NAME: Meal type

ALIASES: None


his/her requirements chooses a meal type (vegetarian

or non vegetarian) after which he is allotted A

(vegetarian) or B(non vegetarian).


26/54

DESCRIPTION: meal type=characters

Characters=A or B.

NAME: Unique identification number

ALIASES: None

WHERE USED/HOW USED: Every accommodant/employee

provides for a page of personal information that

includes all his requirements and expectations from

paying guest accommodation, etc. that serves as the

basic level document maintained for every employee or

accommodant in the paying guest accommodation. After

this the software generates a unique identification

number for each accommodant and employee.

DESCRIPTION: unique identification number =

alphanumeric characters

Alphanumeric characters=letters + numbers

NAME: Occupation

ALIASES: None


27/54

WHERE USED/HOW USED: Every accommodant provides

information regarding both his fathers and local

guardians occupation.

DESCRIPTION: occupation = a sequence of at most 20

characters.


NAME: Room type

Ac/cooler/fan

Attached bathroom

Floor number

Number of accommodants in each room

Building number of the room

ALIASES: None


his requirements and preferences chooses a room (an

ac/cooler/fan or an attached/unattached bathroom).He

also chooses whether he wants a single, double or

triple seater. After this the software generates a

floor number and a building number according to the


28/54

location of the room in the paying guest

accommodation.

DESCRIPTION: floor number and building number=digits

Digits=1,2,3,9.

NAME: Monthly salary

ALIASES: None

WHERE USED/HOW USED: every employee in working in the

paying guest accommodation provides his basic

information which also includes his qualifications.

Based on his qualifications and talent he is given a

job with a deserving pay package.

DESCRIPTION: Monthly salary=digits.

Digits=0,1,2.,9.

NAME: Job


29/54

ALIASES: None

WHERE USED/HOW USED: Every employee in working in the




job.

DESCRIPTION: job=a sequence of almost 20

characters(designation).


NAME: Department

ALIASES: None

WHERE USED/HOW USED: Every employee in working in the




job in a particular department.

DESCRIPTION: department=a sequence of almost 20

characters.



30/54

SOFTWARE REQUIREMENT SPECIFICATION

A Software Requirements Specification (SRS) is a

complete description of the behavior of the system to

be developed. It includes a set of use cases that

describe all the interactions the users will have

with the software. Use cases are also known as

functional requirements. In addition to use cases,

the SRS also contains non-functional (or

supplementary) requirements. Non-functional

requirements are requirements which impose

constraints on the design or implementation (such as

performance engineering requirements, quality

standards, or design constraints).
http://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)


31/54

SRS for the Paying Guest Accommodation

Software:

Introduction

Purpose The purpose of this document is to describe

the external requirements for a paying guest

accommodation system. What are the different

requirements for achieving the ultimate goals, what

are the views of different users about the system. It

also describes the interfaces for the system.

Scope This document is the only one that describes

the requirements of the system. It is meant for

use by the developers and will be the basis for

validating the final delivered system. Any changes

made to the requirements in the future will have

to go through a formal change approval process.

The developer is responsible for asking for

clarifications, where necessary and will not make

any alterations without the permission of the

client.

Abbreviations PGA : Paying guest accommodation

UID : Unique identification number

References The documents that will be referencedlater in the SRS document are:


32/54

Questionnaire

Interview documentations

Data flow diagrams (DFD)

Overview The following SRS document contains an in-

depth documentation of the product perspective that

is how the system (if not stand alone) relates the

requirements of the larger system to functionality of

the software and identifies various interfaces

between that system and the software. It contains

various software system attributes like reliability,

availability portability etc. The SRS is divided

into basic 6 sections with the first dealing with

acquainting the client with the new system; section 2

contains an overall description / general factors

affecting the product and its requirements. And

Section 3 specifies specific requirements of the

software.

The overall description

Product perspective Product i.e. paying guest

accommodation software should be able to provide a

basic and easy interchange of information i.e. it

should be able to remove the communication gaps

between an employee and other employees and even

between employees and the students. It should be

compatible with all the operating systems.


33/54

Interfaces - The external users are the accommodants

staying in the paying guest accommodation. The

accommodants and employees can have an access to

their accounts for their records and history of

bills, their dues, and other information, etc.

System interfaces

Hardware interfaces - The external hardware

interface used for accessing the performance

appraisal software is the personal computers of

the various employees of the company. The PCs may

be laptops with wireless LAN as the internet

connections provided will be wireless.

Software interfaces - The Operating Systems can

be any version of Windows, Linux, UNIX or Mac

which supports TCP/IP protocols. Also visualbasic for coding and developing the software will

be used.

Communications interface - The communication

interface is a local area network through wireless

network routers preferably. As one of the important

functionality of our software is the feature of an

automated reminder system (through e-mails etc), a

network connection is a must for communication.

Memory constraints the PGA software is light weight

software and thus shouldnt pose any problems as far

as primary or secondary memory space is concerned. At


34/54

least 64 MB RAM and 512 MB space on Hard disk will be

required for running the application.

Operations This software release will cover the

required automated management aspects of the

database. Database will be managed both manually by

the employees filling up their journals plus

automated on the basis of various database management

techniques for maintaining old or non-required data.

Database backup and recovery will also be handled

both by the Database administrator and the various

incorporated database management features.

Site adaptation requirements The terminals at

client side will have to support the hardware and

software interfaces specified above.

Product functions - The following are the product

functions of the software to be developed:

The login box should also be on the official

website of the organization.

Thepassword fieldshould be secured.

After signing in and respective verification for

each employee that accesses the software, all

updates and new announcements for users should be

displayed in their respective a/c accordingly.

By clicking on the easy-interface-tabs the user

should be able to view current bill of today,


35/54

dues, date of due for rent, notes, attendance,

fine to be paid and results.

User should be able to change the passwords and

the changes would be stored in the security

settings for the purpose of software maintenance

and checkings.

User characteristics - Each employee is given a

unique identification worked out on the basis of his

registration number and other basic information

specific to an employee. So if he joins the

organization, only then he can login. This prevents

misuse, unauthorized access and hacking of the

product.

Constraints

Due to limited features of DBMS being used

performance tuning features will not be applied

to the queries and thus the system may slow down

with the increase in number of records being

stored.

Due to limited features of DBMS being used,

database auditing will also not be provided.

Company should follow some security policy so

that no unauthorized access is permitted(in

addition to the login security provided by

software)


36/54

Assumptions and dependencies The UID number of the

employees and the accommodants, the departments to

which they belong, posts and designations should not

change.

Apportioning of requirements not required.

Specific requirements - This section contains the

software requirements to a level of detail sufficient

to enable designers to design the system, and testers

to test that system.

External interfaces

User interfaces: The external users are the students

searching for the PG online and the students

already staying in the paying guest

accommodation. The accommodants can have an

access to their accounts for their pupations

to their journals, assessments and

evaluations etc.

Hardware interfaces: The external hardware interface

used for accessing the paying guest

accommodation software is the personal

computers of the various accommodants. ThePCs may be laptops with wireless LAN as the


37/54

internet connections provided will be

wireless.

Software interfaces: The Operating Systems can be any

version of Windows, Linux, UNIX or Mac which

supports TCP/IP protocols. Also visual basic

for coding and developing the software will

be used

Functions

Product Information Maintenance

Description - The system will be maintaining

information about the accommodant and role of each

and every employee of the organization. The

information maintained would be like: accommodant

name, occupation/designation, unique employee

identification number, building, years into PG, track

record etc.

The system will allow creation\modification\deletion

of accommodant information and special purpose graphs

that will help both the accommodant and the employees

in managing the accommodations.

Validity checks

i. Each and every employee and accommodant of the

organization has access to the paying guest

accommodation through specific login IDs


38/54

ii. Login ID will be unique for each accommodant

and employee.

iii. Login ID will not be blank.

iv. Name will be unique for each employee.

v. Employee name will not be blank.

vi. Building name, room no. (to which an

accommodant belongs) should not be blank

Error Handling\Response to Abnormal Situations

If any of the above validations\sequencing flow doesnot hold true, appropriate error messages will be

prompted to the user for doing the needful.

Bill Information Maintenance

Description - The system will be maintaining

information about the bills that each accommodant is

spending in mess/ canteen. The accommodant is also

tracked for its attendance and is fined accordingly.

The system will allow creation\modification\deletion

of due bills only by the employees for student does

not bear more than a certain credit at a time.

Validity checks

i. Each and every employee and accommodant of the

organization has access to the paying guest

accommodation through specific login IDs


39/54

ii. Login ID will be unique for each accommodant

and employee.

iii. Login ID will not be blank.

iv. Name will be unique for each employee.

v. Employee name will not be blank.

vi. Building name, room no. (to which an

accommodant belongs) should not be blank

Error Handling\Response to Abnormal Situations

If any of the above validations\sequencing flow doesnot hold true, appropriate error messages will be

prompted to the user for doing the needful.

Receipt Generation

Once the employees are done with

creation/modification/deletion of the students

information, the receipt copy is generated.

Performance requirements - The PCs used must be at

least Pentium 4 machines so that they can give

optimum performance of the product.

Logical database requirements

The following information will be placed in a

database:

1) Accommodant information: Name, contact details,

UID Number building no. and room no.

2) Building information: Building no., employees,

no. of rooms, manager.


40/54

3) Account Information: User Name, User id,

Password, room no.

Design constraints There are no design constraints.

It is a simple project. Any change in the PG can be

easily reflected back in the software. Like adding a

new room, change of mess charges, change of rental,

any such information can be easily modified

accordingly but only by the administration head of

the PG.

Software system attributes - The following are the

attributes of the product

It should be equipped with current and archive

database.

All records can easily be updated.

It should facilitate employees, accommodant with

updating his/accommodants account, downloading or

uploading pages/documents etc from anywhere.

Reliability

availability

security

maintainability and portability


41/54

FEASIBILITY STUDY


42/54

A feasibility study was an evaluation of a proposal

designed to determine the difficulty in carrying

out a designated task. Generally, a feasibility

study precedes technical development and project

implementation. In other words, a feasibility

study is an evaluation or analysis of the

potential impact of a proposed project.

Technology and system feasibility

The assessment is based on an outline design of

system requirements in terms of Input, Processes,

Output, Fields, Programs, and Procedures. This can be

quantified in terms of volumes of data, trends,

frequency of updating, etc. in order to estimate

whether the new system will perform adequately or

not. Technological feasibility is carried out to

determine whether the company has the capability, in

terms of software, hardware, personnel and expertise,

to handle the completion of the project.

Economic feasibility

Economic analysis is the most frequently used method

for evaluating the effectiveness of a new system.

More commonly known as cost/benefit analysis, the

procedure is to determine the benefits and savings

that are expected from a candidate system and compare

them with costs. If benefits outweigh costs, then the

decision is made to design and implement the system.


43/54

An entrepreneur must accurately weigh the cost versus

benefits before taking an action.

Cost Based Study: It is important to identify cost

and benefit factors, which can be categorized as

follows: 1. Development costs; and 2. Operating

costs. This is an analysis of the costs to be

incurred in the system and the benefits derivable out

of the system.

Time Based Study: This is an analysis of the time

required to achieve a return on investments. The

benefits derived from the system. The future value of

a project is also a factor.

Legal feasibility

It determines whether the proposed system conflicts

with legal requirements, e.g. a data processing

system must comply with the local Data Protection

Acts.

Operational feasibility

Is a measure of how well a proposed system solves the

problems, and takes advantages of the opportunities

identified during scope definition and how it

satisfies the requirements identified in the

requirements analysis phase of system development


44/54

Schedule feasibility

A project will fail if it takes too long to be

completed before it is useful. Typically this means

estimating how long the system will take to develop,

and if it can be completed in a given time period

using some methods like payback period. Schedule

feasibility is a measure of how reasonable the

project timetable is. Given our technical expertise,

are the project deadlines reasonable? Some projects

are initiated with specific deadlines. You need to

determine whether the deadlines are mandatory or

desirable.

The feasibility study of software

development at hand is:

Economic feasibility - The client companys rigidity

in adjusting with a few increments in budgets can

prove to be a major hurdle in the development of

efficient, portable and robust software.

Schedule feasibility - As per the current

requirements provided by the company 6 months seem to

be reasonable enough for the completion of the

project.


45/54

Technology feasibility - Due to the size limit, the

inclusion of a good GUI and other attractive add ons

would b difficult

Operational feasibility - As the data has been kept

in archives manually for past many years and needs to

be stored in the software database thus this makes

work easier but will take time for entering the data.

Legal feasibility - All the legal acts and protocol

are followed


46/54

RISK ANALYSIS

1. RISK TABLE

Risks Category Probability ImpactSoftware doesnt meet

performance requirementsPE 30% 1

Hardware doesnt support

the required interfacePE 30% 2

The user doesnt find it

up to his requirements.PE 20% 2

CUT OFF LINE

Customer changes

requirements SC 10% 4

Team member performance SC 30% 4

Scope estimate incorrect SC 100% 3

Impact values: Category values:

1 Catastrophic PE Performance Risk

2 Critical CO Cost Risk

3 Marginal SU Support Risk

4 Negligible SC Schedule Risk

Risk Descriptions

Software doesnt meet performance requirements

Software developed doesnt meet performance

requirements. This is a pretty generic risk, so we

will refine it at our discretion. Something like an

extremely jumpy screen will probably constitute a

trigger for the contingency plan.


47/54

Sub-condition 1: Real-time computing present issues

on allocating processing time.

Hardware doesnt support the required interface

Hardware doesnt support the required interface.

Sub-condition 1: With the reuse of the login

component, many new interfaces will have to be

implemented. Issues that relate to non conformance

of the design specification are cause for concern.

Sub-condition 2: The design standards for component

interfaces have not been solidified and may not

conform to certain existing reusable components.

Customer changes requirements

Client may request small changes outside the agreed

upon requirements. These may have a major impact on

our design and implementation.

Team member performance

We are relying on our team members to perform at

certain levels to complete this project. Team

members have an infinite number of possible

situations that may hinder their performance.

Probability and Impact

Software doesnt meet requirements


48/54

The software not meeting the performance requirements

has a probability of 30%. This is a performance risk

and has an impact rated as 1 (Catastrophic).

Hardware doesnt support required interface

If one of the engines interfaces doesnt meet the

requirements, we have a manageable problem. However,

this is rated as critical to the project and has a

30% chance of occurring. This is also a performance

risk.

Customer changes requirements

In every project there is the risk of the customer

trying to change the requirements. This is both a

scheduling and cost risk. We gave this a 10% chance

of occurring and rated it as a negligible risk. This

is due to the fact that we have a strong argument for

not having to submit to the customers request if it

is not specified in the requirements document.


Team member performance is also a risk that every

project faces. We gave it a 10% chance that the

occurrence may arise and action must be taken. This

is however a negligible risk and can be corrected

easily.

Risk refinement

High probability/high impact risks are refined


49/54

Risk mitigation, monitoring, and

management

Risk mitigation/monitoring

Software doesnt meet performance requirements

Ensuring milestones are met and taking action if they

are not will be essential to the success of this

project. Establish and enforce formal technical

review guidelines after the completion of a major

component of the project. If the component cannot be

completed due to inability to meet requirements via

coding, a group meeting needs to occur where we

either reevaluate the design of the project orreassign team member responsibilities.


Strong emphasis will be placed on strictly adhering

to the design specification. Being that the engine

component is already designed and we have littleknowledge of the internal workings, well defined

interfaces are a must. We dont have the choice of

redesigning the entire API when a problem arises.

Individual unit tests with stubs/drivers will reveal

more information about the interfaces and their

correctness.


50/54

Client requirements change

We are going to attempt to avoid a requirements

change all together, but under these circumstances

(students working for a Professor) it may arise. We

can attempt this by writing a strict requirement

specification and ensuring that both client and our

team have the same perspective on the project

outcome.


Mitigation of team member performance slippage will

be handled with caffeine. Ensuring that we have an

assortment of caffeine sources will be essential to

this projects success. Dark brewed roast from

dunking' doughnuts is preferred. In certain regards,

there is nothing that can be done to mitigate this

risk. If a group member is sick, for instance, there

is nothing we can do to combat that happening. We

can monitor other situations however, such as a group

member dropping out because of workload. We can

monitor group members through group meetings, and try

to ensure that everyone knows what they are doing,

and is comfortable doing it.

Risk management

Software doesnt meet performance standards


51/54

Obviously, this is a heavy responsibility on the

team. If requirements are not met, it could greatly

affect the quality of the project. If the

requirements are not being met correctly, or at all,

then the contingency plan is to either discuss with

our customer what changes need to be made, or choose

a new project if there is no way we can complete the

project. The trigger to this risk being active is

that we have fallen far behind schedule in one aspect

and the completion of the project is in jeopardy.


In the event an interface is designed incorrectly, we

can only attempt to resolve the issue with a

conversion algorithm that corrects the issue. In the

case that the interface is tightly coupled with otherinterfaces, we will have no choice but to take the

project back to the design phase. Analysis must then

be done on the impact of the proposed changes. The

trigger here is obvious, that being an incorrectly

defined interface found.

Client requirements change

If the occurrence of a change in requirement does

arise after the formal sign off, we will simply

consider the impact of the request. If the impact of

the change is minimal and the schedule allows for it,

we will attempt to incorporate the requested change.


52/54

The trigger here is quite obvious, that being the

change request.


As mentioned above, there is not much we can do in

this regard other than making sure that all group

members are kept relatively happy. If this risk does

occur, then our contingency plan is to assign other

group members additional tasks. Someone might have

to become an additional programmer or tester, for

instance. Luckily, this will probably not occur and

would not have a catastrophic impact regardless. The

trigger to this risk occurring would be notification

by the group member that they will no longer be

working on the project.

STATE TRANSITION DIAGRAM


53/54

Room available

Modify room list

new accom.

Check room list

New Student

Room List

Unique

identification

no.

Generate unique id

Student selected.

Add to the

bill cart

Canteen/mess demands

Things provided


54/54

402 Interview

Documents