Table of Contents

baasopchoppyΑσφάλεια

5 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

365 εμφανίσεις

ANS
-
1

Table of Contents



Overview of the Proposed System

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

3

Description

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

4

Requirements

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

4

System Context Diagram

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

4

Use case Scenario

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

6

Use ca
se Diagram for Student and Lecturer

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

7

Use case model for Admin
................................
................................
................................
.......

8

Use case model for coordinator

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

9

Database requirements

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

10

Activity Diagram

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

10

Activity diagram for students

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

10

Activity diagram for lecturer

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

11

Data Dictionary

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

Error! Bookmark not defined.

Entity
-
Relationship Diagram

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

Error! Bookmark not defined.

Functional Requirements

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

13

Non Functional Requirements

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

14


Approvals

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

14

References
................................
................................
................................
................................
..

15




INTRODUCTION


Project name

Assignment Submission System (ASS)

Project description

The purpose of this Project is to develop an assignment submission system, which will include many
functions for
submit the assignments online. Before that institute was using old paper based system to manage the assignments but
the paper based system is so old and with some disadvantages that are unacceptable in this technology age. For
example the stu
dents do not know if an assignment has been received to the tutor or not. Second big issue is tutor
might lose paper assignment, and a student may not have photocopied their work as advised. So the university realize
to modernization it, so they want to bu
ild a web based base system for their student so that student can able to submit
their assignment online even lecturer can mark their assignment online, grade them and student should able to check
their grade. This will provide enhanced student feedback a
nd administrative cost savings across the University. The
budget for this project is $6000 and allocated time is within 3 months. This is a web
-
application therefore it can run
on popular browsers like Internet Explorer, Firefox, Chrome, Safari, and Opera.

Objectives



Provide an electronic assignment handling solution for university.



Provide robust administrative tools for the creation, modification, marking and moderation of assignments.

Acceptance criteria



We used unified process methodology because we fo
und this methodology best suited for us because of time
shorten and quick development.



We worked on VB.net frame to build the system because we are good in VB.net.



VB.net is powerful tool, flexible, simplified deployment, and full object oriented construct
s.




Definitions

Terms

Definitions

SRS


Software Requirements Specification


WBS

Work breakdown Structure

ER

Entity Relational Diagram

CRM

Customer relationship management

DFD

Data Flow Diagram

Scope

All the work involved in creating this booking

system and the processes used to create them.

SDLC

Software development life cycle


Overview of the Proposed System

Our system will inte
ract with University

database to retrieve students and lecturers information; therefore we decided
to use interfaces
to be easier in changing in the future. Besides, we use GRASP (General Responsibility Assignment
Software Patterns/Principles) to assign responsibility to classes and objects in our object
-
oriented design (Cotroneo
et al., 2000). The different patterns and

principles used in GRASP are: Controller, Creator, Indirection, Information
Expert, High Cohesion, Low Coupling, Polymorphism, Protected Variations, and Pure Fabrication.

Our system context diagram shows the interactions between the system and other actor
s with which the system is
designed to interface. Our system context diagram can be helpful in understanding the context which the system is
part of. We use this context diagram early in our project to get agreement on the scope under investigation (Cotron
eo
et al., 2000). This context diagram is also included in the requirement document. Besides, this diagram was written in
plain language thus the stakeholders can understand items within the document.


Description

The purpose of this Project is to develop a web
-
based assignment submission system which will include many
functions for users (students, admin, lecturer and coordinator). The allocated time is within 3 months. This is a web
-
application therefore it can ru
n on popular browsers like Internet Explorer, Firefox, Chrome, Safari, and Opera.


The system will focus on following functions



Managing data: allowing admin to enter and update data about courses and users.



Managing account: allowing users to update thei
r personal information.



Login System: allowing the users and admin to log in to the system with the username and
password.



Uploading System: allowing students and lecture to upload assignment into the system.



Grading System: lecturer should able to update
grade for assignments and also add comments
according to student’s performance.


Requirements

System Context Diagram



class Domain Model
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
EA 9.2 Unregistered Trial Version
AssignmentSubmissionSystem
IAssignmentSubmisionSystem
Database Subsystem
IDatabase
UniversityOfBallarat Subsystem
IUBallarat


Use case Scenario

This section demonstrates certain functions of the designed solution using high level use case diagrams. Use case
dia
grams tells you how the particular user will interact with the system.

