Project Plan And Srs Final

Business Plan &
SRS Document

11/9/2007
Ho Chi Minh National University – International University
Instructor: Phan Viet Hoang

Group 6

November 9th , 2007
Date
Version 1.0
Status Baseline
Author Team TiHonMum Mim
Reviewer Team TiHonMum Mim
Documenter Nguyen Duc Quan

Team member Signature

Nguyen Duc Quan

Le Vu Hoang

Tran Minh Phung

Phan Duy Tan

Huynh Da Thuc

Business Plan & SRS Document

Table of Contents
1. STATEMENT OF WORK.................................................................................................................5

2. RESOURCE LIST............................................................................................................................8

2.1 Human ................................................................................................................................8

2.2 Software .............................................................................................................................8

2.3 Hardware ............................................................................................................................8

3. ESTIMATION ...............................................................................................................................9

3.1 Huynh Da Thuc estimation ...................................................................................................9

3.2 Phan Duy Tan estimation....................................................................................................12

3.3 Tran Minh Phung estimation ..............................................................................................15

3.4 Nguyen Duc Quan estimation .............................................................................................18

3.5 Le Vu Hoang estimation .....................................................................................................21

4. SCHEDULE.................................................................................................................................24

4.1 Task list .............................................................................................................................24

4.2 Gantt chart (reference) ......................................................................................................26

5. RISK PLAN .................................................................................................................................27

6. DISCUSSION SUMMARY .............................................................................................................29

6.1 Project background............................................................................................................29

6.1.1 Purpose of project ......................................................................................................29
6.1.2 Scope of project .........................................................................................................30
6.2 Perspectives ......................................................................................................................32

6.2.1 Who will use the system?............................................................................................32
6.2.2 Who can provide input about the system? ...................................................................32
6.3 Project objectives ..............................................................................................................33

6.3.1 Know business rules....................................................................................................33
6.3.2 System information and/or diagrams ...........................................................................33

2

6.3.3 Assumptions and dependencies ..................................................................................35
6.3.4 Design and implementation constraint ........................................................................35
6.4 Risks..................................................................................................................................35

6.5 Known future enhancements..............................................................................................36

6.6 References ........................................................................................................................36

6.7 Open, unresolved, or TBD issues.........................................................................................36

7. SOFTWARE REQUIREMENT SPECIFICATION .................................................................................37

7.1 USE CASE SPECIFICATION ...................................................................................................37

7.1.1 Log in and Log out ......................................................................................................37
7.1.2 Manage Department Information ................................................................................39
7.1.3 Manage Lecturer Information......................................................................................41
7.1.4 Manage Student Information ......................................................................................44
7.1.5 Manage Course Offering .............................................................................................47
7.1.6 Manage Financial Activities .........................................................................................50
7.1.7 View Academic History ...............................................................................................52
7.1.8 Register Course ..........................................................................................................53
Appendix ..................................................................................................................................55
7.2 FUNCTIONAL REQUIREMENT ..............................................................................................57

7.3 NON-FUNCTIONAL REQUIREMENT ......................................................................................61

7.3.1 Performance: .............................................................................................................61
7.3.2 Reliability: ..................................................................................................................61
7.3.3 Availability: ................................................................................................................61
7.3.4 Efficiency: ..................................................................................................................61
7.3.5 Supportability:............................................................................................................61
7.3.6 Integrity: ....................................................................................................................61
7.3.7 Portability: .................................................................................................................61
7.3.8 Flexibility:...................................................................................................................62
8. INSPECTION REPORT..................................................................................................................63

9. GLOSSARY.................................................................................................................................63

3

9.1 Introduction ......................................................................................................................63

9.2 Definitions.........................................................................................................................64

9.2.1 OURS .........................................................................................................................64
9.2.2 Academic staff............................................................................................................64
9.2.3 Finance staff...............................................................................................................64
9.2.4 Department ...............................................................................................................64
9.2.5 Faculty.......................................................................................................................64
9.2.6 Curriculum .................................................................................................................64
9.2.7 Subject.......................................................................................................................64
9.2.8 Course Offering ..........................................................................................................64
9.2.9 Prerequisite ...............................................................................................................64
9.2.10 Course Catalog ...........................................................................................................65
9.2.11 Lecturer .....................................................................................................................65
9.2.12 Student......................................................................................................................65
9.2.13 Student priority ..........................................................................................................65
9.2.14 Discount rate..............................................................................................................65
9.2.15 Grade.........................................................................................................................65
9.2.16 Schedule ....................................................................................................................65
9.2.17 Tuition fee..................................................................................................................65
9.2.18 Credit.........................................................................................................................65
9.2.19 Academic duration .....................................................................................................65
9.2.20 Academic year............................................................................................................65

4

1. STATEMENT OF WORK
As the head of information systems for International University, our team is tasked with
developing a new Online Course Registration System.
The system will allow students to access the system during registration time to register
for courses, add or drop the registered courses, check tuition fee, and review their
academic history.
The academic affair staffs will use the system as a mean to manage information of
departments, faculties, students and offering courses.
The system also supports financial office staffs in monitoring financial activities.
The features of the systems can be summarized as the following table:

Group of users Features OURS provides
All Users Login
Manage Department
Information
Manage Lecturer Information
Academic Affair Staffs Manage Department
Information
Manage Student Information
Manage Courses Offering
Financial Office Staffs View Tuition Fee
View Academic History
Students
Register for courses

Our team is going to develop the system using Rational Unified Process with use-case driven. It
includes four phases (inception, elaboration, construction, and transition). And in each phase,
we will go through 6 workflows only (Management, Requirement, Analysis, Design,
Implementation, and Testing). In fact, all 6 workflows will be done iteratively in each phase.
However, attention level of ours team on each workflow in different phases is different. In
particular,

Inception: It can be referred as Initial phase. In this phase we will review the initial system
request from customer, do feasibility study, define the vision and scope of the new system, and
the initial project plan.

Elaboration: It can be referred as planning & requirement phase. In this phase we will pay
attention on detail plan which includes risk plan, estimation, and detail schedule. We also
capture & analyze most of requirements to define the system and analyze its behaviors.

5

