HYDERABAD INSTITUTE OF TECHNOLOGY AND MANAGEMENT

Computer Science and Engineering Department

SOFTWARE ENGINEERING
LAB MANUAL

YEAR : 2018-2019
COURSE CODE : CS506PC
REGULATIONS : R16
CLASS : B.TECH
BRANCH : CSE
SECTION : III-I SEM

TEAM OF INSTRUCTORS : (OPTIONAL)

1
 HYDERABAD INSTITUTE OF TECHNOLOGY AND MANAGEMENT

Computer Science and Engineering Department

Program Outcomes

PO1 Engineering knowledge: Apply the knowledge of mathematics, science,

engineering fundamentals, and an engineering specialization to the solution of
complex engineering problems.

PO2: Problem analysis: Identify, formulate, review research literature, and analyse
complex engineering problems reaching substantiated conclusions using first
principles of mathematics, natural sciences, and engineering sciences.

PO3: Design/development of solutions: Design solutions for complex engineering

problems and design system components or processes that meet the specified
needs with appropriate consideration for the public health and safety, and the
cultural, societal, and environmental considerations.

PO4: Conduct investigations of complex problems: Use research-based knowledge

and research methods including design of experiments, analysis and
nterpretation of data, and synthesis of the information to provide valid
conclusions.

PO5: Modern tool usage: Create, select, and apply appropriate techniques, resources,
and modern engineering and IT tools including prediction and modelling to
complex engineering activities with an understanding of the limitations.

PO6: The engineer and society: Apply reasoning informed by the contextual
knowledge to assess societal, health, safety, legal and cultural issues and the
consequent responsibilities relevant to the professional engineering practice.
PO7: Environment and sustainability: Understand the impact of the professional
engineering solutions in societal and environmental contexts, and demonstrate
the knowledge of, and need for sustainable development.

PO8: Ethics: Apply ethical principles and commit to professional ethics and
responsibilities and norms of the engineering practice.

PO9: Individual and team work: Function effectively as an individual, and as a

member or leader in diverse teams, and in multidisciplinary settings.

PO10: Communication: Communicate effectively on complex engineering activities

with the engineering community and with society at large, such as, being able
to comprehend and write effective reports and design documentation, make
effective presentations, and give and receive clear instructions.

PO11: Project management and finance: Demonstrate knowledge and understanding

of the engineering and management principles and apply these to one‟s own
work, as a member and leader in a team, to manage projects and in
multidisciplinary environments.

PO12: Life-long learning: Recognize the need for, and have the preparation and ability
to engage in independent and life-long learning in the broadest context of
technological change.
 HYDERABAD INSTITUTE OF TECHNOLOGY AND MANAGEMENT

Computer Science and Engineering Department

Program Specific Objectives

PSO1: Foundation of mathematical concepts: To use mathematical

methodologies to crack problem using suitable mathematical
analysis, data structure and suitable algorithm.

PSO2: Foundation of Computer System: the ability to interpret the

fundamental concepts and methodology of computer systems.
Students can understand the functionality of hardware and software
aspects of computer systems.

PS03: Foundations of Software development: the ability to grasp the

software development lifecycle and methodologies of software
systems. Possess competent skills and knowledge of software design
process. Familiarity and practical proficiency with a broad area of
programming concepts and provide new ideas and innovations
towards research technological change.

The following points should be followed to develop software project

startup using software engineering methodology
Problem Analysis and Project Planning -Thorough study of the problem
– Identify Project scope, Objectives and Infrastructure.
Software Requirement Analysis – Describe the individual
Phases/modules of the project and Identify deliverables. Identify
functional and non-functional requirements.
Data Modeling – Use work products – data dictionary.
Software Designing - Develop use case diagrams and activity diagrams,
build and test class diagrams, sequence diagrams and add interface to
class diagrams. Prototype model – Develop the prototype of the
product.
COURSE MANAGEMENT SYSTEM
SRS document for CMS
Introduction 2
Purpose 2
Scope 2
Definitions and abbreviations2
References 2
Overview 2
Overall Description 3
Product Perspective 3
Product Functions 3
User Characteristics 5
Constraints 5
Assumptions and Dependencies 5
Specific Requirements 5
External Interface Requirement 5
User Interfaces 6
Hardware Interfaces 6
Software Interfaces 6
Communication Interfaces 6
Functional Requirements 6
Creating Courses 6
Grade Management 7
Homework Submissions 7
Group Management 9
Online Quizzes 11
Create Accounts 12
Performance Requirements 12
Response Time 13
Throughput 13
Capacity 13
Utilization of Resources 13
Software System Attributes 13
Security 13
Reliability 13
Scalability 13
Introducti on
Purpose
The purpose of this document is to present a detailed description of
the course management system. It will explain the purpose and features
of the system, the interfaces of the system will do, the constraints
under which it must operate and how the system will react to external
stimuli. This document is intended for both stakeholders and developers
of the system.

Scope
It domain use to use it large domain it use for efficient useful it service
it university and faculty and schools in university in each course to access
to link e-learning to show course and useful it service

Definitions and abbreviations

SHS : Student Homework Submission. SIS : Student Information System.
SGT : Group Grading Template.
AIS : Academic Information System. CMS : Course Management System.

