NANYANG TECHNOLOGICAL UNNIVERSITY

School of Electrical and Electronic Engineering

Information Communication Institute of Singapore
Nanyang Avenue
Singapore 639798

Communication Software Development and Project Management

(E6733)

Student Guidelines

June 2004
 Student Guidelines
for
Communication Software Development and Project Management (E6733)

1: INTRODUCTION

All MSc (Communication Software & Networks) students are required to undertake a software
development project (E6733) or a research dissertation project. This document provides the guideline
for the software development project.

Communication Software Development and Project Management (E6733) comprises of the

following components:

1) Project Management Training

2) Software Development Project: The project is further structured as follows:

i) Independent Study
ii) Product, and Technical Process and Management Practice

Each software development project will be supervised by two or more staffs. It will be carried out by
a group of 4-6 students.

2: PRJECT SCOPE, PROPOSAL, SELECTION AND DURATION

2.1: Project Scope

All proposed projects should cover the complete software development lifecycle instrumented with
proper project management practice. They should also develop software based on the latest software
and networking technology. Each student is expected to spend a minimum of 260 hours to complete
the project.

2.2: Project Proposal and Selection

All projects are proposed by staffs through submitting project proposals according to the format
shown in the attached sample. Students select their projects from the list of proposed projects. A
copy of the Project Selection Form for students to choose their project is also attached.

2.3: Project Duration

Full-time students start their projects in the third week of Semester 1. They complete their projects in
week 14 of Semester 2.

Part-time students start their projects in week 18 of Semester 1 in Year 1. They complete their
projects in week 14 of Semester 2 in Year 2.

2
3: PROJECT FRAMEWORK

3.1: Project Management Training

At the beginning of project lifecycle, all the students are required to successfully complete 12-hour
project management training. The training will be conducted in four sessions with three hours per
session.

The objectives of the project training are as follows:

1) To impart to students a comprehensive knowledge on project management.

2) To impart to students knowledge on software outsourcing from both
management and technical aspects.

Upon completion of the training, the students will sit for a paper.

3.2: Independent Study

Each student in a project will be assigned with an independent study task right at the beginning of the
project. The task should aim to make significant contribution to the product to be developed in the
project. It should aims on problems that already have methods to solve them but none of the team
members know these methods. It should not be a research problem.

There are many kinds of independent study can be configured in a software development project.
Some examples are as follows:

1) Study a software development tool that is to be used in the project, teach the
team members, and provide technical support for the use throughout the whole project
lifecycle.
2) Study an existing prototype or open-source software that is to be used as a
base or component in the project, teach the team members, and provide the related
technical support throughout the whole project lifecycle.

The task should be completed independently before the commencement of Semester 2. Upon
completion, a 10-page report should be prepared by the student to report the result.

3.3: Product, Technical Process and Management Practice

The product delivered from the project should be assessed with respect to the objective of the
project. At the end of Semester 1, the objective of the project should be freeze.

Both the technical process and project management practice should also be assessed.

3
4: TECHNICAL PROCESS

All projects will apply the industry standard Object-Oriented software development methodology,
Unified Modeling Process, to develop a software system from its requirements. The main
characteristics of the project approach are:

1) Object-Oriented (OO) modeling: Though OO provides a better structure for

organizing software, quality of the resulting software still depends very much on good OO
modeling.
2) Proper use of Unified Modeling Language (UML): The appropriate and correct use of
UML concepts and notations.
3) Use-Case Driven: The project starts with defining requirements in terms of use-cases.
Classes are identified from the realization of use-cases. Systems are tested in terms of use-
cases.
4) Architecture Centric: The design and development of project should base on proven
architecture for similar systems.
5) Iterative and Incremental: All development should be carried out in an incremental
and iterative manner. The number of iterations that are required for the development of a
complete system depends on the complexity of the requirements.

The main processes are as follows:

1) Survey of Existing Products: At the beginning, all projects should do some survey of
existing products. These products will serve as examples to target systems. It may also help
the project team in judging the standard required.
2) Technical Feasibility Study: If the project team is not familiar with the use of some
technology, some technical feasibility and possibly prototype implementation should be
carried out on a small scale before embarking on the full-scale.
3) Requirements Capture: Requirements are defined in terms of use-cases in a use-case
model. The output of this process is a requirements specification. A suggested format of
requirement specification is attached.
4) Analysis: Use-cases are realized conceptually and analyzed. Classes are identified and
discovered from the realization. The output of this process is an analysis model. A suggested
format of analysis model is attached.
5) Design: The realization of use-cases is further refined to take implementation aspects into
considerations. The object model is further refined to reflect the realization. The output of
this process is a design specification. A suggested format of design specification is attached.
6) Implementation: The design specified in the design specification is implemented using the
target technology and programming languages.
7) Testing: The system is tested in terms of use-cases. A set of test cases and its expected
result should be documented and submitted as a project deliverable.

4
5: PRJECT MANAGEMENT PRACTICE

Concise and proper project management practice should be carried out throughout the whole project
lifecycle.

A concise project plan with the following items should be prepared and submitted to the lab
technician by the end of the fourth week after the project commences:

1) Project Objective
2) Project Scope
3) A detailed Gantt chart to show the plan for all the activities
4) A concise description of an independent study component for each team
member

The project plan should be freeze after the submission of documentations for the first evaluation.
Before this, a revised plan should be submitted if there is any change.

As part of general guideline on project review, a project review meeting should be conducted on
weekly basis for full-time software projects. And, a project review meeting should be conducted on
every two weeks for part-time software projects. The Gantt chart in the project plan should be
updated and reviewed in each project review meeting to show the progress of the project. By the end
first week after a project commences, each project should submits a plan for all the review meetings
throughout the project lifecycle to the lab technician. The meeting should hold on a fixed day and
time in the week (e.g., Saturday, Wednesday). A minute for the meeting that is held in the previous
week and the associated Gantt chart should be submitted to the lab technician by the following
Tuesday.

A statistics will be compiled by the software project coordinator to show the timeliness of project
management documents submission. The statistics will be submitted to Head ICIS on quarterly basis.

5
6: PROJECT DELIVERABLES

This section summarizes all the project deliverables. These deliverables are to be submitted
according to the project milestones that will be discussed in the next section.

6.1: TECHNICAL DELIVERABLES

The main project technical deliverables are as follows:

1) Requirements Specification: a Use-Case Model (a sample format is attached).

2) Analysis Model: To show the realization of all use-cases conceptually including class
diagrams (a sample format is attached).
3) Design Specification: To specify the design for the realization of all use-cases
including class diagrams (a sample format is attached).
Implementation Model: Code and System
4) User Manual: including Installation Guide (a sample format is attached).
5) Test Document: A document to show the testing of the system. This document should
include a set of test cases with expected result. It should also show the actual results produced
by the system.

Each final technical deliverable should be bound in a separate volume.

6.2: PROJECT MANAGEMENT DOCUMENT

For each project, the following project management documents are to be prepared and submitted to
the lab technician according to the schedule defined:

1) A project plan as described in Section 5

2) A minute for each review meeting
3) A Gantt chart to show the project progress on each review meeting

7: PROJECT SIGN-OFF

Upon completion, each project must be formally sign-off. All the project assessments will be
considered as invalid if the project has not been formally signed off. It is the project team and main
supervisor responsibility to ensure that the project is signed off formally upon completion. The
project sign-off procedure is as follows:

1) Submit a copy of CD that stores your final system, source codes, and documentation to a
technician.
2) Submit a hard-bound final copy of all the documentations to the technician.
3) The technician will follow your user manual to install the system and run the test cases.
4) If 3) can be carried out successfully, the technician will sign on the hardcopy of the
documentations.
5) The project team will submit the set of documentations signed by the technician to the main
supervisor.
6) The main supervisor will do a final check to confirm that all the required amendments have
been made and the documentations are acceptable. If they are confirmed acceptable, he/she
will sign on the documentations.