Construction: It can be referred as executing, monitoring, and controlling phase which includes
3 main parts: system design, system implementation, and testing.

Transition: It can be referred as closing phase. In this phase, we will complete and improve the
system, and performance acceptance test to prepare for delivering the system to the
stakeholders.

Inception Elaboration Construction Transition

In order to complete the system development, our team will complete the vision and scope
document, project plan and 6 primary development models which are key products of each
phase.

[Use-case driven]
Design
Model
Test
Use case Analysis Implementation
Model
Model Model Model
Deployment
Model

Vision and Scope document: It provides a vision of current problem and solution for the
problem. It also defines what will be developed and what will not be developed. It is done in
Inception phase.

Project plan: It is a business plan. It includes statements of works, project estimation, schedule,
and risk plan. It is also done in Inception phase.

Use case model: It is a group of use-case package, which includes one or some related use-
cases. And each use case will contain related users’ needs, goals, tasks, processes…, and
resources involved to it together. It is created after users and stakeholders’ requirements are
captured by business analysts. The most important document included in use case model is use-
cases specification document. Use-case model will be done in Inception & Elaboration phases.

6

Analysis model: It contains use-cases and theirs realization which includes domain study,
analysis classes and objects, interactions and behaviors of the system. It also defines the design
constraints, test plan and test cases for the system. Analysis model is mainly done in
Elaboration phase.

Design model: It includes system design specifications that define the system architecture and
detail design of components, database, graphical user interface, and the constraints for
implementation. Design model is done in Construction phase.

Deployment model: It defines how we can deploy the system so that it can run on server(s).
However, we intent to develop the system running on one server only, not distributed on many
server. Therefore, we will not pay much attention on deployment model. This model will be
done in Construction phase.

Implementation model: It defines the way we transfer from logical system architecture into
physical system architecture; test components (unit testing) and integrate them together in
order to form a unique system that satisfies users and stakeholders’ needs.

Test model: It includes many checklists and test cases that are planned and designed in
previous phases. It also requires all defects or errors to be recorded in defects and errors
reports. It is done in Construction phase.

The detail of each workflows and models will be presented in detail schedule, and the plan for
each phase.

Development team will use web-base and J2EE technologies to develop the system.

7

2. RESOURCE LIST

2.1 Human
Team member Main roles Responsibilities
Tran Minh Phung Tester, Integrator Integrate, test components, builds, and system
Le Vu Hoang System Designer, Design components, system and implement
Coder components
Huynh Da Thuc Tester, UI Designer Design graphical user interface, and test
components, builds, and system
Phan Duy Tan System Analyst, Coder Analyze system and implement front end of the
system
Nguyen Duc Quan Team leader, Business Monitor, control the project; analyze
Analyst, Documenter requirements and system behaviors; and do
documentation

2.2 Software
Documentation tool Microsoft word 2007
Scheduling tool Microsoft project 2007
IDE Netbean 6.0
Web Server Glassfish server 2.0
Photoshop CS2
Design tool
Microsoft Express Web Designer
JDK JDK 6.0
DBMS MySQL 5.0
Browser Internet Explorer 6.0, 7.0
Firefox, Opera
Operating system Windows XP, Vista, Linux

2.3 Hardware
Client 3 laptops
2 desktops
Server Reuse one 24/7 available desktop to simulate the server for testing
and deployment

8

3. ESTIMATION

3.1 Huynh Da Thuc estimation
Name : Huynh Da Thuc Date: 11/09/2007 Estimation form ///
Goal statement: To estimate the time to develop prototype for customer A and B Unit: days
Category x goal tasks x quality tasks waiting time project overhead
No. Task Est Del1 Del2 Del3 Del4 Total Assumption
Initial
1 Write team introduction 3 1 4
The system request is quite complex than initial
2 Review system request 4 2 1 -4 3 review
The key user and stakeholder varies and
3 Identify U ser and Stakeholder 4 -4 3 3 changes
Gather user and stakeholder
2 3 5 -5 5 Difficult in getting appointment and interview
4 ideas
5 Write Project background 2 0.5 0.5 3
6 Write Vision statement 1 2 3 6
7 Write Scope statement 2 -1 1 2 The scope is quite simple
8 Identify risks and assumption 2 0.5 2.5
The document should be review again and
9 Complete vision and scope 1 0.5 0.5 2 check any existing error
10 Team Review 3 -1 2 Team gather late and far distance
11 Review 1 3 0.5 0.5 4
Planning
1 Complete statements of works 2 1 3 Statement of works is more complex
Risk varies and should be coherent between
2 Plan for risk 4 1 -1 4 the team members
3 WBS 2 3 -1 1 5
4 Estimation & assumption 1 0.5 0.5 2 Idea should be coherent
5 Schedule 0.5 0.5 1 2
The document is long and complex, need more
6 Discussion summary 2 3 1 7 time to review
7 Analyze initial requirement 2 2 2 6
Understand stakeholder & user
8 needs 1 1 -2 2 2
9 Complete glossary 2 1 1 4 The glossary should be exact and complete
10 Login use case 1 1 -2 3 3
11 Manage faculty use case 1.5 2
12 Manage lecturer use case 1 1 1 3 The use case should be reviewed many times
13 Manage student use case 0.5 2 3 The use case should be reviewed many times
14 Manage courses offering 2 1 1 4 The use case should be reviewed many times
15 View academic history 2 2 1 5
16 Register cour ses use case 3 1 1 1 6
17 Manage financial activities 3 2 -3 1 3 Financial activities are quite complex

9

