Tuesday, December 11, 2007

DFD of a Course Submission System

Assignment SSAD
DFD
[Course Submission System]

ID No : 0700165

========================================================================
Description of the system:

A computer department has decided to support the electronic submission of coursework by students. Each course sets its own coursework and has different deadlines. For example, one course has six pieces of work which students return at regular intervals while another has only one piece of coursework submitted at the end of term. Coursework and submission deadlines are defined within a set of profiles associated with course. As part of a design solution it has been decided that students will submit coursework by " attaching" an electronic submission form to a file containing the work. This form encodes the student name, the course, a coursework reference number and the date of submission. Submitted coursework needs to be assigned to a course tutor determined from an entry in a course profile database. The submission checks the submission against this profile, if incorrect an error is sent to the student. Once a tutor is assigned, the submission is checked against a deadline. A copy of late submission is added to a late submission store. Finally, the submitted work is stored in a coursework database, the submission recorded in the student records and a receipt of it is sent to the student. The handling of submission forms once it has been sent to the electronic systems is a central task within the system. You are responsible for the handling of electronic forms.




Sunday, December 9, 2007

SRS Document of the UOM Web Accessible Database System

Assignment 3
SRS Document
[UOM Web Accessible Database System]
ID No : 0700165
========================================================================

Software Requirements Specification


Version 1.0

9 December 2007


UOM Web Accessible Database


Arshad

========================================================================

Table of Contents

1.0. Purpose

1.1. Introduction
1.2. Scope
1.3. Glossary
1.4. References
1.5. Document overview

2.0. Overall description

2.1. System environment
2.2. Functional requirements definitions
2.3. Use cases
2.3.1. Use Case: Access UOM Home Page
2.4. Non-functional requirements

3.0. Requirement specifications

3.1. External interface specifications
3.2. Functional Requirements
3.2.1. Access UOM Home Page
3.2.2. Survey
3.3. Detailed non-functional requirements
3.4. System Evolution

4.0. Index

========================================================================

1.0. Introduction

1.1 Purpose.

This Software Requirements Specification provides a complete description of all the functions and specifications of the University of Mauritius (UOM) Web Accessible Database. The expected audience of this document is the Faculty of Engineering, including the department of Computer Science who will use this system and the developer. It will also serve as a reference for other students.

1.2. Scope

The University of Mauritius (UOM) Web Accessible Database [UOMWAD] is designed to run on the departmental server (CSE server) and to allow UOM students to fill out a survey form. The data will be held in an Access database on the departmental server.

1.3. Glossary

Term

Definition

UOM student

University of Mauritius students

BDE

Borland Database Engine

CI

Configuration Item

CSE

Computer Science & Engineering

Html

Hyper text markup language

IEEE

Institute of Electrical and Electronic Engineers

SCMP

Software Configuration Management Plan

SDD

Software Design Document

SEI

Software Engineering Institute

SQAP

Software Quality Assurance Plan

SRS

Software Requirements Specification

Survey

Form filled out and submitted by an UOM student.

Web Site

A place on the world wide web



1.4. References

[IEEE] The applicable IEEE standards are published in “IEEE Standards Collection,” 2001 edition.

[Bruade] The principal source of textbook material is “Software Engineering: An Object- Oriented Perspective” by Eric J. Bruade (Wiley 2001).

1.5. Document overview

The remainder of this document is two chapters, the first providing a full description of the project for the owners of CSE department. It lists all the functions performed by the system. The final chapter concerns details of each of the system functions and actions in full for the software developers’ assistance. These two sections are cross-referenced by topic; to increase understanding by both groups involved.

2.0. Overall description

The UOMWAD encompasses numerous files and information from the UOM Database, as well as files on the department server system. This system will be completely web-based, linking to UOMWAD and the remote web server from a standard web browser. An Internet connection is necessary to access the system.


2.1. System environment



The UOMWAD web site will be operated from the departmental server (CSE server). When an UOM student connects to the University Web Server, the University Web Server will pass the UOM student to the Departmental Server. The Departmental Server will then interact with the UOM Database through BDE, which allows the "Windows-type" program to transfer data to and from a database


2.2. Functional requirements definitions

Functional Requirements are those that refer to the functionality of the system, i.e, allow UOM students to fill out a survey form.