References
INTERNET, TAS,IBM REQUESTPRO,INSTRUCTOR.
Overview
The next chapter, the Overall Description section, of this document
gives an overview of the functionality of the product. It describes the
informal requirements and is used to establish a context for the technical
requirements specification in the next chapter.

The third chapter, Requirements Specification section, of this document is

written primarily for the developers and describes in technical terms
the details of the functionality of the product.

Both sections of the document describe the same software product in its
entirety, but are intended for different audiences and thus use
different language.
 Overall Description
Product Perspective
The system will be operate within university environment. This
environment has anther systems that will interact with this system so
we need interfaces between this systems .

Student information
system

Registration system Course management Database system

system

Academic
information system
 Product Functions
The system shall be able to Create Courses.

Download course

student
The system shall be able to automatically create accounts for students and

Update course

instructors.

The system shall be capable of Managing Student Grades.

Access grades

Student Instructor
Modify grades

Evaluating Student’s and group’s

Homework Submissions Online.

 The system shall be capable of automatically accepting Homework
Submissions.

Upload solution of homework submission

student

The system shall support Group Management features especially

important for courses with group projects, this is especially important for
large classes.

Create group

Student
Access group

Drop out from

group

Switch group

The system should provide Online Quizzes.

Answer online quizzes

student
 Upload the

quizzes
instructor

Upload answer

key

user Characteristics

The student expected to be Internet literate Once he/she can log in the
system and navigate between WebPages he/she can use basic
functionality of the system.

Instructor expected to be internet literate and t be able use more

complex functionality of the system.

Constraints
The system must run in windows operating system environment.

The system shall use oracle8i database for all data management tasks.

The system shall work based on XYZ-standard to keep copyright.

Assumptions and Dependencies

Specifi c Requirements
External Interface Requirement
User Interfaces

It must interfaces icons or wizard

Hardware Interfaces
Its must be pc computer to link to course management system

Software Interfaces
We must internet explorer to able to browser and show and interest
course management system
Communication Interfaces
We must user interface rather commadline
Functional Requirements
Creating Courses
Integration with registration system: The system shall
periodically upload the latest registrar’s classes list to determine courses
that offered in the current semester.

The system shall generate course for each class that registered
and determine the current set of students that enrolled in that class.

The system shall allow course instructor to update course content.

Grade Management
Allow grades to be entered online: The system shall allow instructors to
enter and modify grades online.

Allow students to access their grades online: The system shall allow
student to log in their account and check their grades at any time.

The system shall provides statistical information such as averages,

standard deviation, median about students grades.

Track and Handle Re-grade Requests: The system shall be able to track
and handle requests for re- grades, and all information about re-grades
shall be available to the student, and the course instructor.

Homework Submissions
Accept submissions in multiple formats: The system shall accept
submissions in multiple formats, including .zip, .cpp , .txt, .doc, etc.

Support for late submissions: The system shall provide information about
late submissions, and also disallow submissions after a certain period of
time.

Use Case Name Upload Solution Of Homework Submission

Brief Description In this case the student can upload homework

submission in his/her account.

Actor Student.

Precondition Basic flow Logged in the system.

Logged in his/her account using username and
password.
 Check user information.
Choose SHS link.
Choose Attachment link.
Choose the file that have the solution of submission.
The system shall check the deadline to receive the
solution of submission.

Alternative flow In step 1, if the user information not accepted, then:

1. The system show message that show that you should
have to enter valid username and password.
In step 5, if student late on the deadline to receive the
solutions, then:
The system shall prevent the student to upload the file.
The system shall give mark zero to this student.
Send the grade to student account and SIS.

Post condition The file that has the solution shall send to instructor
account.

USERNAME VERIFY
AND VERIFYING ED FIL CHECK
INFORMA
TION
ATTACH E DEADLINE
PASSWORD INFORMA FILE
TION

FIL
E
THE
DATABASE

FIL
SEND E PRESS
TO OK

INSTRUCTOR
ACCOUNT
 Integration with grade management: The homework submission system
shall be integrated with the grade management by using online grading
templates that can be filled out, and automatically annotating code
with line numbers.

assignment grades can be automatically posted to student account.

grader comments can be sent along with the grades.

Use Case Evaluating Student’s Homework Submissions Online.

Name

Brief In this case instructor can evaluate student’s homework submissions

Description online and enter
specific grade for each student based on the evaluation.

Actor Course instructor

Precondition Logged in the system.

Logged in his/her account by using username and password

Basic flow Verify user information.

Choose SHS link.
the system order the submissions based on serial number for each
student.
Instructor choose specific submission and evaluate it.
 Choose SGT link.
Fill grading template.

Alternative flow In step 1, if the user information not accepted, then:

1. The system show message that show that you should have to
enter valid username and password.
In step 6, if the user enter grade out of the range of Homework
Submissions, then:
The system shall not accept the grade.
Show message that show that the user should have to enter grade
within the range, (from 1-10).

Post condition The system shall send grades and any comment with it to student
account .
The system shall send grade to SIS.

Group Management
Ability to create groups: The system shall allow students to
automatically create groups, and enforce certain conditions such as each
student should be a member of exactly one group for a given project.