Complete functional
18 requirement 1 1 -4 4 2
Complete non- functional
19 requirements 2 1 3
20 Define the system 1 1 3 1 6 Team should consider carefully this part
Manage the scope of the
21 system 2 1 1 1 5
Requirement is complex and should be
22 Complete SRS 1 1 1 3 reviewed more
23 SRS inspection 0.5 1 2
24 Test Plan 1.5 1 3
25 Test case 2 1 3
26 Detail WBS 2 2
27 Re-estimation & assumption 1.4 1 2
28 Detail Schedule 1.5 2
29 Team review 1 2 3
30 Review 2 2 2
Executing
1 Define candidate architecture 1.5 2
2 Refine the architecture 1 1 2 Refinement should last for more session
3 Analyze behaviors 2 2
4 Complete analysis model 2 1 3
Complete design model &
5 system architecture 1 1 1 3 The architecture grows rapidly
6 Design GUI 2 1 3
7 Design database 1.5 2
8 Design persistence layer 2 1 3
9 Design business logic layer 1.5 2
10 Design presentation layer 1.5 1 3
11 Design test case 2 2
Complete Implementation
12 model 1 1 2
13 guidelines & code conventions 2 2
14 Produce Integration build plan 1 1
15 Review OOAD 1 1
16 Create file structure of system 1 1
17 Implement GUI 10 10
18 Implement database 9 2 11 No experience in using MySQL
19 Implement persistence layer 11 11
20 Implement business logic layer 9 9
21 Implement presentation layer 9 9
Review code & update
22 changes 2 1 3 Fixing bugs and updates encounter difficulty
23 Integrated build 2 2

10

24 Do integration test 1 1 2
25 Test build 1 1 2
26 Test system 2 1 3 System should be tested well
Inspection meeting should be established
between this duration to ensure the repor t is
27 Complete test report 6 2 8 defection- free and coherent
28 Rework 4 2 6
29 Team review & evaluation 1 1 2
30 Review 3 1 2 3
Closing
Need coherence and re-check logic
1 Complete sour ce code 6 2 4 12 functionality
2 Complete User Manual 3 2 1 1 7 User manual must be in detail
3 Do acceptance test 3 1 1 5 Acceptance test is brand new to team
4 Team review & evaluation 2 2
5 Complete all documents 2 2 3 7
6 Review 4 2 2

11

3.2 Phan Duy Tan estimation

Name : Phan Duy Tan Date: 11/09/2007 Estimation form ///


Category x goal tasks x quality tasks waiting time pr oject overhead

No.
Task Est. Del1 Del2 Del3 Del4 Total Assumption

Initial
1 Write team introduction 0.5 0.5 1 discuss
2 Review system request 0.5 0.5 1 additional requirement
3 Identify U ser and stakeholder 1 1 1 3 Interview
2 members do not know requirements provides
Login use case 4 -2 2
last year
4
Write Project background 1 1 2 Spend time to understand current problem
5
6 Write Vision statement 0.5 0.5 1 review
7 Write Scope statement 0.5 0.5 1 review
Identify risks and assumption 3 -1 2 4 cannot find all risk and assumption
8
All par ts of Vision and Scope document have to
Complete vision and scope 0.5 0.5 1
be finished
9
10 Team Review 1
11 Review 1 0.5 0.5
Planning
1 Complete statements of works 0.5 0.5
2 Plan for risk 6 4 -1 9 Need a lot of meeting to identify mitigation plan
3 WBS 0.5 0.5
4 Estimation & assumption 1 1
5 Schedule 0.5 0.5
6 Discussion summary 1 1
7 Analyze initial requirement 2 1 3 Review
Understand stake holder &
8 user needs 2 2
9 Complete glossary 0.5 0.5 1 Double-check ter m definitions
10 Login use case 1 1
11 Manage faculty use case 1 1
12 Manage lecturer use case 1 1
13 Manage student use case 2 2
There are many solutions in solving problem of
Manage courses offering 4 -1 1 4 course offering management. It is difficult to
choose one
14

12

15 View academic history 1 1
16 Register cour ses use case 4 -1 3 Team brainstor ming
17 Manage financial activities 2 -1 1 only simple activities
Complete functional
18 requirement 3 3
19 requirements 3 3
20 Define the system 2 1 3 Review
21 system 2 2
22 Complete SRS 1 1 2 Use cases are written in details
23 SRS inspection 1 1
24 Test Plan 2 1 3 No experience
25 Test case 2 1 3 Review
26 Detail WBS 0.5 0.5
27 Re-estimation & assumption 0.5 0.5 1 Under-estimate tasks
28 Detail Schedule 0.5 0.5
29 Team review 1 1
30 Review 2 1 1
Executing
1 Define candidate architecture 3 2 5 J2EE architecture is complex
2 Refine the architecture 1 1 2 J2EE architecture is complex
4 Complete analysis model 1 1
5 system architecture 2 1 3 Review
6 Design GUI 1 1
7 Design database 2 2
8 Design persistence layer 1 1
9 Design business logic layer 1 1
10 Design presentation layer 1 1
11 Design test case 2 1 3 test case document
12 model 2 2
13 guidelines & code conventions 0.5 0.5
14 Produce Integration build plan 0.5 1
15 Review OOAD 0.5 0.5 1 Debate
16 Create file structure of system 0.5 0.5 1 Packaging
Tan has a lot of experience in implementing
17 Implement GUI 6 -1 -1 1 5 GUI
18 Implement database 4 4 2 1 11 First time using MySQL
21 Implement presentation layer 6 1 7 Environment integration

13

22 changes 1 1
23 Integrate build 1 1
24 Do integration test 2 -1 1 No experience
25 Test build 2 2
26 Test system 2 2
27 Complete test report 3 2 5 Fix new defects
28 Rework 3 3
30 Review 3 1 1
Closing
1 Complete sour ce code 10 -1 -1 8 use IDE
2 Complete User Manual 6 -1 5 Thuc has a very good writing skill
3 Do acceptance test 3 3
5 Complete all documents 3 3
6 Review 4 1 1

14

3.3 Tran Minh Phung estimation

Name : Tran Minh Phung Date: 11/09/2007 Estimation form ///




Initial
Understanding the problems
1 Write team introduction 2 0.5 0.5 3
2 Review system request 2 1 0.5 0.5 4
3 Identify U ser and Stakeholder 2 0.5 0.5 3

3 1 1 5 Use all existed documents
ideas
4
5 Write Project background 1 1 2 4
6 Write Vision statement 3 1 1 0.5 0.5 6
7 Write Scope statement 4 1 2 7
8 Identify risks and assumption 1 0.5 0.5 1 3
Have enough all information
9 Complete vision and scope 1 0.5 0.5 2
10 Team Review 1 1
11 Review 1 1 1
Planning

Vision and Scope documents is baseline
1 Complete statements of works 1 0.5 0.5 2