6
8: PROJECT MILESTONES

The main major project milestones for full-time and part-time students are listed in Table 1 and 2
respectively. The schedule for project management document submission is listed in Table 3.

Table 1: Major Milestones for Full-Time Students

Major Milestones Deadlines Submit to

Project Selection Yr 1, Semester 1, Week Nil
2
Project Assignment and Kick-off Yr 1, Semester 1, Week nil
3
Submission of Requirements Yr 1, Semester 1, Week Each project
Specification and Analysis Model for 14 supervisor through
First Assessment the main project
supervisor
Demo of Initial Prototype for Second Yr 1, Semester 2, Week nil
Evaluation 2
Submission of Independent Study Yr 1, Semester 2, Week The main project
Report for Concluding the Evaluation 2 super
of Independent Study visor
Submission of Final Documentations Yr 1, Semester 2, Week Each project
(Final Req Spec, Design Spec, User 11 super
Manual, Test Document) for Final visor
Evaluation throu
gh
the
main
proje
ct
super
visor
Project Presentation and Demo for Yr 1, Semester 2, Week nil
Final Evaluation 12
Sign-Off Yr 1, Semester 2, Week nil
14

7
Table 2: Major Milestones for Part-Time Students

Major Milestones Deadlines Submit to

Project Selection Yr 1, Semester 1, Week nil
12
Project Assignment and Kick-off Yr 1, Semester 1, Week nil
18
Submission of Requirements Yr 1, Semester 2, Week Each project
Specification and Analysis Model for 20 supervisor through
Interim Assessment the main project
supervisor
Demo of Initial Prototype for Second Yr 2, Semester 2, Week nil
Evaluation 8
Submission of Independent Study Yr 2, Semester 2, Week The main project
Report for Concluding the Evaluation 8 supervi
of Independent Study sor
Submission of Final Documentations Yr 2, Semester 2, Week Each project
(Final Req Spec, Design Spec, User 11 supervi
Manual, Test Document) for Final sor
Evaluation through
the
main
project
supervi
sor
Project Presentation for Final Yr 2, Semester 2, Week nil
Evaluation 12
Sign-Off Yr 2, Semester 2, Week nil
14

Table 3: Schedule for Project Management Document Submission

Major Milestones Deadlines Submit to

Project Plan End of the 4th week in Lab Technician
the project lifecycle
A schedule of project review meeting End of the 1st week in Lab Technician
the project lifecycle
A minute of each review meeting and Tuesday of the following Lab Technician
a progress report presented in a Gantt week
chart

8
 Software Project Proposal – A Sample

Project Id: F02-A

Project Title: A Seamless Software Design and Development Environment

1) Supervisors: Dr A, Dr Y
2) Project Description:

Most object-oriented (OO) software development methodologies adopt OO analysis that realize
use-cases in terms of objects and their interactions at the early stage of requirements analysis.
They force analysts to make decisions on these designs prematurely through trial and error. This
has become a major problem in OO software development today.

This project is to develop a graphical CASE tool to implement an approach that has been
developed to address the above-mentioned problem. In the proposed approach, use-cases are
realized in DF nets instead of collaboration and sequence diagrams. The tool will be developed in
Java through extending an existing tool developed from a research project. The graphical
interface for specifying DF nets has already been implemented in the existing tool. The
objectives of this project are as follows:

o Develop a graphical user interface to accept design decisions

o Develop a transformation sub-system to transform DF nets into OO design and
implementation
o Develop a transformation sub-system to transform DF nets into component-based
design and implementation
o Develop a sub-system to support OO functional reuse

Students who choose this project are expected to be proficient on Java. Knowledge and
experience on component-based software development will be an added advantage. Knowledge
and experience on developing graphical tool will also be relevant.

3) Hardware and software needed: Java, Visual C++, EJB, COM

5) Special skill needed: Proficient in Java and good knowledge on Visual C++ and component-
based software development.

