Class Test - 001

Q2:
A project size of 200 KLOC is to be developed. Software
development team has average experience on similar type of
projects. The project schedule is not very tight. Calculate the Effort,
development time, average staff size, and productivity of the
project. Discuss the classifications of Cost Drivers and their
attributes in COCOMO model.

Solution: The semidetached mode is the most appropriate mode, keeping in view the
size, schedule and experience of development time.

Hence E=3.0(200)1.12=1133.12PM
D=2.5(1133.12)0.35=29.3PM

P = 176 LOC/PM

Classification of Cost Drivers and their attributes:

(i) Product attributes -

o Required software reliability extent

o Size of the application database
o The complexity of the product

Hardware attributes -

o Run-time performance constraints

o Memory constraints
o The volatility of the virtual machine environment
o Required turnabout time

Personnel attributes -
 o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

Project attributes -

o Use of software tools

o Application of software engineering methods
o Required development schedule

Q3:
Draw the DFD for ATM system (see details from question 1)
& decompose the processes up to level 2 diagram. More
level diagram will carry extra marks.

Solution:

DFD for ATM system

DFD (Data Flow Diagram) of an ATM System consist of two levels of DFD. These
levels are Level 0 DFD and Level 1 DFD. Both these levels are used for making the
DFD of an ATM system.
1. Level 0 DFD:
This level is also known as Context Level DFD. At this level, only the
interacting inputs and outputs with a system are described. The DFD of
this level is shown below:
2. Level 1 DFD:
At this level, more detailed information is given about the processing of
the ATM system. The DFD of this level is shown below:
 Level – 2 DFD
Q4:
Draw the SRS for academic system of your institute. Describe the
roles of project manager. Draw a SPMP document for academic
system.

Solution-

THE ROLE OF THE PROJECT MANAGER

The role of the project manager encompasses many activities including:

• Planning and Defining Scope

• Activity Planning and Sequencing
• Resource Planning
• Developing Schedules
• Time Estimating
• Cost Estimating
• Developing a Budget
 • Documentation
• Creating Charts and Schedules
• Risk Analysis
• Managing Risks and Issues
• Monitoring and Reporting Progress
• Team Leadership
• Strategic Influencing
• Business Partnering
• Working with Vendors
• Scalability, Interoperability and Portability Analysis
• Controlling Quality
• Benefits Realisation

Software Requirements Specification for Student Management

System
This is the Software Requirements Specification for Student Management
System, Which is developed using .Net and SQL Server.

1: Introduction
1.1 Purpose

Our product is student management system gives all the services that must
be provided to a student over the internet to find fee details provided by
that administrator of the college.
This product contains each and every data regarding student, payment
etc., personal details which can be updated by the student and viewed by
the administrator. It provides the detailed information about the fee details
and the location (place) of college. Our product is a subpart of university
management system.
1.2 Intended Audience and Reading Suggestions

The intended audience for this Student Management System document is

the internal guides of the organization where the team has developed the
project. Further modifications and reviewing will be done by the
organization and deliver a final version. The final version of this document
is reviewed by the Internal Guides and Head of the Department of the
college.

1.3 Project Scope

Our Student Management System product usage makes work done at the
faster way the software is applicable to view the fee details provided by the
administrator of the organization and student can edit his personal details
which can be viewed by the administrator.
2: Overall Description
2.1 Product Perspective

Student Management System is capable of managing each and every data

regarding student, payments etc. Student Management System helps us in
managing in an extremely efficient way. This Student Management System
works in an efficient manner.

We have two modules in this project. One is admin and other is the user.
Admin can maintain the fee details of students and can generate the
reports can export the details to excel. User module can edit their personal
details and can view the fee details.

2.2 Product Features

• Reduces the manual workload.

• Complete details of the student can be stored and retrieved.
• Admin can see all the student’s payment details and also export to
excel sheets.
• The student can view all his details, payment details and the location
of the college.
2.3 Design and Implementation Constraints

The Student Management System software is designed in such a way that

the user can easily interact with the screen because of GUI. The admin and
the user are the two users who use the project. The admin inserts the
details of the students and the fee details that the students have paid. User/
student can view his/her details, update if required and check the fee
details.

Software requirements:

• Microsoft .Net framework 3.5

• Microsoft Visual Studio 2008
• Microsoft ASP.Net 3.5
• Microsoft C#.Net language
• Microsoft SQL Server 2005
• ADO.NET
• HTML

Hardware Requirements:

Processor: Intel Pentium 4 or more

Ram: 1 GB or more

Hard disk: 40 GB hard disk recommended for the primary partition.

2.5 User Documentation

In our user manual, we are going to keep the information regarding our
product which can be understandable by a new person who is going to use
it. If a new person is using it online help will be provided in that we are
going to explain each and every step clearly by our product can be useful
for any user.