Candidate risks must be listed out already
2 Plan for risk 3 2 1 1 5
3 WBS 4 0.5 0.5 1 6
4 Estimation & assumption 1.5 0.5 2
5 Schedule 2 1 3
6 Discussion summary 6 1 7
7 Analyze initial requirement 2 2
8 user needs 1 1 1 3
9 Complete glossary 4 1 0.5 0.5 5
10 Login use case 3 0.5 0.5 4
11 Manage faculty use case 2 0.5 0.5 3
12 Manage lecturer use case 3 0.5 0.5 4

15

13 Manage student use case 3 1 4
14 Manage courses offering 3 1 4
15 View academic history 4 1 1 6
16 Register cour ses use case 4 1 1 1 7
17 Manage financial activities 1 0.5 2
Complete functional
18 requirement 1 1
19 requirements 3 1 4
20 Define the system 7 0.5 0.5 8
21 system 8 1 2 11
22 Complete SRS 1 1
24 Test Plan 2 1 3
25 Test case 2 1 3
26 Detail WBS 2 2
27 Re-estimation & assumption 1 1
28 Detail Schedule 1 1
29 Team review 1 1
30 Review 2 1 1
Executing
1 Define candidate architecture 1 1 2
2 Refine the architecture 1 1
5 system architecture 2 2
6 Design GUI 1 1 2
7 Design database 1 1 2
8 Design persistence layer 1 1 2
9 Design business logic layer 1.5 0.5 2
10 Design presentation layer 1.5 0.5 2
11 Design test case 1.5 0.5 2
12 model 2 2
15 Review OOAD 1 1
16 Create file structure of system 1.5 0.5 2
17 Implement GUI 10 2 12
18 Implement database 8 1.5 0.5 10
19 Implement persistence layer 9 0.5 0.5 10

16

20 Implement business logic layer 8 0.5 0.5 1 10
21 Implement presentation layer 7 2 1 10
22 changes 1 1 2
23 Integrate build 1 1 2
24 Do integration test 1 1 2
25 Test build 1 0.5 0.5 2
26 Test system 3 3
27 Complete test report 6 2 1 9
28 Rework 5 2 7
30 Review 3 1 1
Closing
1 Complete sour ce code 10 1 1 1 13
2 Complete User Manual 6 1 1 8
3 Do acceptance test 4 2 6
6 Review 4 1 1

17

3.4 Nguyen Duc Quan estimation

Name :Nguyen Duc Quan Date: 11/09/2007 Estimation form ///




Initial
1 Write team introduction 1 2 -1 2
2 Review system request 1 1 2
3 Identify U ser and Stakeholder 2 1 -1 2

Gather user and stakeholder Use existing requirements provided last year,
1 1
ideas additional requirements
4
5 Write Project background 1 1
6 Write Vision statement 1 1
7 Write Scope statement 1 1

this task must be done along the summary
task
8 Identify risks and assumption 4 2 2 -2 6
9 Complete vision and scope 0.5 0.5 1 must do informal review
10 Team Review 1 1
11 Review 1 1 1
Planning
1 Complete statements of works 0.5 0.5 1

lack of experience in risk mitigation
2 Plan for risk 8 2 1 -2 11
3 WBS 1 1
4 Estimation & assumption 1 1
5 Schedule 1 1

must be more detail than vision and scope
6 Discussion summary 1 0.5 0.5 2
7 Analyze initial requirement 1 1 2
8 user needs 2 2
9 Complete glossary 2 2

10 Login use case 3 -1 2 Login is a popular function

18

11 Manage faculty use case 2 1 3
12 Manage lecturer use case 2 1 3
13 Manage student use case 2 1 3
3 members are familiar with old requirements
14 Manage courses offering 2 1 3
15 View academic history 2 1 3
16 Register cour ses use case 2 1 3
17 Manage financial activities 2 1 3
Complete functional
18 requirement 1 1 1 3
19 requirements 1 1 1 3
20 Define the system 1 1 1 3

Must per form scope management during the
requirement phase
21 system 6 2 1 1 10
22 Complete SRS 1 1
24 Test Plan 1 1 2
25 Test case 1 1 2
26 Detail WBS 1 1
28 Detail Schedule 1 1
29 Team review 1 1
30 Review 2 1 1
Executing
1 Define candidate architecture 2 1 3
2 Refine the architecture 1 1
5 system architecture 1 1
6 Design GUI 1 1 2
8 Design persistence layer 1 1
10 Design presentation layer 1 1
11 Design test case 1 0.5 0.5 2
12 model 1 1 2
15 Review OOAD 1 1

19

16 Create file structure of system 1 1
17 Implement GUI 5 2 2 9
18 Implement database 6 1 1 1 9
19 Implement persistence layer 7 1 9
20 Implement business logic layer 7 1 9
21 Implement presentation layer 7 1 9
22 changes 1 1
23 Integrate build 1 1
24 Do integration test 1 1
25 Test build 1 1
26 Test system 1 1 2
27 Complete test report 5 2 1 8
28 Rework 3 0.5 0.5 1 5
30 Review 3 1 1
Closing

J2EE requires more works
1 Complete sour ce code 10 2 12

Too many guidelines must be written
2 Complete User Manual 5 1 1 7
3 Do acceptance test 5 5

documentation follows RUP standard
6 Review 4 1 1

20

3.5 Le Vu Hoang estimation

Name : Le Vu Hoang Date: 11/09/2007 Estimation form ///


Category x goal tasks x quality tasks wa iting time project overhead


Initial
1 Write team introduction 1 1 2 Review introduction
2 Review system request 3 -1 2 Already have basic requirement
3 Identify U ser and Stakeholder 2 1 3 Investigate and interview
1
4 ideas 1
5 Write Project background 2 2
6 Write Vision statement 1 1
7 Write Scope statement 1 1
8 Identify risks and assumption 9 -1 -1 7 Team brainstor ming
9 Complete vision and scope 2 2
10 Team Review 2 2
11 Review 1 1 1
Planning
1 Complete statements of works 1 1
2 Plan for risk 12 -1 -1 10 Just find basic risk
3 WBS 1 1
4 Estimation & assumption 3 -1 2 Elicitation
5 Schedule 3 -1 2 Assign schedule for 1 person
6 Discussion summary 1 2 3 Sum everything in detail
7 Analyze initial requirement 2 -1 1 Stifling
8 user needs 3 3
9 Complete glossary 2 2
10 Login use case 6 -2 4 Login use case is simple
11 Manage faculty use case 4 4
12 Manage lecturer use case 4 4
13 Manage student use case 6 -1 5 Inspection
14 Manage courses offering 6 -1 -1 4 Just consider about offering, not class
15 View academic history 3 3
16 Register cour ses use case 3 3
17 Manage financial activities 2 2