Actors
:
User (Students, Tutor), Coordinator and Admin.



Procedure:



Users have their own id and password which they are currently using to access university website.



User enters userna
me and password to login.



The system verifies this information and if correct and matches the right level of access for a user, then it
takes user to the assignment page.



Student enters course information



Students can view assignment schedule, when it
’s due.



Lecturer can update their personal information.



After choose the course lecturer select assignment and can download particular student’s assignment.



Lecturer can upload marked assignment back to the system as a marked assignment and can grade
students.



Lecturer can also give valuable feedback to student based on their assignment.



Coordinator can update user’s information and can check the result of student.




Admin can update user’s information.



Admin can update courses and assignment informatio
n.

Exceptions:



If the User has entered wrong username or password. If this happens, user will have to try again.



Use case Diagram for Student and Lecturer





Use case model for Admin



Use case model for coordinator





Database requirements



‘User’ table will be accessed. ‘Username’ and ‘password’ will be read.



‘Course’ table will be accessed.



‘Assignment’ table will be accessed.


Activity Diagram

The activity diagram shows the basic flow of the main processes.

Activity diagram for students



Activity diagram for lecturer








Data Dictionary

























Table Name

Fields

Type

Description

Student

ID

VARCHAR(50)

PK


First name

VARCHAR(50)



Last name

VARCHAR(50)


Lecturer

ID

VARCHAR(50)

PK


First name

VARCHAR(50)



Last name

VARCHAR(50)


Staff

ID

VARCHAR(50)

PK


First name

VARCHAR(50)



Last name

VARCHAR(50)


Coordinator

ID

VARCHAR(50)

PK


First name

VARCHAR(50)



Last name

VARCHAR(50)


Course

ID

VARCHAR(50)

PK


Name

VARCHAR(50)



Description

VARCHAR(2000)


Assignment

ID

VARCHAR(50)

PK


Name

VARCHAR(50)



Description

VARCHAR(2000)


Assignment
-
Properties

Course
-
ID

VARCHAR(50)

PK, FK


references Course(id)


Assignment
-
ID

VARCHAR(50)

PK, FK


references Assignment(id)


Lecturer
-
ID

VARCHAR(50)



Due
-
date

DATETIME



Lock
-
date

DATETIME


Profile

ID

VARCHAR(50)

PK


Password

VARCHAR(50)



Role

VARCHAR(50)


Submission

Student
-
ID

VARCHAR(50)

PK, FK


references Student(id)


Course
-
ID

VARCHAR(50)

PK, FK


references Course(id)


Assignment
-
ID

VARCHAR(50)

PK, FK


references Assignment(id)


Submission
-
Date

DATETIME



Grade

VARCHAR(50)



Comment

VARCHAR(500)



Status

VARCHAR(50)


Functional Requirements

Functional
Requirement
ID

Requirement Title

Requirement detail


Priority

FR01

Authentication

The system will provide functionality to allow the
Students, lecturer, coordinator, office staff and admin to
log in to the system with the username and password.
On successful entry of username and password they
will be guided to the appropriate page.

If the details
provided are for a “student” they will be directed to the
submission page and result page. If the details entered
match a lecturer, they will be directed to the marking
page.

Essential

FR02

Validation

If the user enters wrong information they we be denied
access to the system.

Essential

FR03

Password recovery

If the user forgets password, he/she will have to enter
email address to receive new password.

Essential

FR04

Log out

As the student account
cannot perform lecturer
functions, all two types of accounts need the ability to
log out from the system and login with a different
username and password.

Essential

FR05

Enter new data

This function allows admin to enter new data about
course, submission
due time, user information and
create new user account for new students.

Essential

FR06

Update data

This function allows admin to update data about
student’s details, submission time (when extension time
is necessary) and course information.

Essential

FR
07

Submit assignment

This function allows students to submit their
assignments during submission time.


FR08

Manage
Submission

The submission page will allow lecturers to mark and
comment and upload the feedback to the system.

Essential

FR09

Register

A new student will have the ability to register a new
account of the website to be able to submit and check
the result online.

Essential

FR10

Manage account

The Manage Account screen will allow users to update
their personal information from the system.

Essential

FR11

Feedback

This Feedback function will allow the lecturer to give
feedback information to the student.

Essential

FR12

View Result

This function will allow a student to view their own
result and they cannot see other students result, this
fu
nction also permits lecturer, coordinator and office
staffs to view the result of all students in the particular
course.