9
 School of Electrical & Electronic Engineering
Information Communication Institute of Singapore
Block S2, Nanyang Avenue, Singapore 639798 Tel: (65) 790 6028 Fax: (65) 792 2971

MSc in Communication Software and Networks

Software Project Selection Form

Instruction:
1. Form a project group of SIX members (If you cannot form a group, please submit your form on
individual basis and we will find a group for you. However, groups will have a higher priority in
getting their choices).
2. Choose Two (2) projects in descending order of your preference.
3. Return the completed form in the Drop-Box provided near the printer in the Practicum Lab of S2-
B3a-01
Project Team:
Team Member Academic qualification (e.g., BEng in
EE, BSc in CS, etc.) and relevant
Name Matriculation Signature experience
Number

Project Selected:
1st Choice Project Title and Id:

2nd Choice Project Title and Id:

10
 Requirements Specification – Suggested Format

A requirements specification should include the following sections.

1. Introduction

{Please include the following:

1. context of your project
2. objective of the project
3. mention that Unified Software Development Process is used
4. organization of the requirement model (the documentation)}

2. Architecture Description (Overview)

{Please include the following:

1. overview of the requirements
2. common non-functional requirements
3. highlight critical use cases (with reference to the use case description in the use-case
model) and any special treatment needed
4. Prioritization of use cases for the next workflow}

3. Use-Case Model

3.1. Overview

{Please draw use case diagrams (ellipses) to show all the use cases and actors and their
interactions}

3.2. Actors

{Please list and describe each actor}

3.3. Real Use Cases

{Please list and describe each real use case. To avoid the repetition in describing similar use
cases, you may construct some abstract, inclusion or extension use cases in Section 3.4 and
use them to describe the use cases here}

{The description of each use should include:

Precondition
Flow of events
Basic Path
Alternative Paths
Postcondition
Special Requirement (if any)
Specification of use interface (if any)}

3.4. Supporting Use Cases

11
 {Please list and describe each abstract, extension and inclusion use cases here}

4. Conclusion

{Please give a summary on what the project team has achieved in Requirements Capture. You
should also highlight the foreseeable difficulties (if any) that you may encounter in the process of
completing the project.}

12
 Analysis Model – Suggested Format

An analysis model should include the following sections.

1. Introduction

{Please include the following:

1. context of your project
2. objective of the project
3. mention that Unified Software Development Process is used
4. organization of the analysis model (the documentation)
5. overview of the requirement: Please draw use case diagrams (ellipses) to show all the use
cases and actors
6. give an overview of the architecture by stating the analysis and service packages with
concise descriptions}

2. Use-Case Realization--Analysis

2.1. Real Use-Case Realization--Analysis

{For each use case, please provide the following:

1. collaboration diagrams
2. a textual flow of events in terms of analysis objects
3. special requirement: all the non-functional requirements for the realization of the
use case}

2.2. Supporting Use-Case Realization--Analysis

{Please describe each abstract, extension and inclusion use cases use case as at Section 3.2
here}

3. Analysis Class

3.1. Overview

{Please include the list of classes with a concise description on what each class represents}

3.2. Class Diagram

{Please draw the overall class diagrams in this sections. The stereotype and the attributes of each
class should be shown in the diagram. The relationships between classes should also be shown in
the diagram}

3.3. Class Responsibility and Special Requirement

{For each class, please state its responsibilities and special requirements in this section}

4. Architecture Description

{Please include the following:

13
1. analysis packages (including service package): here you should show the partition of use cases
and classes for each package clearly.
2. common non-functional requirements
3. highlight the key classes (with reference to the class specification) and any special
treatment needed: just state the name and the reference, but do not repeat the class
specification here
4. highlight the use cases realization—analysis that realizes some important and critical
functionality: just state the name and the reference, but do not repeat the specification of use
case realization—analysis here.
5. Prioritization of use cases for the next workflow}

5. Conclusion

{Please give a summary on what the project team has achieved in Analysis. You should also
highlight the foreseeable difficulties (if any) that you may encounter in the process of completing
the project.}