21

Complete functional
18 requirement 4 4
19 requirements 4 4
20 Define the system 2 1 3 Iteration abuse
21 system 10 3 13 Define carefully scope
22 Complete SRS 1 1
24 Test Plan 2 -1 1 2 people
25 Test case 2 -1 1 2 people
26 Detail WBS 1 1 2 Scope Creep
28 Detail Schedule 1 1 2 Misunderstood predecessor
29 Team review 2 2
30 Review 2 1 1
Executing
1 Define candidate architecture 3 -1 2 Fix J2EE model
2 Refine the architecture 0.5 0.5
3 Analyze behaviors 0.5 0.5
4 Complete analysis model 1 0.5 0.5 2 Review model
5 system architecture 3 -1 2 Hoang is professional
6 Design GUI 2 1 3 Use AJAX
8 Design persistent layer 2 2
10 Design presentation layer 1 1 2 Use AJAX
11 Design test case 0.5 0.5 1 Many test cases
12 model 1 1
13 guidelines & code conventions 1 0.5 1.5 Replace Magic Number with sy mbolic Constant
14 Produce Integration build plan 1 1 2 Extract Method
15 Review OOAD 3 -1 2 Defect tracking
16 Create file structure of system 0.5 0.5
17 Implement GUI 7 5 12 Implement AJAX
18 Implement database 10 -1.5 -0.5 8 Use Database tool
21 Implement presentation layer 10 10
22 changes 4 -1 -1 2 Good Programming skill
23 Integrate build 1 1 2 No experience
24 Do integration test 2 2

22

25 Test build 1 1
26 Test system 1 1
27 Complete test report 5 2 2 9 Report unit test
28 Rework 6 1 -1 6 Broken build
30 Review 3 1 1
Closing
1 Complete sour ce code 16 -1 -1 14 Need system build
2 Complete User Manual 10 -1 9 Good English skill
3 Do acceptance test 4 0.5 0.5 1 6 Need rework
5 Complete all documents 5 2 7 Need time for review
6 Review 4 1 1

23

4. SCHEDULE

4.1 Task list
Start End Pre-
No. Task Duration Resource
Date Date decessor
1 Initial 11 days 02/10/2007 15/10/2007 Team
2 Write team introduction 2 days 02/10/2007 03/10/2007 Team
3 Review system request 2 days 02/10/2007 03/10/2007 Team
4 Develop vision and scope 6 days 04/10/2007 10/10/2007 3 Team
5 Identify User and Stakeholder 2 days 04/10/2007 05/10/2007 Team
6 Gather user and stakeholder ideas 1 day 06/10/2007 06/10/2007 5 Quan
7 Write Project background 1 day 08/10/2007 08/10/2007 6 Thuc
8 Write Vision statement 1 day 08/10/2007 08/10/2007 6 Phung
9 Write Scope statement 1 day 08/10/2007 08/10/2007 6 Hoang
10 Identify risks and assumption 6 days 04/10/2007 10/10/2007 5SS Team
11 Complete vision and scope 1 day 11/10/2007 11/10/2007 4 Quan
12 Team Review 1 day 12/10/2007 12/10/2007 11 Team
13 Review 1 1 day 15/10/2007 15/10/2007 12 Team
14 Planning 20 days 15/10/2007 09/11/2007 Team
15 Complete statements of works 1 day 15/10/2007 15/10/2007 Team
16 Plan for risk 11 days 15/10/2007 29/10/2007 Tan
17 WBS 1 day 15/10/2007 15/10/2007 Thuc
18 Estimation & assumption 1 day 16/10/2007 16/10/2007 17 Team
19 Schedule 1 day 17/10/2007 17/10/2007 18 Phung
20 Discussion summary 2 days 15/10/2007 16/10/2007 Quan
21 Analyze initial requirement 2 days 18/10/2007 19/10/2007 20 Team
22 Understand stake holder & user needs 2 days 22/10/2007 23/10/2007 21 Quan
23 Complete glossary 2 days 22/10/2007 23/10/2007 22SS Hoang
24 Complete use case model 3 days 24/10/2007 26/10/2007 22 Team
25 Login use case 3 days 24/10/2007 26/10/2007 Thuc
26 Manage faculty use case 3 days 24/10/2007 26/10/2007 Phung
27 Manage lecturer use case 3 days 24/10/2007 26/10/2007 Phung
28 Manage student use case 3 days 24/10/2007 26/10/2007 Phung
29 Manage offering course 3 days 24/10/2007 26/10/2007 Hoang
30 View academic history 3 days 24/10/2007 26/10/2007 Tan
31 Register courses use case 3 days 24/10/2007 26/10/2007 Tan
32 Manage financial activities 3 days 24/10/2007 26/10/2007 Quan
33 Complete functional requirement 3 days 24/10/2007 26/10/2007 Team
34 Complete non-functional requirements 3 days 24/10/2007 26/10/2007 Team
35 Define the system 3 days 24/10/2007 26/10/2007 Hoang
36 Manage the scope of the system 10 days 15/10/2007 26/10/2007 Quan

24

