Report I, Knowledge Base & System Analysis and Design

Project name

Short name if any

Report I, knowledge base & system analysis and design

A report submitted to the

Faculty of Computer Science and IT

In partial fulfillment of the requirements for the degree of

Bachelor of Science

In Computer Science and IT

Prepared by

student 1 name

student 2 name

student 3 name

student 4 name

student 5 name

Supervised by

Dr. Ahmed ElShafee

Assistant Professor, Faculty of Computer Science & IT

Ahram Canadian University

January 2013

Table of Contents:

Preface...... 1

Acknowledgement...... 2

Part one: System analysis and planning

1. Chapter one: Introduction...... 3

1.1: Overview...... 4

1.2: Motivation...... 5

1.3 Document Organization...... 6

2. Chapter two: Project Planning...... 7

2.1: Project Planning...... 8

2.2: Risk Management...... 12

2.3: Report Writing and Presentations...... 17

2.4: Project Scheduling...... 17

3. Chapter three: knowledgebase...... 26

3.1 Introduction...... 27

3.2Topic 01...... 28

3.3 Topic 02...... 29

3.4 Topic 03...... 30

3.5 Topic 04...... 31

4. Chapter four: Project Analysis...... 19

4.1 Problem Domain...... 20

4.2 Similar System Survey and case studies...... 21

4.2.1 Case 01...... 22

4.2.2 Case 02...... 23

4.2.3 Case 03...... 24

4.2.4 Case 04...... 25

4.5 Requirements analysis...... 32

4.5.1 Functional Requirements...... 33

4.5.2 Non-Functional Requirements...... 41

4.6 A simple pattern for requirements analysis

4.7 System use case diagram...... 42

4.8 System sequence diagrams...... 43

4.9AssumptionsandConstrains...... 43

Part Two: System Design

5. Chapter five: System design and architecture...... 55

5.1 System layout...... 56

5.2 System features, characteristics, and functions...... 57

5.3 Class diagram...... 59

5.4 Classesdescription...... 59

5.5Database ER diagram...... 60

5.6 Hardware design & description...... 61

5.7 Technology constrains...... 62

Part three: Prototype implementation

6. Chapter six: Prototype Implementation...... 70

6.1System User manual...... 71

6.2System Snapshots...... 72

Conclusions and Future Work...... 80

References...... 81

Appendix 1: System Software Code...... 90

Appendix 2: System Hardware Components...... 100

Dr. Ahmed ElShafee, 2013, Graduation Project TemplatePage (1/55)

List of Figures:

Figure 2.1: GANTT CHART...... 25

Figure 3.1: USE CASE DIAGRAM...... 36

Figure 3.2: CONTEXT DIAGRAM...... 55

Acknowledgments

List acknowledgments. Briefly take the time to thank those who helped you along your writing journey.

Obviously, you'll never be able to include every person or institution, so try to keep this as brief as possible.

Part One

System Analysis And Planning

Chapter 1: Introduction

In this chapter, a brief review of the literature of the system is introduced.

Overview
Motivation
Document Organization

1.1: Overview

What dose proposed system present ?

Briefly define the proposed system

What is the main target of the system ?

Build a new product

Solution for existing problem

Enhancing existing product.

The main features if the proposed system?

Flexibility

Optimization

Cheap

Easy operation

…..

1.2 Motivation

Why you intend to build that project?

To learn new technology

To gain experience in certain field, that will develop your carrier path

To sell the project after building it

To solve a problem

To enhance service quality

1.3 Document organization

The remaining part of this Document is organized as follows.

Chapter 2 and 3 present …..

Chapter 4 and 5 provide a brief survey ……

Chapter 6 explains …..

Chapter 7 discuss ………..

Chapter 2: Planning

In this chapter, the planning process of this project will be discussed in brief.

Project Planning
Risk Management
Report Writing And Presentations

2.1: Project Planning

The purpose of Project Planning is to identify the scope of this project, estimate the work involved, and create a schedule for the development of the project.

Project planning begins with requirements that define the software to be developed. The projectplan is then developed to describe the tasks that will lead to completion.