2.3. Use cases

The system will consist of CSE/UOM Home page.

It is used is to fill out a survey. The questions on the survey will be created by a designated faculty member. The survey will ask the UOM student questions concerning their degree, job experience, how well their education prepared them for their job, and what can the CSE department do to improve itself. This information will be retained on the CSE departmental server and an e-mail will be sent to the designated faculty member.

All pages will return the student to the UOM Home Page.


2.3.1. Use Case: Access CSE Home Page



Brief Description:
The Departmental Web Server is waiting on an UOM student to connect.

Initial step-by-step description:
For this use case to be initiated, the UOM student must be connected to the Internet and connected to the University Web Server.

1. The student connects to the University Web Server.
2. The student selects the CSE link on the UOM home page.
3. The University Web Server passes the student to the CSE Home Page.
[Reference SRS 3.2.1]


2.3.2. Use Case: UOM student Chooses Survey


Brief Description:
The UOM student chooses to fill out a survey.

Initial step-by-step description: For this use case to be initiated the UOM student must be connected to the Internet and is on the CSE Home Page.

1. The UOM student selects the “Fill out a survey” link.
2. The CSE Departmental Server provides the survey form.
3. The UOM student fills in the form.
4. The UOM student clicks submit.
5. The CSE Departmental Server retains information in the database & designated faculty member will be notified.
6. The CSE Departmental Server returns the student to the UOM Home Page.
[Reference SRS 3.2.2]


2.4. Non-functional requirements

There are requirements that are not functional in nature. Specifically, these are the constraints the system must work within.
The web site must be compatible with Netscape, Mozilla and Internet Explorer web browsers. This system will use the same type of Internet security presently being used by University of Mauritius.


3.0. Requirement specifications

3.1. External interface specifications
None

3.2. Functional Requirements

3.2.1. Access CSE Home Page

Use Case Name:

Access UOM Home Page

Priority

Essential

Trigger

Menu selection

Precondition

UOM student is connected to the Internet and is on the University Web Server (UOM Home page)

Basic Path

1. University Web Server sends the UOM student to the CSE Departmental Server.

2. The CSE Departmental Server presents the student with the CSE Home Page.

Alternate Path

N/A

Postcondition

The student is on the CSE Home Page

Exception Path

If there is a connection failure the CSE Departmental Server returns to the wait state

Other


Reference

SRS 2.3.1



3.2.2. Survey

Use Case Name:

Survey

Priority

Essential

Trigger

Selects

Precondition

The student is connected to the Internet and on the CSE Home Page

Basic Path

1. The CSE Departmental Server presents the student with a survey form.

2. The UOM student fills in the form and click submit

3. The CSE Departmental Server checks to see if all required fields are not empty.

4. If the required fields are not empty, the Departmental Server creates a new record in then Survey Table of the UOM Database.

5. If any of the required fields are empty, the CSE Departmental Server returns a message and returns the student back to the Survey form.

6. The CSE Departmental Server returns the student to the UOM Home Page at the end.

Alternate Path

N/A

Postcondition

The survey record is created in the Survey Table of the UOM Database.

Exception Path

1. If the connection is terminated before the form is submitted, the fields are all cleared and the CSE Departmental Server is returned to the wait state.

Other


Reference:

SRS 2.3.2


3.3. Detailed Non-Functional Requirements

Attribute Name

Attribute Type

Attribute Size

LastName*#

String

30

FirstName*#

String

30

MaidenName*#

String

30

Address1*#

String

50

Address2#

String

50

City*#

String

30

State*#

String

2

Zip*#

Int

6

Year*#

Int

4

AdditionalDegrees#

String

50

Spouse#

String

30

Children#

String

50

CurrentEmployment#

String

50

EmailAddress#

String

20

ReceiveEmails#^

Boolean

1

Password*#^

String

10

EntireRecordVisible*^

Boolean

1


Fields marked with an ‘*’ are required fields.
Fields marked with a ‘#’ can be visible or not visible and is determined by the UOM student. Fields marked with a ‘^’ are never visible to anyone other than the UOM student.

The questions that are used on the survey form will be initially created by a designated faculty member.
The questions will be stored in the Question Record of the Survey Table of the UOM Database. The answers to these questions will be stored in a record in an Answers record in the Survey Table of the UOM Database.