Essential


Non Functional Requirements

Non
-
Functional
Requirement
ID

Non
-
Requirement
Title

Non
-
Requirement detail


Priority

Essential
/
Conditional /
Optional

NFR01

Usability

Due to the diversity of the users, the
system needs to be as simply as
information technology system can be

Essential

NFR02

Friendliness

The look of the site should be simple
and use highly contrasting colors for
text.

Essential

NFR03

Loading time

As this application is trying to reach the
widest audience possible the system
needs to be as bandwidth friendly as
possible.

Essential

NFR04

Security

The submission system needs to meet
all the security requirements of

an
online submission system.

Essential

NFR05

Privacy

The privacy of all the users of the site
should be safe and secured.

Essential

NFR06

Extensibility

The submission system should be
extended in the future when the amount
of users is increased.


Approvals


Sign
-
off Sheet


I have read the above Project Plan and will abide by its terms and conditions and pledge my full commitment
and support for the Project Plan.


Project Sponsor:

Date

Project Manager:

Date



References


1.

Cotroneo, D.,
Nixon, P., Russo, S.
&
Vele
, D. (2000).
Object
-
oriented Design of an Intelligent
Building Management System
. Orlando : Deputy Vice Chancellor.

2.

Lair, R. &

Lefebvre
, J. (2002).
Pure Asp.Net
. USA :Sams Publishing.

3.

Babu, R. (n.d.).
Advantages of ASP.NET
. Retrieved September 21, 2012,

4.

from http://www.java
-
samples.com/showtutorial.php?tutorialid=973






















ANS
-
2

0 LEVEL DFD











Assignment
Submission System

Lecturer

Student

Admin

Coordinator, Office staff

Login

Update
personal information

Choose course

Choose assignment

Mark assignment

Update assignment date

View results

Update personal information

Choose course

Choose assignment

View results

Submit assignment

Login














1 LEVEL DFD

STUDENT
Search
Assignment
Status
Search
Assignment
Marks
View Status
Not Found
Generate
Evaluator ID
View Marks
Not Found
STATUS
AsgmntResult
EVALUATOR
Issue
Assignment
Check
Assignment
Allot
ADMIN
[
Regional Centre
]
Register
Evaluator
Evaluator Details
Evaluator
Allot
Assignment
s
Prepare
Results
Assignments
Submit
Results
AsgmntResult
IssueAsgmnt












2
ND

LEVEL DFD



























Student

Login

Profile

Update
personal
information

Choose
course

Choose
assignment

Submit
assignment

Mark
assignment

View results

User

Submission

Update
assignment
information

Assignment properties

Lecturer

Coordinator and
office staff

Administrator

Login data

Login data

User data

User data

Assignment data

Assignment data

Assignment data

Assignment data

Assignment data

User

Course

Assignment

Update
course

Update user

Update
assignment

Assignment data

Course
data

User data

Login

Login

Login

Login

Update data


ANS
-
3

ER
-
DIAGRAM


























STUDENT

Addr

SEX

DOB

Prog_Code

E
No
.

Sna
me

ASSIGNMENT

AsgmntCode

MaxMrk

MinMrk

Submits

EVALUATOR

EvCode


EvName

Addr

sex

RESULT

CourseCode

MarksObt

Status

MaxMarks

Has

Views

Prepare


ANS
-
4

Problem in Developing MIS

1.

Despite the availability of technology today there is a problem in developing a good and problem free MIS

software for the MFIs. The diverse nature of microfinance creates an intriguing complexity for software

application development. Some of the complex
ities in developing a single or a small number of software to

meet the needs of the MFIs are discussed below.

2.

Many Institutional Models: The organizational forms is a function of the specific of social , political,

economics , regulatory and legal envir
onments throughout the world. There are a variety of organizational

forms that are assumed by the MFIs for carrying on their work. The MFIs can be in the form of credit

union, cooperatives, Non governmental Organizations (NGO) and even banks. All have th
eir own varied

type of requirement for MIS and its automation.

3.

Different Lending Methodologies: MFIs have vastly different lending methodologies across the globe and

even within the same country. Some MFIs follow individual lending some follow village b
anking

methodology and yet others may be following solidarity group lending . In Indian for example some MFIs

follow the e Grameen Model as per the example of the Grameen Bank, Bangladesh while other follow