Use Case Name Create Group

Brief In this case students can create and participate in one group in order to
work together in large Homework Submissions like project and store in
Description
there group.

Actor Student.
 Precondition Logged in the system.
Logged in his/her account by using username and password

Basic flow Verify user information.

Choose Group link.
Choose create group link.
Choose one from the listed groups.
The system shall check if user participate in another group.
Check the number of members for the chosen group.
The system shall show to user group password and username.
The system shall store student serial number and his/her name in
group information.

Alternative flow In step 1, if the user information not accepted, then:

1. The system show message that show that you should have to
enter valid username and password.
In step 5, if the user participate in another group, then:
The system shall prevent user to participate in this group.
Show message that show that the user is member of another
group, so he/she cannot participate in this group.
In step 6, if the number of members for this group is in the
maximum number, then:
The system shall prevent user to participate in this group.
Show message that show that the user must looking for another
group.

Post condition The user is member of this group and can access it in any time.

Integration with homework submissions: The system shall be able to

accept group homework submissions.
Integration with grade management: The system shall support grade
management for groups, and track how the group grade translates into
individual student grades.

Use Case Name Evaluating Group’s Homework Submissions Online.

Brief Description In this case instructor can evaluate group’s homework submissions
online and enter specific grade for each group based on the
evaluation.

Actor Course instructor

Precondition Logged in the system.

Logged in his/her account by using username and password

Basic flow Verify user information.

Choose GHS link.
the system list the available groups.
Instructor choose group submission and evaluate it.
Choose GGT link.
Fill grading template.

Alternative flow In step 1, if the user information not accepted, then:

1. The system show message that show that you should have
to enter valid username and password.
In step 6, if the user enter grade out of the range of
Homework Submissions, then:
The system shall not accept the grade.
Show message that show that the user should have to enter
grade within the range, (from 1-20).

Post condition The system shall send grades and any comment with it to
group.
The system translate group grade into individual students
grades.
The system shall send grade to SIS.
Group Maintenance: Invariably, students either switch groups, or drop out
from a group altogether. The system shall support such transitions and
keep track of them.

Online Quizzes
The system shall instructor to upload quizzes.

The system shall allow instructor to upload answer key to the system.

The system shall allow student to answer quizzes.

The system shall compare answer key with student answer.

Integration with grade management: the system manage the quizzes’

grades by sending it to grade management in order to allow instructor to
modify the grades and student to see their grades.

Use Case Name Answer online Quizzes

Brief Description In this case student can answer Quizzes online
and get his/her grade immediately
after he/she finish answer the quizzes.

Actor student

Precondition Logged in the system.

Logged in his/her account using username and
password.

Basic flow Check the user information.

Choose Quizzes link.
Begin answer the quizzes.
The system shall compare student answer with
answer key.
If the student answer and answer key identical the
system give specific mark for this question .
The system shall collect the student marks.
Choose finish button.

Alternative flow In step 1, if the user information not accepted, then:

1. The system show message that show that you
should have to enter valid username and password.
In step 5, if the student answer and answer key not
identical, then:
The system shall give zero for this question.
If the student dose not answer question the system
shall give zero for this question.
Post condition
The student shall see his/her grade after he/she
choose finish link.
The system shall store the grade in student account
and instructor account.
The system shall send the grades to SIS.
Create Accounts
The system shall automatically create
accounts for each class.
Create one account for course instructor regardless to the number of
classes that he/she teach.
The account username is course name and its number.
The account password is the same password that in AIS.
Any change in the password in AIS the system shall reflect it on the
instructor account password in CMS.
Create one account for each student that registered in this class.
The account username is course name and its number.
The account password is the same password that in SIS.
Any change in the password in SIS the system shall reflect it on the student
account password in CMS.
Instructor account contain the classes that he/she teach, each class
contain list of student that ordered based on student serial number.
Instructor can modify student grades from his/her account.

Performance Requirements

Response Time
Average response time shall be less than 2 second.

Throughput
The system shall accommodate 1000 booked per minute.

Recovery Time
In case of a system failure, redundant system shall resume operations
within 30 seconds.
Average repair time shall be less than 1 hour.
Start-up/Shutdown Time
The system shall be operational within 1 minute of starting-up.

Capacity
The system accommodate 4000 concurrent users.
Utilization of Resources
The system shall store in the database no more than one million
transactions.
If the database grows over this limit, old transaction shall be backed up
and deleted from the operational database.

Software System Attributes

Security
Firewall Protection: The course management software system shall run inside
a firewall.

Support different roles: The system shall support different roles for users,
such as Instructors, Students, and administrative staff, the user logged in
with given role should only be allowed access consistent with that role.
For example a student shall only be allowed to see he/she grades not
to modify it.

Reliability
The system shall not be down more 2 times in year.

Scalability
Scaling the system to large number of users: large courses will have
hundreds of students.
The system shall be able to handle the load for such courses, especially near assignment deadlines
when many students can be expected to access the course management system.
PROTOTYPE MODEL FOR COURSE MANAGEMENT SYSTEM:
Experiment -1
VIVA QUESTIONS

1. List out the software Application Domains?