Hardware:
CSE Departmental Server & UOM Web Server

Operation System:
Window 98 or above

Internet Connection:
Existing telephone lines / LAN

Code Standard:
The web pages will be coded in html by using Front Page. The forms will be done in Active Server Pages (ASP 3.0).
The connection to the UOM Database will be done with Windows BDE.
Each page of the web site will be fully documented.

Performance:
The system should generate the records in the appropriate table of the
UOM Database 100% of the time

3.4. System Evolution

In the future this system will be updated to allow students from the Humanities Department to join the survey. A report generated by the system concerning the responses to the survey could be another addition to the UOMWAD in the future.




Monday, October 22, 2007

Architecturel Design of a Voice Browser System

Assignment 2
System Architectural Design
[Voice Browser System]
ID No : 0700165
==========================================================================
Description of the system

Voice Browser System - enable access to the web using spoken interaction

Two types of clients are illustrated: telephony and data networking. The fundamental telephony client is, of course, the telephone, either wireline or wireless. The handset telephone requires PSTN (Public Switched Telephone Network) interface, which can be either tip/ring, T1, or higher level, and may include hybrid echo cancellation to remove line echoes for ASR barge-in over audio output. A speakerphone will also require an acoustic echo canceller to remove room echoes. The data network interface will require only acoustic echo cancellation if used with an open microphone since there is no line echo on data networks. The IP interface is shown for illustration only. Other data transport mechanisms can be used as well.

Once data has passed the client interface, it can be processed in a similar manner. One minor difference may be speech endpointing. Endpointing will most likely be performed either in the telephony interface or at the front-end of the ASR processor for speech input from telephony interface. For speech via the IP interface endpointing can be performed at the client as well as the ASR front-end. The choice of where endpointing occurs is coupled with the choice for echo cancellation.

It is currently not clear how non-speech data will be handled at the telephony interface. This can include inputs such as pointing device input from a "smart phone," address books and other client resident file data, and eventually even data like video. These smart telephone devices are now on the drawing boards of many suppliers. Some this traffic can be handled by WAP/WML, but there are still open issues with regards to multi-modality. Therefore voice markup language specifications should provide means for extending the language features.

Data from the ASR/DTMF (etc.) recognizer must be in a format compatible with the NL (Natural Language) interpreter. Typically this would be text, but might include non-textual components for pointing device input, in which case pointing coordinates can be associated with text and/or semantic tags. If the recognizer has detected valid input while output is still being presented, the recognizer can signal the presentation component to stop output. Barge-in may not be desirable for certain types of multi-media output, and should primarily be considered important for interrupting speech output. In some cases it may also be undesirable to interrupt speech output, such as in the processing of commands to change speaking volume or rate.

The recognizer can produce multiple outputs and associated confidence scores. The NL interpreter can also produce multiple interpretations. Interpreted NL output is coordinated with other modes of input that may require interpretation in the current NL context or may alter or augment the interpretation of the NL input. It is the responsibility of the multi-media integration module to produce possibly multiple coordinated joint interpretations of the multi-modal input and present these to the dialog manager. Context information can also be shared with the dialog manager to further refine the interpretation, including resolution of anaphora and implied expressions. The dialog manager is responsible for the final selection of best interpretation.

The dialog manager is also responsible for responding to the input statement. This responsibility can include resolving ambiguity, issuing instructions and/or queries to the task manager, collecting output from the task manager, formation of a natural language expression or visual presentation of the task manager output, and coordination of recognizer context.

The task manager is primarily an Application Program Interface (API), but can also include pragmatic and application specific reasoning. The task manager can be an agent, or proxy, can possess state, and can communicate with other agents or proxies for services. The primary application interface for the task manager is expected to be web servers, but can be other API's as well.

Finally, the presentation manager, or output media "renderer," has responsibility for formatting multi-media output in a coordinated manner. The presentation manager should be aware of the client device capabilities.





Sunday, October 7, 2007

Different types of Software Application

Assignment 1
Software Application

ID No : 0700165
==================================================================================== Software can be split into two main types - system software and application software. System software is any software required to support the production or execution of application programs but which is not specific to any particular application.

Examples of system software would include the operating system, compilers, editors and sorting programs.