37 Complete SRS 1 day 29/10/2007 29/10/2007 35,33,34,24 Quan
38 SRS inspection 1 day 31/10/2007 31/10/2007 37 Team
Phung,
39 Test Plan 1 day 01/11/2007 01/11/2007 37SS Thuc
Phung,
40 Test case 1 day 01/11/2007 01/11/2007 37SS,39SS Thuc
41 Detail WBS 1 day 02/11/2007 02/11/2007 37,38 Quan
42 Re-estimation & assumption 1 day 05/11/2007 05/11/2007 41 Team
43 Detail Schedule 1 day 06/11/2007 06/11/2007 42 Quan
44 Team review 1 day 07/11/2007 07/11/2007 43 Team
45 Review 2 1 day 09/11/2007 09/11/2007 44 Team
46 Executing 31 days 01/11/2007 07/12/2007 Team
47 Define candidate architecture 3 days 01/11/2007 05/11/2007 Quan
48 Refine the architecture 1 day 09/11/2007 09/11/2007 47 Team
49 Analyze behaviors 1 day 09/11/2007 09/11/2007 Quan
50 Complete analysis model 1 day 10/11/2007 11/11/2007 49 Quan
51 Complete design model & system architecture 1 day 12/11/2007 12/11/2007 50 Hoang
52 Design component 1 day 13/11/2007 13/11/2007 51 Team
53 Design GUI 1 day 13/11/2007 13/11/2007 Thuc,Tan
54 Design database 1 day 13/11/2007 13/11/2007 Hoang
55 Design persistence layer 1 day 13/11/2007 13/11/2007 Hoang
56 Design business logic layer 1 day 13/11/2007 13/11/2007 Hoang
57 Design presentation layer 1 day 13/11/2007 13/11/2007 Tan
Phung,
58 Design test case 1 day 13/11/2007 13/11/2007 52SS Thuc
59 Complete Implementation model 2 days 14/11/2007 15/11/2007 52 Hoang
Complete Implementation guidelines
60 & code conventions 1 day 16/11/2007 16/11/2007 59 Tan
61 Produce Integration build plan 1 day 16/11/2007 17/11/2007 60SS Quan
62 Review OOAD 1 day 18/11/2007 18/11/2007 60,61 Team
63 Create file structure of system 1 day 19/11/2007 19/11/2007 62 Tan
64 Implement components & unit test & check list 9 days 19/11/2007 29/11/2007 Team
65 Implement GUI 9 days 19/11/2007 29/11/2007 Thuc
66 Implement database 9 days 19/11/2007 29/11/2007 Hoang
67 Implement persistence layer 9 days 19/11/2007 29/11/2007 Hoang
68 Implement business logic layer 9 days 19/11/2007 29/11/2007 Hoang
69 Implement presentation layer 9 days 19/11/2007 29/11/2007 Tan
70 Review code & update changes 1 day 30/11/2007 30/11/2007 64 Team
71 Integrate build 1 day 01/12/2007 01/12/2007 70 Phung
72 Testing & fix bugs 5 days 01/12/2007 05/12/2007 Team
73 Do integration test 1 day 01/12/2007 01/12/2007 Phung
74 Test build 1 day 02/12/2007 02/12/2007 73 Phung
75 Test system 1 day 03/12/2007 03/12/2007 74 Tan, Thuc

25

Phung,
76 Complete test report 4 days 01/12/2007 04/12/2007 Thuc
77 Rework 5 days 01/12/2007 05/12/2007 Team
78 Team review & evaluation 1 day 06/12/2007 06/12/2007 72 Team
79 Review 3 1 day 07/12/2007 07/12/2007 78 Team
80 Closing 18 days 10/12/2007 28/12/2007 Team
81 Complete source code 6 days 10/12/2007 15/12/2007 Hoang,Tan
82 complete User Manual 7 days 10/12/2007 17/12/2007 Thuc
83 Do acceptance test 5 days 15/12/2007 20/12/2007 Phung
84 Team review & evaluation 2 days 21/12/2007 22/12/2007 Team
85 Complete all documents 6 days 18/12/2007 23/12/2007 Quan
86 Review 4 1 day 28/12/2007 28/12/2007 Team

4.2 Gantt chart (reference)

26


5. RISK PLAN
Risk plan for project OURS Project
Assessment team members Quan, Tan, Thuc, Phung, Hoang
Risk Prob. Impact Priority Actions
Assign tasks of these people to Quan &
Phung, Thuc, and Hoang take
5 4 20 Tan, Work overtime.
pre-thesis course

Components developed Reserve time to integrated and rework for
separately cannot be
4 4 16 integration in schedule.
integrated easily, requiring
redesign and rework.
Make another informal meeting in the
Development team cannot
complete to deliver the 3 5 15 same week to complete them
components when reviewing
No substitution if any team
Add more tasks for remaining members,
member cannot continue to 4 3 12
add more time to work
contribute to the project.
Before starting; development team lists
People’s assignments do not
3 4 12 out and evaluates the skills of each
match their strengths
member.
Each team member will write a draft
version of report on what he does before
Detail reporting could take
4 3 12
more development time. documenter of team writes it again.

Work on weekends, set schedule with
All team members need
time for exam; define meetings in each
preparation time for
3 3 9
midterm, final exam, and week in suitable time for all people.
other subjects.
Lack of experiences in
software project
Assign 2 members working on each test.
management, especially in
Risk and changes management tasks will
testing, verification,
3 3 9 have a long duration to finish. Support
validation, risks
others people about what we already
management and changes
known.
management exists in the
Team
Create a detailed schedule in a whole
Development time is limited project and supervise process of work with
in 2 months only. Therefore, 2 3 6
schedule, change schedule with any
the pressure is really high.
mismatch with schedule.

27

Operate some relax actions to recharge
Low motivation and moral
2 3 6 team spirit
reduce productivity

Make clear about techniques we used, if
some new techniques are needed, assign a
Team member needs extra
time to learn unfamiliar 2 2 4 member read them and talk to other
Tools or techniques. members about them.

PM has to control conflicts in team, assure
Conflicts among team
everybody thoughts are respected, make
members’ ideas results in
2 2 4 assumptions when we have conflicts,
poor performances, more
record any conflicts to change if we are in
meeting, and extra rework.
wrong way
Analysis carefully requirements, review
Developing extra
requirements and design, if extra function
functionalities that are not
1 2 2
required will extends the appears, change schedule to add more
schedule. time for working

28


6. DISCUSSION SUMMARY

6.1 Project background