2. Differentiate between Functional and non-functional requirements?
3. List out the layer's of software engineering?
4. Differentiate process and product?
5. List out the levels of CMM?
6 List out the process models?
7. Explain Agile process?
8. Explain Domain Analysis?
9.List out requirements Modeling approaches?
10.Explain Behavioral Model?

Experiment no 2.EASY LEAVE

SRS DOCUMENT FOR EASY LEAVE
INTRODUCTION 2
DOCUMENT PURPOSE 2
 PRODUCT SCOPE. 2
INTENDED AUDIENCE AND DOCUMENT OVERVIEW 2
DEFINITIONS, ACRONYMS AND ABBREVIATIONS 2
DOCUMENT CONVENTIONS 2
REFERENCES AND ACKNOWLEDGMENTS 3

2. OVERALL DESCRIPTION 3
PRODUCT PERSPECTIVE 3
PRODUCT FUNCTIONALITY 3
USERS AND CHARACTERISTICS 3
OPERATING ENVIRONMENT 4
DESIGN AND IMPLEMENTATION CONSTRAINTS 4
USER DOCUMENTATION… 4
ASSUMPTIONS AND DEPENDENCIES 4
3. SPECIFIC REQUIREMENTS 5
EXTERNAL INTERFACE REQUIREMENTS 5
FUNCTIONAL REQUIREMENTS 6
BEHAVIOUR REQUIREMENTS 6
4.OTHER NON-FUNCTIONAL REQUIREMENTS 7
PERFORMANCE REQUIREMENTS 7
SAFETY AND SECURITY REQUIREMENTS 7
SOFTWARE QUALITY ATTRIBUTES 7
5. OTHER REQUIREMENTS 8
INTRODUCTION
The following subsections of the Software Requirements Specifications (SRS) document provide
an overview of the entire SRS.

DOCUMENT PURPOSE
The purpose of this document is to show the software requirements of the Leave Management
software.The functionality and scope of this software are described in this SRS document.

PRODUCT SCOPE
The Leave Management software aims at helping the user to address issues from multi-
disciplinary angles related to Leave management and services.
The major benefits of this software are -
1.It is a unique software which helps to organize event without any paperwork. 2.It has a wide
variety of Modules.
By just few clicks user can check the leave status, leave balance, notices and apply for and grant
leave accordingly.

INTENDED AUDIENCE AND DOCUMENT OVERVIEW

This SRS document is intended for developers , professors, students for reading. The rest of the
document contains the functional and non functional requirements of Leave Management
System.

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

LMS - Leave Management System. LB – Leave balance.
SRS- Software Requirement Specification.
Servers: Machines that store all the information and records.

DOCUMENT CONVENTIONS
The entire document is in Times New Roman font. The headings are numbered 1,2,3... and so
on and sub-headings are numbered x.1,x.2.... and so on. Both headings and sub-headings are in
bold.
Main title : Font Times New Roman and size 14 Sub titles : Font Times New Roman and size 14
Content : Font Times New Roman and size 12

REFERENCES AND ACKNOWLEDGMENTS

Software Engineering book written by Roger Pressman ,Ian Sommerville.
OVERALL DESCRIPTION
Describes the general factors that affect the product and its requirements.
This section does not state specific requirements. Instead it provides a
background for those requirements, which are defined in section 3, and
makes them easier to understand.

PRODUCT PERSPECTIVE
It is aimed at replacing the tedious paper works that the companies or
colleges currently use. The system will collect data and store it for fast and
easy reference. The system will provide users with complete record of the
attendance and and leaves. It will also provide information about the leave
balance(availability).The system is thus helpful to reduce the time and
complexity of maintaining the records.

PRODUCT FUNCTIONALITY
Some major product functionalities of the system are as follows:
Information about the employee/student/staff attendance.
Check for leave availability.
Maintain employee leave record.
Display notices.
Apply for leave.
Approve or reject leave application.
USERS AND CHARACTERISTICS
Primary users of the system will be employees working in company
/students /staff, manager , HOD, Admin. Very little technical expertise is
required for reading the outputted data since it is in graphical/tabular
form.
Educational level of LMS computer software – Low Experience of LMS
software – None
Technical Expertise – Little

OPERATING ENVIRONMENT
Open source ,HTML,windows, Ubuntu.

DESIGN AND IMPLEMENTATION CONSTRAINTS

High performance, User-friendly,Security based System, validation of
Users, very fast response time.

USER DOCUMENTATION
A link is provided for help and very easy User Interface.

ASSUMPTIONS AND DEPENDENCIES

Assume that all the information entered by the user will be correct. If any
wrong information found then system will notify an alert. The system is
required to save generated reports.
SPECIFIC REQUIREMENTS
External Interface Requirements
User Interfaces
The User Interface Screens are described in table 1.
Table 1: Leave Management User Interface Screens

Screen Name Description

 Login Log into the system.

Employee Display attendance of employee, no.of leaves, leave

balance.Add or update employee records.

Apply for leave Display leaveavailability, application for leave, cancel

application. Add or update leave allotment records

Leave records Display leave history.

Approve/reject leave Display leave availability and application form. Add or update
application records.

Staff Add or update staff records Create, modify, and delete staff
member.