3: System Features
This Student Management System project is divided into 2 modules

1. Administrator and
2. User

Module Description
Admin: Admin is a person whose responsibility is to maintain the database
that contains each and every data regarding the all the student. Admin can
add student details into the database, can be able to delete student details
and can update the student fee details.
Admin has some other responsibilities they are
• Admin is can maintain the fee details of each and every student.
• Admin can generate the reports of the students and
• Admin can export the details to excel.

User: Here the user means the student. The responsibility of the student is
to login into the site and can view his/her fee details and can able update
his/her personal details if there is any wrong details are present. Whenever
the student will register his/her name then the student will be given by one
individual username and password. When the student will type the correct
username and password then the will enter into another page. In that page,
the student can select two options that are updated details and view
details. A student can able to update his/her personal details and can be
able to view the fee details but cannot update the fee details.

4: External Interface Requirements

Hardware Interfaces

We require LAN connection for interacting with the database and local
computers for any help or any other requirement. We use TCP/IP protocol
for communicating with local hosts. We also need a system with P4
processor; 1GB RAM and database memory.

Software Interfaces

We use MS.Net 3.5 and C#.Net 3.5 Programming language for writing the
code for the project. ASP.Net 3.5 for creating the web pages, using GUI for
login screens and interacting with the database. SQL server 2005 is used
for creating the local and global database (server). Microsoft Visual Studio
2008 IDE for writings the programs. Operating system: Windows XP or
higher version.

Communications Interfaces

The communications functions required by this product are LAN connection

within the whole company so that the Admin, employee, and customer can
interact with each other. We use TCP/IP protocol.
Q1:

Identify the requirements for the following problem:

Design the software to support a computerized banking network

including both human cashiers and automatic teller machines
(ATMs) to be shared by a consortium of banks. Each bank provides
its own computer to maintain its own accounts and process
transactions against them. Cashier stations are owned by individual
banks and communicate directly with their own bank’s computers.
Human cashiers enter account and transaction data. • Automatic
teller machines communicate with a central computer that clears
transactions with the appropriate banks. An automatic teller
machine accepts a cash card, interacts with the user, communicates
with the central system to carry out the transaction, dispenses cash,
and prints receipts. The system requires appropriate record keeping
and security provisions. The system must handle concurrent
accesses to the same account correctly. • The banks will provide
their own software for their own computers; you are to design the
software for the ATMs and the network. The cost of the shared
system will be apportioned to the banks according to the number of
customers with cash cards.

Solution –
Automated Teller Machine Example

Requirements Specification

Design the software to support a computerized banking network including both

human cashiers and automatic teller machines (ATMs) to be shared by a
consortium of banks. Each bank provides its own computer to maintain its own
accounts and process transactions against them. Cashier stations are owned by
individual banks and communicate directly with their own bank’s
computers. Human cashiers enter account and transaction data. Automatic teller
machines communicate with a central computer which clears transactions with the
appropriate banks. An automatic teller machine accepts a cash card, interacts with
the user, communicates with the central system to carry out the transaction,
dispenses cash, and prints receipts. The system requires appropriate record-
keeping and security provisions. The system must handle concurrent accesses to
the same account correctly. The banks will provide their own software for their
own computers; you are to design the software for the ATMs and the
network. The cost of the shared system will be apportioned to the banks according
to the number of customers with cash cards.

We now read through the requirements document and underline the nouns
(or noun phrases) and circle (italicize) the verb phrases.

Design the software to support a computerized banking network including

both human cashiers and automatic teller machines (ATMs) to be shared
by a consortium of banks. Each bank provides its own computer to maintain its
own accounts and process transactions against them. Cashier stations are
owned by individual banks and communicate directly with their own bank’s
computers. Human cashiers enter account and transaction data. Automatic
teller machines communicate with a central
computer which clears transactions with the appropriate banks. An automatic
teller machine accepts a cash card, interacts with the user, communicates
with the central system to carry out the transaction, dispenses cash,
and prints receipts. The system requires appropriate record-keeping and
security provisions. The system must handle concurrent accesses to the same
account correctly. The banks will provide their own software for their
own computers; you are to design the software for the ATMs and
the network. The cost of the shared system will be apportioned to
the banks according to the number of customers with cash cards.

List of underlined nouns:

software banking network cashier ATM consortium

bank bank computer account transaction cashier

station

account data transaction data central cash card user

computer

cash receipt system record-keeping

provision

Security access cost customer

provision
From this list of nouns, we need to identify the classes. We eliminate
candidates that are:
1. Redundant -- user (customer)

2. Irrelevant -- cost

3. Implementation constructs -- words like algorithm, process, data

structure, interrupt, linked list, and CPU cycle are not part of the
problem domain, but may be relevant in the design and
implementation of the system. In this list we may exclude -
- access, software