14
 Design Specification --- Suggested Format

An analysis model should include the following sections.

1. Introduction

{Please include the following:

1. context of your project
2. objective of the project
3. mention that Unified Software Development Process is used
4. organization of the Design model (the documentation)
5. overview of the requirement: Please draw use case diagrams (ellipses) to show all the use
cases and actors
6. give an overview of the architecture of the whole design by stating the design subsystems
with brief descriptions and UML diagrams to show their structure and interfaces}

2. Architecture Description

{Please include the following:

1. Design subsystem (including service package): here you should show the partition of
use cases and classes for each subsystem, clearly; interface and dependencies between
subsystems should be shown in appropriate UML diagrams.
2. common non-functional requirements
3. highlight the key classes (with reference to the class specification) and any special
treatment needed: just state the name and the reference, but do not repeat the class
specification here
4. Show subsystems’ interfaces, the interfaces provided by the subsystem define operations
that are accessible from “outside” of the subsystem.
5. Highlight the use cases realization—Design that realizes some important and critical
functionality: just state the name and the reference, but do not repeat the specification of use
case realization—Design here.
6. Specify deployment models, list nodes and network configurations, distributing
subsystems among the nodes. State the system and programming platforms.
7. Prioritization of use cases for the implementation}

3. Use-Case Realization--Design

3.1. Real Use-Case Realization--Design

{For each use case, please provide the following:

1. A textual flow of events in terms of Design objects
2. Implementation requirements: textual description that collects requirements, such
as nonfunctional requirements, on a use-case realization.
3. Sequence diagrams for complex use cases}

3.2. Supporting Use-Case Realization--Design

{Please describe each abstract, extension and inclusion use cases use case as at Section 3.1
here}

15
4. Design Class

4.1. Overview

{Please include the list of classes with a concise description on what each class represents}

4.2. Class Diagram

{Please draw the overall class diagrams in this section. The stereotype of each class should be
shown in the diagram. The attributes (with types) and operations (with signatures) should be
shown in the class diagrams. However, for classes that will be implemented in databases, the
operations should be excluded from the class diagrams. The relationships between classes should
also be shown in the diagrams}

4.3. Overview of Design Class and its Special Requirements

{For each class, please gives a brief description of its responsibilities, its attributes, its operations
and its special requirements; for each relationship, please also give a brief description.}

4.4. Method Specification

{For each complex operation, please specify concisely a method to implement the operation.}

5. Database Design

{Please show the detailed database schema for all the databases that will be implemented in the
project}

6. Conclusion

{Please give a summary on what the project team has achieved in Design. You should also
highlight the foreseeable difficulties (if any) that you may encounter in the process of
implementing the project.}

16
 User Manual – Suggested Format

Each project must prepare a well written and easy to read and understand User Manual that includes
the following sections.

1. Introduction

{Please include the following:

1. The hardware and system software requirement
2. An overview of the system functionality
3. Organization of user manual}

2. The System

{Please include the following:

1. Subsystems in your system
2. Databases (if any)
3. Use cases in each subsystem
4. The interfaces between the subsystems }

3. Installing the System

{Please include the following:

1) Installation procedure (environment setup, database setup, etc.)
2) Frequently encountered problem and possible solutions}

4. Using the System

{Please structures this chapter by subsystem and describes the use of a subsystem by describing the
use of each use-case in the subsystem. You may further divide this chapter by having one chapter for
one subsystem. Within a subsystem, you may further classify the use-cases according to their
functional need (e.g., system administrator role and other user role). The following should be
included in the description for a use-case:

1) The purpose and the context (when the use case is used) of the use-case
2) Step by step procedure on the operating of the use-case
3) Use interface format and layout for the use-case
4) Errors that may result in the operating of the use-case and the associated error
messages
5) Documents and reports generated with format included}

17
5. Wrapping Up

{You should mention the limitation of your system (if any) and give suggestion on the next step}

18