As the project progresses, the plan should progress as well, monitoring the progress being made, ensuring activities are taking place when they should be.

Table (2.1) shows project activities

Activity / Duration / Start / End
Defining scope of the project / 2 weeks
Identifying project stakeholders / 1 week
Case studies / 2 weeks
Building Knowledge base / 10 weeks
System specification / 1 weeks
Requirements analysis / 4 weeks
Risk management / 1 week
Design SW modules / 3 weeks
design HW modules / 3 weeks
Design user interface / 1 week
Documentation / 15 weeks

2.2: Risk Management

Risk Management is the process of identifying, assessing project’s risks and then developing strategies to manage them. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.

Potential Risk Treatments

Once the projects risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories:

Transfer
Avoidance
Reduction (Mitigation)
Acceptance (Retention)

2.2.1: Risk Identification

The main risks types facing the development of this system are as follows:

Time risks

This is due to the compression of the schedule of the project, optimistic evaluation of time estimates, dropping off important tasks from estimates.

Budget risks

This is due to the un-predictable developing cost since the project requires several experiments which can’t be determined at the earlier stages.

Requirement risks

This can happen due to incomplete, incorrect, inconsistent, volatile or unclear requirements.

Some of the risks facing this project are as follows:

Unexpected User Operational faults …
Unexpected Environments operation faults …..
Design faults …..
Implementation faults ….
……

2.2.2: Risk Analysis

This process is responsible for assessing and analyzing the possible risks facing the development of the project.

This is done by calculating the risk exposure associated to every risk. This is equal to the product of the probability of the risk and its associated loss.

Risk / Probability (%) / Loss (in terms of system performance- %) / Risk Exposure
Unexpected User Operational faults … / 25% / 10% / 0.025
Unexpected Environments operation faults ….. / 75% / 15% / 0.1125
Design faults ….. / 45% / 20% / 0.09
Implementation faults …. / 15% / 8% / 0.02
Total risk in terms of system performance / 0.2475

2.2.3: Risk Prioritization

This process is responsible for prioritizing the possible risks facing the development of the project according to highest probability or greatest loss. Therefore, low effect risks can be ignored.

The following are the possible risks ordered discerningly according to their associated loss:

Unexpected User Operational faults …
Unexpected Environments operation faults …..
Design faults …..
Implementation faults ….

2.2.4: Risk Resolution

This is the process of identifying the treatment action regarding each possible risk:

Risk / Resolution Strategy / Description
Unexpected User Operational faults … / Risk Reduction / Involve reducing the severity of the loss. This is done by trying to ……….. in order to avoid …………….
Unexpected Environments operation faults ….. / Risk Transfer / Transferring the risk off the critical path of the system development process, possibly to another part of phase of the project (Causing error at speed calculation phase).
Design faults ….. / Risk Transfer / Transferring the risk off the critical path of the system development process, possibly to another part of phase of the project. such effect is excluded from the system scope. It is included as a part of the future work plan.
Implementation faults …. / Risk Acceptance / Involves accepting the loss when it occurs and not taking any measure to resolve this risk

2.3: Report Writing and Presentations

October 2011

A presentation about the scope of the project and an introduction to the project was presented. The scope and functionality of the project were discussed. A preliminary time line was proposed. The main functionality and features of the project were presented and a feasibility plan was provided for minimal specification.

November 2011

A presentation about the analysis phase of the project was presented to provide clarity about the projects functional and non-functional requirements, system expectations and the main features of the system.

December 2011

This is done with UML use case diagrams which depict functionality from the user’s perspective and from the system perspective.

January 2011

A presentation about the project design phase was presented to show the modular and architectural design of the project. In this presentation, a detailed explanation of the possible project modules was discussed.

2.4: Project Scheduling

Figure 2.1: Gantt chart

Dr. Ahmed ElShafee, 2013, Graduation Project TemplatePage (1/55)

Chapter 3: Knowledgebase

This chapter, presents building knowledgebase phase.

Introduction
Topic 01
Topic 02
Topic 03
Topic 04

Knowledgebase

A good knowledge base will streamline the process you use to build and to solve problems within the project.

Instructions