Reports Select, view, save, and delete reports

Hardware Interfaces
The system shall run on :
Operating system: Any Windows OS.
Scripts which supports CGI, HTML & Javascript. Web Browser : Google
Chrome , Mozilla firefox.

Software Interfaces
The system shall interface with an Oracle or Access database.
To implement the project we have chosen HTML language for its more
interactive and easy to understand support.

Communications Interfaces
This System supports Google chrome and Mozilla Firefox web browsers.
This System involves FAQ forms for the requesting information, queries
and problems etc.
Functional Requirements
System will keep Employee records
System provides Information about the leave approval and leave
availability.
Keep staff record.
Keep notices record.
Display leave history.
NON-FUNCTIONAL REQUIREMENTS
Non-functional requirements define the needs in terms of performance,
logical database requirements, design constraints, standards compliance,
reliability, availability, security, maintainability, and portability.

PERFORMANCE REQUIREMENTS
Performance requirements define acceptable response times for system
functionality.
The load time for user interface screens shall take no longer than two
seconds.
The log in information shall be verified within five seconds.
Queries shall return results within five seconds
The system shall consume very little of primary memory
SECURITY REQUIREMENTS
Customer Service Representatives and Managers will be able to log in to
the Leave Management System. Customer Service Representatives will
have access to the leave management and scheduling subsystems.
Managers will have access to the Management subsystem as well as the
leave management and scheduling subsystems. Access to the various
subsystems will be protected by a user log in screen that requires a valid
UserId.

SOFTWARE QWALITY ATTRIBUTES

Standards Compliance
There shall be consistency in variable names within the system. The
graphical user interface shall have a consistent look and feel.
Reliability
Specify the factors required to establish the required reliability of the
software system at time of delivery.
Availability
The system shall be available 24*7.
Maintainability
The Leave Management System is being developed in Java. Java is an
object oriented programming language and shall be easy to maintain.
Portability :The Leave Management System shall run in any Microsoft
Windows environment that contains Java Runtime and the Microsoft
Access database.
EXPERIMENT-2
VIVA QUESTIONS

1. Explain data flow diagram?

2. Justify the purpose of the interaction model for a web application?
3. Explain architectural design elements?
4. Explain design interface element?
5. Explain component level design element?
6. Explain about the architectural styles?
7. Explain about the architectural patterns?
8. Explain transform mapping?
9. list out transaction flow.types of transaction flow?
10 .Explain about architectural designs?
 Experiment no 3: E-BIDDING
Existing on line auction system

The first part is an investigation of already existing on-line auction systems

around the net. We considered three of the most famous auction web
sites: eBay.com, asteinrete.com and onsale.com.
The table below describes the functionality offered to the users by this
three big auction systems:

User Stories eBay.com asteinrete.co onsale.com

m

Home Page X X X

Registration X X X

Login X X X
 Personal Page X X X

Search X X X

Excluding a word X

In a given category X X X

In a given city X

Having price form € to € X X

Browse X X X

Item Page X X X

Bid X X X

Post an auction X X X

Help X X X

Change Language

Chat X

Administration ? ? ?

As shown in the table, all the three systems give the possibility to register,
to login to the website and have a home page with a general description
of the portal. They offer also a personal page, where each user can check
the status of their auctions or of their offers.
Another characteristic of this portals is to have an item page, a page that
describes each item on auction (with a textual description, a photo etc.).
The search functionality is also very important: in addiction to a normal
keyword search, eBay offers also the possibility to search excluding a given
word, search in a given category, search for auctions regarding a given city
and to make price range (from € to €) search. All the three systems give
also the possibility to place a bid, to post an auction and have also some
help pages that explains the aims of the portals and the functionality.None
of the portals has the possibility to change language (onsale.com is in
English, asteinrete.com is in Italian while eBay.com is in English but there
is also the Italian version at eBay.it) and only eBay.com has a chat room for
the users.

Functional requirements and system design:

The first step of the project is to find the functional requirement of the on
line auction portal with the help of techniques like Use Cases and User
Stories. After having found the functional requirements, the project goes
on with the system design using the following techniques: the UML class
diagram, the EER diagram for the database design and the page flow
diagram.

Use Cases

The first step for the functional requirement collection are the use cases.
Use cases are “a description of set of sequences of actions, including
variants, that a system performs that yield an observable result of value to
an actor”. They are used in order to: design system from user’s
perspective, communicate system behaviour in user’s term and
enumerate all externally visible behaviour [11].
Here are the use cases for the on line auction system project (there are
two actors for the system: a normal user and an administrator).
As shown on the schema, a normal user can register to the system,
browse the available items, post his/her bid and post a new auction. The
administrator, on the other hand, can insert and modify available data
about items, users and categories of items.

User Stories

After collecting all use cases, user stories can be written. A user story “is
the smallest amount of information (a step) necessary to allow the
customer to define (and steer) a path through the system” [8].
The user stories are divided into 2 main categories: user side (stories for
the general users) and administration side (the stories for the
administrators of the system).
User Side Stories:

Home Page:
The home page is the entry point to access the main services:
Register
My personal page
Search
Help
The home page shows also a list of categories to simplify items searching
and the latest auctions.