6.1.1 Purpose of project
There is a widespread agreement that the policy in course registration is very
complicated, costly, take-time, and inconvenient to both students and university. This is due
the fact that at the beginning of each semester, the university has to pause or delay some
activities to spend time for course registration of students. Some staffs have to prepare for
offering courses list (including selecting courses and inviting lecturers …), print it out, and
deliver the registration form to each student. After around one week, all students’ registration
form will be returned. In addition, the staffs have to input students’ registration information to
Excel files. They also have to check manually whether the registration form of each student is
legal or not basing on some conditions such as prerequisite course, maximum and minimum
number of credits allowed registering … If there is anything wrong or students want to add or
drop the courses, everything in the above process has to be restarted. Moreover, sometimes
some papers are lost when documents are moved from one place to another place; both
students and university have to spend time for retrieving necessary information and approve it.
However, it is impossible to do that in some cases.
In addition, calculating tuition fee for students, managing students’ academic history…
are also thorny issues. Mistakes can occur anytime when financial office‘s staffs use calculator
or Microsoft excel to calculate tuition fee.
Students’ transcript management is also another issue. When students want to have
transcript to see their academic history, they have to wait at least two weeks to receive it from
academic affair.
Those are some typical examples for the inconvenience and complication of the current
course registration policy. They lead the university to the decision of building Online Course
Registration System to improve effectiveness, reduce time and cost in course registration
process.

29

6.1.2 Scope of project
The list of features which are developed:

Feature Description

o This feature allows user to log in the system to achieve the access
permission to perform other functions, which are granted to that
specific user. It also lets the user log out his/her session.
o If the username and password are correct, the system redirects the
Login and user to his/her specific homepage (student, administrator or officers…).
logout o Otherwise, the system warns the user with the error messages. The
account is locked out if the user fails to log in three times. User has to
wait 30 minutes for the account to be released.
o Users also have another option to choose when they forget the
password and intend to recover it
o This feature allows a Student to view his studying progress. The
View Academic
Student can see the courses he has taken as well as the scores and
History
status (passed or failed)as follow:
 View all courses he took.
 View courses in a specific semester in a specific year.
 View all courses he passed.
 View all courses he failed.

o This feature allows a Student to register course offerings in the current
Register course
semester.
o The system retrieves and displays the Student’s current schedule (e.g.;
the schedule for the current semester). The schedule may be empty.
o The student can change the schedule by adding or dropping course(s).
o The system also checks the prerequisite and the total of credits before
allowing that student to register the selected courses. The Student can
only select a total of minimum 15 credits and maximum 30 credits.
o After the Student add or drop a course, the system recalculate total
credits and discount
o This feature allows Academic Affair Staff to manage department and
Manage
faculty information. This includes adding, updating, and deleting
Department
department and faculty from the system.
Information

o This feature allows the Academic Affair Staff to manage student
Manage
information in the registration system. This includes adding, updating,
Student
deleting, and searching students from the system.
Information

o This feature allows Academic Affairs to monitor course offerings in one
Manage

30

Courses semester of specific year
o The following tasks are included in this feature: Create list of course,
Offering
update list of course, add a course offering, delete course offering,
change lecturer
Manage
o This feature allows the Academic Affair Staff to manage lecturer
Lecturer information in the registration system. This includes adding, updating,
information deleting, and searching lecturers from the system.

o This feature allows Financial Office Staff to monitor student’s tuition
Manage
fee. This includes viewing and updating the tuition fee status of
financial
students.
activities
o Following tasks are included in this feature:
 View tuition fee
View by ID and name
View by faculty and academic duration
View by course, semester, and academic year
o Update tuition fee of students

31

6.2 Perspectives

6.2.1 Who will use the system?
User Description

Student The people who attending the course in the university. Use the system
to register the courses and view academic history

Academic Affair The Staff working in the Academic Affair Office, responsible for the
Staff Academic issue in the University. Use the system to manage school,
lecturer, and student information

Financial Office Staff The Staff who is responsible for the financial business in the University.
Use the system to monitor financial activities related to course
registration

6.2.2 Who can provide input about the system?
Student The Student needs an online mechanism to register, add and drop
course instead of the paper based process

The Student needs to view their academic history every time and
every where they want instead of waiting the respond from the
Academic Office

Academic Affair staff 1. The Staff of the Academic Affair Staff needs to manage the course
information, department information.
2. Easy to use, easy update, easy to modify

Financial Office staff 1. The Staff needs to manage the financial business of the University
2. They would view the Student tuition fee status
Lecturer They could give ideas or comment on the solution for the system’s
development and improvement

32

6.3 Project objectives

6.3.1 Know business rules
1. In the old paper-based mechanism, the process of registration as follow
a. The Students receive the Registration form and register the course for the
semester
b. The Registration forms are transferred to the Academic Affair Staff
c. Academic Affair Staff process the Registration Form
d. The Students receive the report from offering course from the Academic Affair
Staff
e. If any Student wants to add or drop course(s), the process restarts

2. At each beginning of the semester, the Academic Affair Staff make the list of course and
provide to each Faculty to distribute to the Students. They also manage the number of
Lecturer, the Department. All is the paper – based process.

3. After receiving the report from the Academic Affair Staff, the Students also receive the
financial report from the Finance Office. The Finance Officers have to manage the
financial information status of each student, decide the financial business of each
student and make the report to each student.

6.3.2 System information and/or diagrams
System context: OURS is a part of university management system. It can interact with
other sub-system of university management system such as scheduling system, grading
system, student management system, payment system …

University
Online university
System
registration system

33

OURS will be used by students, academic affair staffs, and financial office staffs with
functionalities showed in following diagram.

OURS

Manage Department
«uses»
«uses»
Manage Lecturer

«uses»
«uses»

Manage Student
«uses» Academic Affair Staff

Manage Course
Offering

Register Courses

«uses»
«uses»
Login&Logout «uses»
«uses»

«uses»
View Academic
History
Manage Financial
Student
Activities
Financial Office Staff

34


6.3.3 Assumptions and dependencies
1. The system will be applied for universities using credit system like International
University.
2. The registration information of students is processed by academic affair. And only
academic affair has right to manage and process the registration information.
3. Development team will use J2EE architecture to develop system.
4. Policy for tuition fee payment is using cash and it is managed by financial office.
5. Development team must have at least one 2-hour meeting per week.
6. Development time is 2 months and 10 days
7. Development team must produce the first build before the review 3
8. Each team member must work at least 15 hours per week.

