Archive for the ‘PROJECT’ Category

Peer Grades

December 27, 2011 Leave a comment

Peer grades are to be sent until January,6. The ones who do not send will loose grades. Keep in mind that the grades will be kept private. The grading range is between 0-10. Attach brief comments related to your gradings for your group members.


Project Grading Criteria

December 27, 2011 Leave a comment

In general, you will be graded according to your design(%35), analysis(%25) and implementation(%20). You can organize your project and demo by checking the criteria given in ProjectGradingCriteria form.



Project System Designs Report Content

November 20, 2011 Leave a comment

Internal Documentation is a means for communicating ideas between different parts of a development team, especially during the design phase as well as for proper maintenance of a software system. Considering the fact that people responsible for maintenance might not be the same people who have designed and implemented the software, it should be self-explanatory and complete.  This means just about anything used during analysis and design such as reasoning and rationale of key design decisions, design procedures (e.g. top-down decomposition of the system and specific architectural style used), and UML diagrams should be part of this document. Proper commenting of source code, of course, is an essential part of internal documentation.

Again there is no single way to organize such a report, a sample follows:

  1. Introduction
    1.1 Purpose of the system
    1.2 Design goals
    1.3 Definitions, acronyms, and abbreviations
    1.4 References
    1.5 Overview
  2. Software architecture
    2.1 Overview
    2.2 Subsystem decomposition
    2.3 Hardware/software mapping
    2.4 Persistent data management
    2.5 Access control and security
    2.6 Boundary conditions
  3. Subsystem services
  4. Glossary

You are required to use CASE tools and UML during all phases of software development.

Source: Description

Categories: PROJECT

About Analysis Report

October 15, 2011 Leave a comment

Analysis Document of a project, also known as a Software Requirements Specification (SRS), is produced as a result of the analysis of the system to be developed. The requirementsprovided by the customer are analyzed carefully and this document is produced as a result of a thorough analysis of the system at hand. In a sense, this document is a contract between the developer (“you”) and the user/customer (“us” in this case).

Once you feel your analysis document is complete, you may begin your design. This phase is perhaps the most crucial of all and should be dedicated sufficient time. A project without aproper design might actually receive a failing grade even if its implementation is completely finished.

There can be many different ways in which to organize an Analysis document; the key point is being able to convey the model produced as a result of the analysis as clearly and completely as possible. One example organization for an object-oriented software system is as follows[1]:

1.    Introduction
2.    Overview
3.    Functional requirements
4.    Nonfunctional requirements
5.    System models
5.1.Use case model
5.2.Dynamic models
5.3.Object and class model
5.4.User interface – navigational paths and screen mock-ups
6.    Glossary

[1] Object-Oriented Software Engineering, Bernd Bruegge and Allen H. Dutoit, Prentice-Hall, 2000, ISBN: 0-13-489725-0.


Project Statement

October 6, 2011 Leave a comment

Draft of the project statement is provided below. There may be some changes in the coming days, so check the post frequently.

Electronic Document Management System

CS 319 Term Project

Project: Electronic Document Management System

A document is an information carrier between institutions. In the past, it was very difficult to ensure communication between institutions. The documents needed to be written by hand and each mistake meant to re-write document. Then, photocopying was introduced and cost of duplication of documents was reduced. In the 1980s, computersstarted to be used to prepare documents and this helped to handle errors and reuse old documents. In the late 1980’s, the fax was invented and became a popular document transfer method. Then, transfer of a document by the fax took less time than sending it by hand. Finally, the invention of the Internet was a significant step for the transfer of the documents.

In this project, you are expected to implement a document management system. The system facilitates the creation, editing, monitoring, storing, accessing, distributing of documents. This system also provides good facility to transfer process of documents inside the institution through departments or outside institutions electronically. The lifetime of the process starts with the creation of the document and terminates after the delivery of the document to whom it may concern.

Project Requirements:

  • There should be many institutions with different departments.
  • There should be different departments of the institutions.
  • Approved document shall be sent to departments of same institutions or departments of different institutions.
  • Document shall be prepared just text (i.e. multiline textbox), can have several attachments.
  • Sent and received documents shall be reachable but not editable. (Institution level)
  • Sent and received documents shall be searchable/viewable (institution level)
  • Every institution has different categories of employees and the employees have different roles in the document management system. These categories can be
  1. Author(eg. Secretary of Computer Engineering department of Bilkent University)
  2. Reviewer (eg. An instructor(s) of the department)
  3. Approver (eg.Chairman of the department)
  4. Reader(eg. An instructor from Electric-Electronic Engineering department of Bilkent University / Manager of an institution)

Permissions of roles are given below.

Roles Permission
Reader Read documents
Author Create and update documents
Reviewer Review the document
Send back the document to its author to edit
Send the document to the approver
Approver Review the document
Reject-Send back the document to Reviewer
Approve-Sendthe document to relevant authority
  • Employees of institutes need to login to the system.
  • Preparation of a document inside an institute requires some steps.Common steps in this process:
  1. Create/Edit: documents are produced by an Author who often begins by using a template or an existing document. Each section of the template is completed or deleted if not applicable.  Once a draft of the document is ready for reviewing, it is sent to a Reviewer to read and comment.
  2. Review: A Reviewer (or multiple Reviewers) gets documents from author and comments on the draft. In most cases, the draft version is sent back to the Author for rework.  The document may cycle many times between the Author(s) and Reviewer(s) before an acceptable version is completed. Once the document is ready, Reviewer send it to an Approver  for final review with his/her paraph-initial (paraf).
  3. Approve: The finalized version is sent to an Approver for a final review and authorization.  Approvers may deny approval, in effect rejecting the document from going further and send it back to the Reviewer for more rework. Once approved, it is numbered and sent to relevant authority(other department/institution) with the approver’s signature.
  4. Distribute: After sending the document, it is taken by document directorate. This unit may send it back to approver for changes  orsends the document to the Readers (employee) who are concerned with.

These steps are shown below

  • The states of the document should be kept.

Implementation Details

  • The system should be a desktop application implemented using Java Swing.
  • You shall not use database management systems like Oracle or MySQL. Your implementation should be saved in file/s. (Object to File Serialization can be used)