Registration:
The registration page allows user to provide his/her personal data (name,
address, date of birth, fiscal code, email address, phone number, userID,
password) and receive a userID and a password. UserID and password
allow the user to access to his/her personal page, to take part to the
auction and to post a new auction.
It performs basic checks on entered data and provides user registration or
an error message if the userID and/or user fiscal code are already present
in the system.

Login
Every time the user tries to access to non-public areas (personal page, bid,
post an auction…), he/she is asked to provide his/her personal ID and
password. These are entered through a form. If userID and password are
correct, the user is logged in and is no more asked to login throughout the
session. Otherwise an error message is raised.

Personal page:
To access the personal page the user is asked to login, or to register. The
personal page keeps track of all the items the user is presently trying to
buy and has bought in the recent past and of all items he/she is trying to
sell. From this page it is also possible to post a new auction.

Browse:
The user can browse the auctions selecting among several categories of
items (e.g. cars, books etc.). The results will be shown in a table and the
user can sort them by price, by auction interval (by lasting period of the
auction).
Search:
The user can search for items on auction providing a key word by different
criterions:
Excluding a word
In a given category
In a given city
Auctions having price from a given value in Euro to another value Both
registered and unregistered users can access to this service.

Item page:
Item characteristics are shown in the item page. From this page the user
can place a bid pushing the button “PLACE A BID” and view the chronology
of the bids.

Bid:
The user that makes a bid is asked to login if not already logged. If the bid
is accepted by the system, the item is listed in the user personal page. Bids
can only be placed during the auction interval and they must be at least
one minimum increment bid above the current price.

Post an auction:
From his/her personal page, the user can post an auction from a specific
form, providing the characteristics of the item he/she is willing to sell. If
the auction is accepted by the system, the item is listed in the user
personal page and other users can place a bid for it.

Help:
The system must provide help pages in order to explain how to perform all
possible actions, such as registering, searching items, posting an auction
etc.

Change language:
The user can change from every page the language in which he/she wants
to read the pages with a combo box (Italian/English).

Chat:
The user can enter in a chat room using as nickname his/her userID and as
password his/her personal password. In the chat room can send message
to all users or send private messages to only one user.

Messages:
The user can send message to other users with a text and a topic and the
message will be sent via email to the receiver. It is also possible to view
the received messages on the website and answer to them.
Administrator Side Stories:

Administrator Page:
From the login page, providing his/her administratorID and password,
he/she can access the administrator page, that shows the administrator
menu to access all the administration activities (manage items, manage
users, manage categories).

Manage Items:
The administrator can access all data about items stored in the database
and also delete them, but not modify the characteristics of the items
(initial price, description etc.).

Manage Users:
The administrator can access and modify all data about users stored in the
database and also delete them.

Manage Categories:
The administrator can access and modify all data about categories stored
in the database, add a new category and also delete them. The
administrator can delete a category if and only if no items are associated
to that category; otherwise an error message is raised.

Accept / refuse auction:

The administrator can control the new auctions posted by the user and
decide whether to accept or to refuse them.

Then, we write a table that assigns to each user story a priority and a risk
level:

User Stories Priority Risk

User Side Stories

Home Page Must Low

Registration Must Medium

Login Must Medium

Personal Page Must High

Search Must Medium

Excluding a word Should Medium

 In a given category Must Medium

Having a price from € to € Should Medium

In a given city Should Medium

Browse Must Medium

Item page Must Medium

Bid Must High

Post an auction Must Medium

Help Should Low

Change language Could Medium

Chat (spike) Could High

Messages Should Medium

Administration Side Stories

Administrator Page Must Low

Manage Items Must Medium

Manage Users Must Medium

Manage Categories Must Medium

Accept / refuse auction Must Medium

UML Class Diagram

The next step of the design phase is to draw an UML Class Diagram of the
system. Since the programming language of the system is an object
oriented one, an UML Class Diagram is particularly adapted to show the
classes of the system, their inter- relationships, and the operations and
attributes of the classes [1].
Here is the class diagram of the project.

The class User contains several parameters that are information about a
normal user that browses the system (username, password, name,
surname…); the parameter administrator is a flag that indicates whether
the user is an administrator or not. This class performs the operations of a
normal user (search for an item, get the items on auction, post a new
auction, send messages to other users) and those of a system
administrator (create a new category, delete a category, delete an item,
delete an user). The class Message has a text, a topic and the user_id of
the sender and of the receiver. The class Item contains several information
about the item on auction (the name of the item, its photo, a textual
description of it..) and about the category it belongs to.
A category has a name and, eventually, a super-category it belongs to: a
category can belong to another category (e.g. category sport car belongs
to category car).
Class Motor and Music are subclasses of Item. Car and Motorcycle are
subclasses of Motor: they inherit the properties of class Item and they
have their specific attributes (model, km, matriculation date). CD, MC and
Instrument also inherit properties form Item and have their own specific
attributes (genre, condition).
Class SoldItem represent an already sold auction item, its attributes are
the name of the item, the final price, the date in which it was sold and its
buyer and seller.
EER Diagram for Database Design
After having drawn the UML Class Diagram for the On Line Auction
System, it is clear what kind of data should be stored in the database.
Since PostgreSQL is a relational database, the EER modelling approach is
very useful to design the database schema since it maps well to the
relational model and the constructs used in the ER model can easily be
transformed into relational tables [13].
Here is the EER Diagram for the database of the system.