6.3.4 Design and implementation constraint
1. The system will be developed using J2EE technology
2. The system provides the service in two languages Vietnamese and English

6.4 Risks
1. All team members need preparation time for midterm, final exam, and other subjects.
2. Phung, Thuc, and Hoang take pre-thesis course.
3. Lack of experiences in software project management, especially in testing, verification,
validation, risks management and changes management exists in the Team.
4. No substitution if any team member cannot continue to contribute to the project.
Applying the project again from the beginning could take development team more time.
5. Development time is limited in 2 months only. Therefore, the pressure is really high.
6. Development team cannot deliver the components when reviewed. Development team
could deliver components of unacceptably low quality, and time must be added to
improve quality.
7. Developing extra functionalities that are not required will extends the schedule.
8. Low motivation and moral reduce productivity.
9. Team member needs extra time to learn unfamiliar tools or techniques.
10. Conflicts among team members’ ideas results in poor performances, more meeting, and
extra rework.
11. People’s assignments do not match their strengths.
12. Components developed separately cannot be integrated easily, requiring redesign and
rework.
13. Detail reporting could take more development time.

35

6.5 Known future enhancements
1. Pay tuition fee (billing system): The Student can access to a billing system and perform
the transaction online such as transferring money to the Bank account of the University,
receiving the discount money from the University policies. This function would be
involved with the other banking system, authentication and security issue which are out
of the scope of the this development
2. Access the system as lecturer: Initially, the users who can access to the system are
Students, Academic Affair Staffs, and Financial Officer. The Lecturer plays a role as an
observer. However, in the future, the Lecturer can log in to the system to view course,
to access to their homepage in order to make the contact with the Students. Grading
system is also considered in the future.

6.6 References
For further information, the reader should examine the Vision and Scope document, the
SRS document.

6.7 Open, unresolved, or TBD issues
Schedule and time table construction are not completed at the recent time

36

7. SOFTWARE REQUIREMENT SPECIFICATION

7.1 USE CASE SPECIFICATION

7.1.1 Log in and Log out
Name Use Case: Log in and Log out

Summary This use case allows user to log in to the system to achieve the access
permission to perform other functions which are granted to that specific user.
It also lets user log out to end his/her session
Rationale The system provides functions such as course registration, financial
management just for the specific users (Students, AAO Staff…). Therefore,
logging in/out helps to distinguish type of user.
Users All users
Precondition None.
Basic course of
This use case begins when a user wants to log in the system to perform
event desired tasks.
1. The system requests the user to provide his username and password
for the authentication.
2. Right after the user submits his username and password, the system
checks username and password.
3. If the username and password matches, the system redirects the user
to his specific homepage (student, administrator, financial officer).
4. After logging in, the user can log out to end his/her session
Authentication Fail
Alternatives
paths
In step 4, if the username and password do not match, the system will
return the log in homepage with the error message MS001 (see
Appendix). The system will allow the user to log in 3 times before it locks
the user account and displays an error message MS002.

Not remember password

In step 1, the system provides the user another option, call “Not
remember password”. The users will use this option to recover their
forgotten password by giving the username, answer a security question.
Then the system will set the password to a default value. The user can
use the password to log in or change the new password.

37

Account locked

In step 3, if the user account is locked, the system notifies the user that
the account is locked with the error message MS002.
Account logging in simultaneously

In step 2, if the account is logged by another user, the second user can
not log in by that username and password. An error message MS003 will
be provided.
Post If the logging in is successful, the system will redirect the user to his specific
Conditions homepage.

38


7.1.2 Manage Department Information
Name Use Case: Manage Department Information

Summary
This use case allows Academic Affair Staff to manage department and faculty
information. This includes adding, updating, and deleting department and
faculty from the system.
Rationale The Academic Affair Staff needs to manage the department and faculty
information online. With the paper – based system, the Staff have to deal
with a bunch of paper if he/she wants to add, update or delete one
department. Along with this feature, it makes the Staff easier and more
convenient to manage the information.

Users Academic Affair Staff

Precondition User logged in the system as the role of Academic Affair Staff.

Basic course of This use case starts when the Academic Affair Staff wishes to add, update,
event and/ or delete department information in the system
1. The system requests that the Academic Affair Staff to specify the
function he/she would like to perform (add department information,
Update department information, or Delete department information).
2. Once the Academic Affair Staff provides the requested information, one
of the sub flows is executed.
If the Academic Affair Staff selects “Add a Department”, the Add a
Department sub flow is executed.

If the Academic Affair Staff selects “Update a Department”, the
Update a Department sub flow is executed.
If the Academic Affair Staff selects “Delete a Department”, the
Delete a Department sub flow is executed.
Add a Department

1. The system requests that the Academic Affair Staff enter the
Department information. This includes:
Name
-
Location
-
Description
-
Dean
-
Faculty
-

39


2. Once the Academic Affair Staff provides the requested information and
confirms, the department is added to the system.
3. The system provides the Academic Affair Staff with a summary of
department information newly added.
Update a Department

1. The system requests the Academic Affair Staff to choose a department
to modify information.
2. The Academic Affair Staff chooses a department.
3. The system retrieves and displays the department information has
been chosen by user.
4. The Academic Affair Staff makes the desired changes to the department
information. This includes any of the information specified in the Add a
department sub-flow
5. Once the Academic Affair Staff updates the necessary information, the
system updates the department record.
Delete a Department

1. The system requests the Academic Affair Staff to choose a department
to delete.
2. The Academic Affair Staff chooses a department.
3. The system retrieves and displays the department information
4. The system prompts message MS004 to the Academic Affair Staff to
confirm the deletion of the Department.
5. The Academic Affair Staff confirms to delete the selected department.
6. The system deletes the selected department from the system.

Delete Cancelled
Alternatives
paths
If, in the Delete s Department sub-flow, the Academic Affair Staff decides
not to delete the Department , the delete operation is cancelled, and the
Basic Flow is re-started

Post If the use case is successful, the department information is added, updated,
Conditions or deleted from the system. Otherwise, the system state is unchanged.

40

Project Plan And Srs Final

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Project Plan And Srs Final

Ähnlich wie Project Plan And Srs Final (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Project Plan And Srs Final