Choose a knowledge base program topics. There's no need to rebuild the wheel. You will buy the wheel, but you need to understand the operation of the wheel.

Determine the information that you should include when writing the report. For example, if you're creating a knowledge base for a software product, you may want writers to include information about the problem, the client's software version and operating system and how the employee solved the problem.

Divide topics between team members, each one will go through it, and after completing the topic, write down the technical part describing topic details, and transfer the gained knowledge base to other team members.

Allow all team members the opportunity to add to the knowledge base. The advantage of a knowledge base is that all individuals add their knowledge to the system. It doesn't work if only a few people have access. Set the controls in the software to allow the team to edit the knowledge base.

You may need to take a training employees on how to use a system. Before you can start building anything, you need to know how to use the software. Schedule a training period to go over the basics.

Topic/research area / Responsible person / period / Status (done/ fail/ postpone,…) / comment

3.2 topic 01

Write at least 5 pages to summarize everything

3.3 topic 02

Write at least 5 pages to summarize everything

3.4 topic 03

Write at least 5 pages to summarize everything

3.5 topic 04

Write at least 5 pages to summarize everything

Chapter 4: Analysis

In this chapter, the analysis phase of the project will be discussed briefly.

Problem Domain
Similar System Survey
Functional Requirements
Non-Functional Requirements
System use case diagram
System sequence diagram
Assumptions and Constraints

4.1: Problem Domain

The main motivation behind this project is to …..

Nowadays, traditional systems ….. are extremely expensive and need to be replaced by new system ….. in order to have better output, cheaper system and exclude human resource and human mistakes in the system.

Recently there are two types of traditional system commonly used in Egypt or world wide

….
…..

Yet, after years passed using these traditional systems the following bad impacts were discovered

….
…..

Thus, the need for another system to replace the traditional systems due to the disadvantages has become a necessity.

Our project comes with an innovative solution to overcome those disadvantages as a software alternative for traditional systems with the following advantages:

….
…..

4.2: Similar System Survey and case studies

4.2.1 Case 01

Brief description

…………….

Main functions and theory of operation

……………..

Theory of development and implementation

………….

Advantages

…………..

Disadvantages

…………………

Suggestions

…………………

4.2.2 Case 02

Brief description

…………….

Main functions and theory of operation

……………..

Theory of development and implementation

………….

Advantages

…………..

Disadvantages

…………………

Suggestions

…………………

4.2.3 Case 03

Brief description

…………….

Main functions and theory of operation

……………..

Theory of development and implementation

………….

Advantages

…………..

Disadvantages

…………………

Suggestions

…………………

4.2.4 Case 04

Brief description

…………….

Main functions and theory of operation

……………..

Theory of development and implementation

………….

Advantages

…………..

Disadvantages

…………………

Suggestions

…………………

4.5: Requirements Analysis

A software requirements definition is an abstract description of the services which the system should provide and the constraints under which the system must operate; requirements may be either functional or non-functional requirements.

4.5.1: Functional Requirements

Functional requirements specify the functionality that a system or component provide.

The following are the functional requirements of the proposed system:

System provides ….
User is able to ….
System shall …
System should …
System calculates …
System provides …

4.5.2: Non-Functional Requirements

Non-Functional Requirements ensure the delivery of an operable and manageable system which provides the required functionality reliable, uninterrupted or with minimal time of interruption even under unusual situations. They are developed by:

Project Team
Operations Manager
Application Support
QA-Manager
Testing Manager

The following are some of the system’s non functional requirements:

Interactive User Interface (GUI)
Troubleshooting for system inconsistencies
Portability
Performance Requirements(speed, response time)
Reliability of system with its functionality
Manageability and Ease of Use of the system main features
Scalability
Extensibility
Robustness

Some of which are more elaborated as follows:

Confidentiality:

The system should consider the maximum confidentiality standards for the data it contains, and maximum security should be applied to the system to ensure the data confidentiality and integrity.

Portability:

The system should be with maximum portability, and this is satisfied through the language used in developing the system .Thus this system can work on multiple platforms.

Reliability:

The system should be reliable, as it will contain all the organization documents including all the paper work of the organization, and hence it has to be a reliable system with very minimal probability of failure, and a very few number of failures per unit time.

Ease of Use:

The system should be very user friendly, that a normal organization individual with minimal knowledge of computer based applications can easily acquaint with it.

Extensibility:

The system should be able to extend the functionalities of itself with minimal adjustments and without going into details of other functionalities within the system. Hence, very high-level concepts such as OOP, encapsulation and abstraction should be used. In addition, the design of the database should promote the same concept in terms of being able to accommodate new data, and hence increase the extensibility of the system.

Robustness:

The system should be able to identify its failures, and ensure the consistency of the data within itself, and hence maximize the usefulness of the system. In addition, the system should be able to recover from errors and failures. Moreover, the system should allow trouble shooting.

4.6 A simple pattern for requirements analysis

Take the following steps to develop a pattern for business stakeholder requirements descriptions:

Identify the business processes.

Identify the IT processes that support each of the business processes.

Identify the activities within each of the IT processes.

Identify the functions within each of the activities.

Identify the use cases for one or more of the functions.

4.6.1IdentifyBusiness Process

BP1: Course automation process

BP2: Course schedule automation process

4.6.3 Identify IT processes that support the business process

BP1: Course automation process

ITP1: Manage courses

BP2: Course schedule automation process

ITP1: Manage tutors

ITP2: Manage course schedules

3.6.4 Identify the activities within each of the IT processes

BP1: Course automation process
ITP1: Manage courses
A1: Course topics activity
A2: Course activity

BP2: Course schedule automation process
ITP1: Manage tutors
A1: Tutor activity
A2: Tutor assignment activity
ITP2: Manage course schedules
A1: Course scheduling activity

4.6.5 Identify the functions within each of the activities

BP1: Course automation process

ITP1: Manage courses
A1: Course topic activity
F1: Add course topic
F2: Edit course topic
F3: Delete course topic
F4: View course topics
A2: Course Activity
F1: Add course
F2: Edit course
F3: Delete course
F4: View courses

BP2: Course schedule automation process

ITP1: Manage tutors
A1: Tutor activity
F1: Add tutor
F2: Edit tutor
F3: Delete tutor
F4: View tutors
A2: Tutor assignment activity
F1: Assign tutor to course
F2: Edit tutor
ITP2: Manage course schedules
A1: Course scheduling activity
F1: Assign course hours schedule
F2: Assign tutor to course hour
F3: View course calendar

4.7 System use case diagram

4.8 System sequence diagrams

4.9 Assumptions and Constrains

Assumptions.

You’ll need to make a brief and clear-cut description of any project assumptions related to business, people, technology, expectations, or schedules. Then list the sample project assumptions and share it with project participants, executives, and stakeholders for approval.

Constraints.

You will need to make a description of the major limitations impacting the project. The project constraints description must include timelines, resource availability, funding, and other important factors influencing project success.

Dependencies.

It’s important to determine a link between project assumptions and project constraints and then set any major dependencies between the characteristics. Once it’s done you’ll need to make a full description of the dependencies and use it in developing the project plan.

Adjustment.

If project assumptions and constraints are invalidated or they are likely to be modified at a later date, then you’ll need to make adjustments to the activities and estimates listed in your project plan accordingly.

Sample assumptions and constraints tend to exist around project resource availability or competence. That’s why, when developing a description of project management assumptions and constraints, try to give extra consideration to project cost, timing, and human-related issues. It’ll be one of the first steps during the project initiation phase. Once identified and agreed, sample assumptions and constraints in project management will be the foundation for managing unknowns and uncertainties – this is all about risk management.

Part Two

System Design

Chapter 5: System design and architecture

In this chapter, the design phase of the project will be discussed briefly.

System layout
System features, characteristics, and functions
Class diagram
Classes description
Database ER diagram
Hardware design and description
Technology constrains

5.1 System layout

The proposed system consists of three main modules, the server, the hardware interface module, and the software package

The following figure shows the system layout

Figure (5.1) system layout

A short description for each module and its associations with other modules.

….

5.2 System features, characteristics, and functions