As shown on the schema, there are several entities (user, item, message…)
with their own attributes and relations. Motors and music are particular
kind of items (they extend the entity item). Each User owns one or more
items and can bid, making an offer, for one or more of them. Each Item, on
the other hand, is owned by exactly one User and belongs to one category.
A Category can have one super-category. A Message is sent from one User
to exactly one another User.
Car, motorcycle and CD, MC, instrument are respectively sub-entities of
motors and music. In addition to the attributes inherited from item, they
have their specific attributes (km, matriculation date, genre..).
Sold-Item is a particular kind of entity called “weak entity”. A weak entity,
in contrast to regular entity, does not have key attributes of its own. When
an Item is sold, it becomes a Sold-Item.
From the EER diagram, it is easy to get the tables of the database using
the “Elmasri” algorithm [3], here are the tables of the on line auction
system database. For EMJ conventions, each entity has an integer ID as
primary key.

USER(user_id(PK), username, pwd, administrator, givenName,

familyName, phoneNo, address, civicNo, city, state, fiscalCode)
MESSAGE(message_id(PK), from(FK USER), to(FK USER), topic, text)
ITEM(item_id(PK), initialPrice, name, photo, description, available,
intervalStart, intervalEnd, owner(FK USER)) BID(bid_id(PK), item(FK ITEM),
offerer(FK USER), offer) MOTORS(motors_id(PK, FK ITEM))
MUSIC(music_id(PK, FK ITEM))
CAR(car_id(PK, FK MOTORS), km, immatDate, model)
MOTORCYCLE(motorcycle_id(PK, FK MOTORS), km,
immatDate, model)
CD(cd_id(PK, FK MUSIC), genre, condition) MC(mc_id(PK, FK MUSIC),
genre, condition) INSTRUMENT(instrument_id(PK, FK MUSIC), condition)
SOLDITEM(item_id(PK), name, date, price, buyer(FK USER))
CATEGORY(category_id(PK, FK ITEM), name, super-category(FK
CATEGORY))

Page Flow Diagram

Since the on line auction portal consists of web pages, it is useful to draw
a page flow diagram. A page flow is a diagram that visually organizes the
flow and actions of the web pages [9]. Here is the page flow that
represents the path, for a normal user, to register to the system, search for
an item and place a bid and make a logon.

As shown on the diagram, from the home page it is possible to reach the
registration page and enter the personal data of the user. If the data are
right, the user can reach a confirmation page, otherwise (e.g. the
username that he/she choose is already in use) an error page. From the
homepage it is also possible logon inserting username and password and
reach a search page to search for an item. The result of the search are
given in another page where there are the links to see the item’s detail
(description, photo…) and place a bid for that item.
Here the page flow for write messages to other users, view the items on
auction and post a new auction.
From the home page it is possible, for logged users, to reach their
personal page. From the personal page it is possible to write message to
other users, read the received messages, view their own items on auction
and post a new auction with an insertion form.
Finally, the page flow diagram for the administration activities.
When a user is a system administrator, after having inserted username
and password, can reach the administration page. From the administration
page it is possible to view all data about users and items present in the
database and manage them. For an administrator it is also possible to
view a list of the new auctions proposed by the user and accept or refuse
them.
PROTOTYPE MODEL FOR E-BIDDING:
VIVA QUESTIONS
1. Explain the basic design principle in class-based components?
2.Explain different types of coupling?
3.List out quality factors?
4.List out the software Risks?
5.Differentiate between Error and defect?
6.List out the elements of software quality assurance?
7.List out goals ,attribute & metrics of software quality assurance?
8.Explain 6 software engineering?
9.Give the formula for mean-time between failure?
10.give the formula for availability?
 Experiment no 4:
ELECTRONIC CASH COUNTER:

PROBLEM DEFENITION
To develop an automated banking system, which is required to perform
the following functions:
The customer logs into the system using card number and pin number. The
system checks for validation.
The system queries the customer for the type of account either fixed
deposit or credit account. After getting the type of account the system
shows the balance left.
The system queries the customer for the transaction type either
withdrawal or deposit and the required amount. The user enters the
amount and the transaction if carries out
SRS DOCUMENT FOR AUTOMATED BANKING SYSTEM
INTRODUCTION
Purpose
The purpose of this SRS is to describe the requirements involved in
developing an Automated Banding System (ABS).
The intended audience is any person who wants
To create account.
To withdraw or deposit either in fixed deposit
or credit account.
Scope
The product is titled Automated Banking System (ABS).
The product will perform the following tasks
Allow a new user to create an account, either fixed or credit account by
entering the details and by depositing an initial amount.
Allow the existing user to enter his account details like card number, pin
number and account type to view his balance.
Allow the existing user to deposit an amount by entering the amount to
be deposited after the balance had been viewed.
Allow the existing user to withdraw an amount by entering the amount to
be withdrawn after the balance had been viewed.
The primary benefits expected of the system are: user friendly, continuous
connectivity without failure, fault tolerant and involves lesser manpower.
Definitions, Acronyms and Abbreviations
ABS: Automated Banking System.
Overview
The SRS contains an analysis of the requirements necessary to help easy
design.
The overall description provides interface requirements for the Banking
system, product perspective, hardware interfaces, software interfaces,
communication interface, memory constraints, product functions, user
characteristics and other constraints.
Succeeding pages illustrate the characteristics of typical naïve users
accessing the system along with legal and functional constraints enforced
that affect banking system in any fashion.
THE OVERALL DESCRIPTION
Product perspective
Hardware interfaces
Hard disk: The database connectivity requires a hardware configuration
that is on-line. This makes it necessary to have a fast database system
(such as any RDBMS) running on high rpm hard-disk permitting complete
data redundancy and backup systems to support the primary goal of
reliability.
The system must interface with the standard output device, keyboard and
mouse to interact with this software.
Software interfaces
Back End: Oracle
Front End: Microsoft Visual Basic 6.0
Operations
The user can create a new account.
The existing user can access his account and view his balance by entering
his details.
The user can deposit and withdraw money from his account.