Self Help Group Model as propagated by the ins
titutions like National Bank for Agriculture and Rural

development (NABARD)

4.

Methodology on Interest Payment: The practices for calculating interest and the periodicity for its

payment vary according to the product and organisation. These variations can
occur even within the same

organisation depending on the product and the area of operation.

5.

Other varied requirements: /there are variations in terms of the currencies languages and reporting

requirements of the MFIs.


6.

Does

the MIS disrupt established departmental boundaries? The establishment of a new MIS can
result in changes in several organizational units. For example, inventory and purchasing
departments may be merged to make more efficient use of the MIS. Such disrupti
ons may be
resisted by department members, who may resent having to change the way they do things or the
people with whom they work.

7.

Does the MIS disrupt the informal system? The informal communication network may be disrupted
as a new MIS alters communica
tion patterns. If organization members prefer some of the earlier,
informal mechanisms for gathering and distributing information, they may resist the more formal
channels set up for the new system. Development and Alumni Office managers often talk
informa
lly about the university’s graduates. A new MIS cannot interfere with that valuable
communications channel.


8.

Does

the MIS challenge specific individual characteristics? People with many years of service with
the organization have “learned the ropes” and know how to get things done in the existing system.
They may resist change more tenaciously than newer people who h
ave been with the organization
for a comparatively short period of time and do not have as large an investment in organizational
know how and relationships.


9.

Is the MIS supported by the organizational culture? If top management maintains open
communication

deals with grievances, and, in general establishes a culture with trust throughout
the organization, there is likely to be less resistance to the installation of a new MIS. However, if
top managers are isolated or aloof from other organization members, or

if the organizational
culture supports inflexible behavior then effective implementation of the MIS is likely to be
hindered. At many colleges and universities, departments have been relatively independent by
tradition. In this kind of culture, top manage
ment support must be supplemented by broad based
support from organizational members.


10.

Do employees have a say in how the change is implemented? As we have seen repeatedly earlier,
the manners in which changes are designed and implemented affects the amoun
t of resistance
those changes will encounter. In general when managers and employees make change decisions
together, there is a greater likelihood that the changes will be accepted.


11.

Implementation and Security:

Security of the new system is a control issu
e that must be addressed in the design and implementation
stages


for example, by placing equipment in safe and supervised areas and by constructing password
and read only files. There are a number of important security concerns to be addressed and the ri
sks
associated with mainframe computers and micro or personal computers vary. While the production of
mainframe configuration is usually adequate, security for microcomputer systems is sorely lacking in many
organizations.

Organizations using microcomputer

based information systems have experienced increased control
problems, such as theft and vandalism, the destruction or alteration of data and the unauthorized
dissemination of restricted or sensitive information. Theft and vandalism can be limited by plac
ing
equipment in secure areas or by making existing facilities more secure. Software or program piracy can be
prevented by copy guarding important programs and by securely strong authorized originals and backup
copies. Data can be protected by making alter
ations to on line data files impossible without the correct
password or by making backup copies of disks to preserve the originals from intentional or accidental
erasure.



SOLUTIONS
-

What Should We Do?

Thus, what can be done to improve the situation? In

a nutshell, the following could be the possible course
of action.

1.

Good Business Practices: The MFIs should first focus on building good microfinance practices as
only they can sustain the MFI. This is the most important prerequisite for the future of the

MFIs and
the success of MIS in them.




2.

Strategies with Information Technology: The organizing should elevate its view on Information
Technology to a strategic level. Information Technology should be woven in the organizational
operation and decision
-
making process in such a manner so that it becomes a core competency of
the organization.

3.

Value based approach: The MFIs should take a val
ue
-

based approach to MIS solution not a cost
or price approach. They should see the expenditure in Information Technology as an investment
and not expense.


4.

95% rule: Instead of trying to get or build a software which caters to the 100% needs of the MFI
they should take a software which will satisfy 95% of the needs for the simple reason that
organisations spend most of the money in getting that additional 5% functionally.

5.

Buy high quality software: The MFIs should desist from buying poor quality softwar
e as they may
ultimately lead to heavy loses in terms of data and time. Hence, it is advisable that MFIs should
buy only high quality and stable software solutions.

6.

Customization: The MFIs should try to manage as far as possible with the features provided

in the
software. They should customize only when absolutely necessary, as it is costly every time one
tries to modify the programme code.