Examples of application programs would include an accounts package or a CAD program. Other broad classes of application software include real-time software, business software, scientific and engineering software, embedded software, personal computer software and artificial intelligence software.


System Software

System software refers to the files and programs that make up your computer's operating system. System files include libraries of functions, system services, drivers for printers and other hardware, system preferences, and other configuration files. The programs that are part of the system software include assemblers, compilers, file management tools, system utilities, and debuggers. The system software is installed on your computer when you install your operating system. You can update the software by running programs such as "Windows Update" for Windows or "Software Update" for Mac OS X. Unlike application programs, however, system software is not meant to be run by the end user. For example, while you might use your Web browser every day, you probably don't have much use for an assembler program (unless, of course, you are a computer programmer).

Since system software runs at the most basic level of your computer, it is called "low-level" software. It generates the user interface and allows the operating system to interact with the hardware. Fortunately, you don't have to worry about what the system software is doing since it just runs in the background. It's nice to think you are working at a "high-level" anyway.


Real time Software



Predator MDC is a real time software.

Click here to read more












A real time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced.

In short, any situation where the time at which a result is produced is as important as the result itself. Producing the right answer too late is as bad as producing the wrong answer or no answer at all! Avionics, robotics and process control are all examples of real-time software applications. At present real-time software is difficult, and thus expensive, to produce. Programmers are forced to work with low-level machine languages because conventional programming aids hinder, rather than help, the ability to guarantee timing predictability. An optimizing compiler, for instance, may rearrange the object code it generates to improve performance.

However this makes it difficult for the programmer to accurately predict the timing behavior of a program from its source code. Also real-time systems must undergo an unusually long testing phase to increase confidence in their timing behavior. Yet even this is not always sufficient because the system may not have exactly the same real-time behavior under test conditions as it does `in the field'.


Business Software



Officenet Workplace™ is the complete IT solution for any busy office

Click here to read more













Business software is generally any software program that helps a business increase productivity or measure their productivity. The term covers a large variation of uses within the business environment, and can be categorized by using a small, medium and large matrix:
The small business market generally consists of home accounting software, and office suites such as Microsoft Office.

The medium size has a broader range of software applications, ranging from accounting, groupware, customer relationship management, human resources software, loan origination software, shopping cart software, field service software, and other productivity enhancing applications.

The last segment covers enterprise level software applications, such as those in the fields of enterprise resource planning, enterprise content management, business process management and product lifecycle management. These applications are extensive in scope, and often come with modules that either add native functions, or incorporate the functionality of third-party software programs. Now, technologies that have previously only existed in peer-to-peer software applications, like Kazaa and Napster, are starting to feature within business applications.


Scientific Software


The ADAM Interactive Anatomy (AIA4) software provides visual human anatomy capabilities.

Click Here to read more











Scientific software is powerful specialized software that scientists and engineers develop allowing users to calculate very complex expressions in an analytic form; Behavioral and social sciences (such as psychology, sociology, psychiatry, criminal science, family studies, political science, developmental research, anthropology, or social work) Medical research ,Education (in administration, test analysis, counseling) ,Business research (marketing, management, economics, organization) and Environmental science.


Embedded Software






Click here
to read more







An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions. It is usually embedded as part of a complete device including hardware and mechanical parts.Its principal role is not the transformation of data, but rather the interaction with the physical world. It executes on machines that are not, first and foremost, computers. They are cars, airplanes, telephones, audio equipment, robots, appliances, toys, security systems, pacemakers, heart monitors, weapons, television sets, printers, scanners, climate control systems, manufacturing systems, and so on.


AI Software














Corneal Mapping of the eye using AI Software.

Click here to read more.


Artificial Intelligence Software can be thought as a 'human brain machine' since the particular AI software can process the simulation of a human brain. These processes include learning (the acquisition of information and rules for using the information), reasoning (using the rules to reach approximate or definite conclusions), and self-correction. Particular applications of AI include expert systems, speech recognition, and image recognition.


Web Application




This amazing software is a web application.

Click here to read more













Web application is an application that is accessed through web over a network such as the internet or an intranet. It is really important to note that the ability to update and maintain Web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity.Webmail, online retail sales, online auctions, discussions & Weblogs are common examples.