Product Functions
Creating a New Account
The user should provide his personal details to facilitate the bank clerk to
create a new account. The user should provide:
Customer Name.
Customer address.
Required account type.
Pin Number.
Initial deposit.
Operating with created account
The user should be able to operate with his new account after:
Entering card number.
Entering pin number.
Entering the account type, transaction type and amount involved in the
transaction.
User characteristics
The intended users of this software need not have specific knowledge as
to what is the internal operation of the system. Thus the end user is at a
high level of abstraction that allows easier, faster operation and reduces
the knowledge requirement of end user
The Product is absolutely user friendly, so the intended users can be the
naïve users.
The product does not expect the user to possess any technical
background. Any person who knows to use the mouse and the keyboard
can successfully use this product.
Constraints:
At the time of creating the new account, each user gives a pin number and
is provided with a unique card number that must be used for further
transactions. Hence the user is required to remember or store these
numbers carefully.
At the time of creating the new account, the initial deposit should not be
less than the specified amount.
SPECIFIC REQIREMENTS
Logical Database Requirements
The system should contain databases that include all the necessary
information for the product to function according to the requirements.
These include relations such as Customer Details and Account Details.
Customer details refer to the customer’s name and address. Account
details of the customer include the card number, account type, transaction
type and the pin number given by the user to be used at the time of the
transaction at the bank.
FRONT – END DESCRIPTION
The front end for the Automated Banking System (ABS) is designed using
Microsoft Visual Basic 6.0. The front end contains a user-friendly interface.
The first form contains a welcome screen that provides an option for the
user to either crate a new account or to operate through an existing
account. The “create account” module contains a provision to crate a new
account after collecting the customer name, address and other details.
The card number and pin number of the user is obtained every time there
is a transaction. The user is requested to select the required type of
transaction and the amount involved in the transaction.
BACK – END DESCRIPTION
 The Automated Banking System (ABS) database contains only one table. It
correlates a unique card number, customer name, account type, pin
number and the balance.
DATA FLOW DIAGRAM:

Administrator
Display summary report

Queries for details

User

Commits transaction

Enters a/c number + pin number

Database
Update

Checks for availability

Generates error report
Enters details
Displays report on a/c details
about new transaction

3.0 TESTING

FORM NAME INPUT EXPECTED ACTUAL STATUS

OUTPUT OUTPUT

MAIN FORM Existing user Menu form must Menu form was Pass
be displayed
displayed
MENU FORM Card and pin Validate card and Card and pin Pass
numbers pin number number were
validated

CUSTOMER User details are Create a new New account Pass

DETAILS entered account was created

DEPOSIT FORM Amount to be Deposit amount Amount was Pass

deposited is deposited
entered

WITH DRAW Amount to be Withdraw amount Amount was Pass

FORM withdrawn is withdrawn
entered

4.0 SAMPLE FORM

NEWACCOUNTFORM
CUSTOMER INFORMATION FORM
TRANSACTION FORM (WITHDRAW)

TRANSACTION FORM (DEPOSIT)

PROTOTYPE MODEL FOR ELECTRONIC CASH COUNTER:

38
VIVA QUESTIONS

1. Explain about unit testing,integration testing,regression testing?

2.Explain about validation testing?
3.Explain alpha and beta testing?
4.Explain cyclomatic complexity?
5.Explain white box and black bo testing?
6.list out process and project metrics?
7.Explain evaluation of size-oriented metrics?
8.Explain function oriented metrics?
9.what is the relation between lines of code and function point
metrics?
10 list out web app project metrics?
ADDITIONAL VIVA QUESTIONS
1.compute the function point value for the project with the following
information?
Domain characteristics
1) number of users inputs 32,outputs-60,user enquirer -24,number
of files 8,number of external interface-1
Assume that all complexity adjustment value are average
2. Explain software risk?
3. Explain RMMM plain?
4. Differentiate between risk component,risk drivers?
5. Differentiate between known risks and predictable risk?
6.Explain the software re engineering process model?
7.Explain the forward and reverse engineering?

39