4. Roles – the name of a class should reflect its intrinsic nature and not
a role it plays in an association. In a company a person may be
asked to play the role of a boss or a subordinant. A system could be
modelled that included these two separate classes, but a system in
which a person object was capable of playing either role would be far
more robust and flexible. In this list there are no terms that should be
considered as roles in an association.

5. Attributes – names that describe properties of individual objects and

names that do not have additional attributes and behaviours
associated with them. -- account data, transaction data
(Both of these are not simple strings or numbers but have several
fields and could be considered objects)

6. Operations – the name of something that is applied to an object, but

not manipulated in its own right. None in this list.

7. Vague classes – classes must be specific with well-defined properties

and boundaries. Names describing general concepts are not good
candidates for being classes. Vague nouns may indicate areas in the
requirements document that need further refinement, or point to
subsystems that will need to be fleshed out in subsequent refinements
of the model. In this example the vague nouns
are: system, security provision, record-keeping
provision, banking network

Identified classes in the ATM system

Account ATM Bank Bank-computer CashCard

Cashier Consortium Customer CashierStation CentralComputer

Transaction Cash Receipt

Now go back to the requirements document and extract the verb phrases that
relate to these nouns.

Subject Verb phrase Object Indirect object

phrase
Consortium shares ATMs
Bank provides BankComputer
BankComputer maintains Accounts
BankComputer processes Transaction against
Account
Bank owns CashierStation
CashierStation communicates with BankComputer
Cashier enters Transaction for Account
ATMs communicate with CentralComputer about
Transaction
CentralComputer clears Transaction with Bank
ATM accepts CashCard
ATM interacts with Customer
ATM dispenses Cash
ATM prints Receipt

Implicit verb phrases

Consortium consists of Banks

Bank holds Account
Consortium owns CentralComputer
Customers have CashCards

Additional implicit verb phrases from knowledge of the problem domain

Bank employs Cashiers

CashCard accesses Accounts

Now we eliminate the phrases that do not represent proper associations

1. Only keep phrases where the subject has not been eliminated as a class
candidate. This is already done in this list.
2. Irrelevant or implementation associations –
3. Actions -- Associations describe static structural properties not temporal or
transient ones. In this example, ATMs print receipts and dispense cash have
 attributes as objects and indicate that dispense and print are two operations of
an ATM. ATMs accept Cashcards is part of the transaction cycle.
4. Ternary Associations – Most associations between three or more classes can be
decomposed into binary associations or phrased as qualified
associations. Cashier enters transaction for account can be decomposed
into Cashier enters transaction and Transaction concerns account.
5. Derived Associations – omit associations that can be derived in terms of other
associations. As much as possible, classes and associations in the object model
should represent independent information. Multiple paths between classes in a
diagram often indicate derived associations which are compositions of primitive
associations. Consortium shares ATMs is a composition of Consortium
owns CentralComputer and CentralComputer communicates with ATMs. Not
all multiple paths between classes indicate redundancy. If the multiplicity
assignments are important and do not match then both associations may be
needed.

Domain Model
Initial Object Model Diagram

The first refinement of this model is to assign attributes to the classes and
organize classes by using inheritance to share common structure. Look for
classes with similar attributes and associations to make
generalizations. Qualifiers select from among objects in a set and remove
multiplicity. Only consider attributes that are visible in the problem domain
and relate to the particular application at this time.
CashierTransaction and RemoteTransaction have the same association
names, multiplicity, and attributes. They should be generalized. Similarly,
ATM and CashierStation have associations of the same name and perform the
same kind of services. We now incorporate this new view into a revision of
the initial object model diagram. Multiplicities can be removed by association
qualifiers that distinguish between the multiple objects.
Iterating the Object Model:

1. Signs of missing objects include:

• asymmetries in associations and generalizations
• disparate attributes and operations on a class – split a class so that each part is
coherent
• difficulty in generalizing cleanly – one class may be playing two roles, split it
up and one part may fit cleanly
• an operation with no good target class—add the target class
• duplicate associations with the same name and purpose – generalize to create
the missing superclass that unites them
2. Signs of unnecessary classes include
• lack of attributes, operations, and associations: why is it needed?

Further refinement of this model is suggested by the diagram. The distinction

between the Bank and the BankComputer does not affect the analysis. The
fact that communications are handled by computers is an implementation
detail. Transaction is not sufficiently general because it concerns only a single
account. In general transactions consist of one or more updates on individual
accounts. An update is a single action.
System Sequence Diagrams
System Operations

• swipeCard
• enterPasscode
• selectTransaction
• enterAmount

For each system operation write a contract in which you identify the objects
(classes) that collaborate to provide the requested function. Then construct the
collaboration diagrams that detail the exchange of messages required to
implement the indicated collaboration.