PhiladelphiaUniversity

Faculty of Administrative & Financial Sciences

Business Networking and Systems Management Department

Graduation project

Graduation project Requirements:

Abstract

An abstract is a short summary of your completed project. If done well, it makes the reader want to learn more about your research.

Write your summary after the rest of the paper is completed. After all, how can you summarize something that is not yet written? Economy of words is important throughout any paper, but especially in an abstract.

These are the basic components of an abstract in any discipline:

1) Motivation/problem statement: Why do we care about the problem? What practical, scientific, theoretical gap is your project filling?

2) Methods/procedure/approach: What did you actually do to get your results?

3) Results/findings: As a result of completing the above procedure, what did you learn/invent/create?

4) Conclusion/implications: What are the larger implications of your findings, especially for the problem/gap identified in step 1?

However, it's important to note that the weight accorded to the different components can vary by discipline.

Guidelines

 An abstract is a short informative or descriptive summary of a longer report.

 It is written after the report is completed, although it is intended to be read first.

 In a technical report, the abstract appears on a separate page after the table of contents and list of illustrations.

 There are two distinct types of abstracts:

Style:

  • Single paragraph, and concise
  • As a summary of work done, it is always written in past tense
  • An abstract should stand on its own, and not refer to any other part of the documentation such as a figure or table
  • Focus on summarizing results - limit background information to a sentence or two, if absolutely necessary
  • What you report in an abstract must be consistent with what you reported in the documentation.

Chapter (1): introduction :

The abstract is the only text in a research paper to be written without using paragraphs in order to separate major points. Approaches vary widely, however for our studies the following approach can produce an effective introduction.

General intent

The purpose of an introduction is to aquaint the reader with the rationale behind the work, with the intention of defending it. It places your work in a theoretical context, and enables the reader to understand and appreciate your objectives.

An Introduction should contain the following four parts:

1. Background.

In this part you have to make clear what the context is. Ideally, you should give an idea of the state-of-the art of the field the project is about. But keep it short: in my opinion this part should be less than a page long.

2. The Problem.

If there was no problem, there would be no reason for a project, and definitely no reason for reading it. So, please tell the reviewer why she should proceed reading. A simple sentence like "So farno-one has investigated the link..." or "The above-mentioned solutions don't apply to the case ...", can sometimes be enough to clarify the point you want to get at. Experience shows that for this part a few lines are often sufficient.

3. The Proposed Solution.

Now - and only now! - you may outline the contribution of the project. Here you have to make sure you point out what are the aspects of your work clearly highlight what is the difference between your solution and the others. You can take your time here, but I suggest avoiding getting into too much detail.

4. The project goals and objectives.

This part is related to the proposed solution but in this part u must specify the goals and objectives for the project by using points.

In addition there can be the following optional ingredients:

5. Related work

6. An anticipation of the conclusions

If you decide to include this into the introduction, you might want to (a) keep it as short as possible, (b) refer as much as possible to the concluding section, and (c) keep it well separated from the rest of the introduction.

7. The outline (plan of the documentation)

Personally, I find it useful only for long documentation, otherwise I think it is a waste of paper. But this is my very personal opinion.

Style:

  • Use past tense except when referring to established facts. After all, the paper will be submitted after all of the work is completed.
  • Organize your ideas, making one major point with each paragraph. If you make the four points listed above, you will need a minimum of four paragraphs.
  • State the goals and objective precisely - do not oversimplify.
  • As always, pay attention to spelling, clarity and appropriateness of sentences and phrases.

Theoretical background:

Characteristics and advantages of tools used to realise the elements and components, which used during the project development including development CASE tools and programming tools and languages.

Chapter (2): planning and analysis :

Project nature and scope.

  • The problem statement
  • Proposed solution.
  • Project constraints
  • Project objectives and goals

Project management:

1)Total cost.

Hardware and Software coast.

2)Time management (time needed to execute project ( use Gantt Charts or PERT Diagram)) .

Fact finding:

To understand the system, you perform fact-finding using techniques such as interviews, surveys, document review, observation, and sampling

- document the techniques that used to collect information and the information that you obtained during this activity

Functional and non functional requirement

Functional requirements.

The functional requirement for a system describe the functionality or services that the system is expected to provide these depend on the type of the project which is being developed.

Non functional requirement

Constraints on the services or functions offered by the system.

You must mention the following system characteristics, speed, volume, capacity, availability, and reliability

System use cases:

1)System actors.

An actor is someone or something that is external to the system, but that is going to interact with the system.

2)Use case description.

A use case description documents the name of the use case

Names of the actors, a description of the use case

A step by step list of the tasks and actions required for successful completion, a description of alternative causes of action preconditionspost conditions and assumptions

3)Use case model.

A use case represents the steps in a specific business function or process, a use case is a complete sequence of related actions initiated by an actor

System DFDs :

1)Contacts diagram.

The context diagram represents the information system’s scope and its external connections but not its internal working; context diagram is the first DFD in every business process.

Context diagram shows the context into which the business process fits it contains only one process, representing the entire system.

2)Level zero diagram.

Diagram 0 displays the information system’s major processes, data stores, and data flows and its exploded version of the context diagram’s process symbol, which represents the entire information system

3)Lower level .

Lower level DFDs show additional detail of the information system through the leveling technique of numbering and partitioning

Chapter (3): project design:

1- Datadictionary:

A data dictionary, is a central storehouse of information about the system’s data

  • Data item dictionary.
  • Data structure dictionary .
  • Data store dictionary .
  • Data flow dictionary .
  • Function description dictionary.

2- Data design

Determine the system entities and attributes.

Database design:

  • create an initial ERD
  • assign all data elements to entities
  • create 3NF designs for all tables, taking care to identify all primary and foreign keys
  • generate the final ERD that will include new entities identified during normalization

3-Interface & Screens Design

4-Input, Output & report Design.

5-Control Design.

Chapter (4) : project implementation :

Application Development

In this part you must document your software modules

Module: A module consists of related program code organized into small units that are easy to understand and maintain.

 you will refer to DFDs, process descriptions, ERDs, and anything else that describes the functions that program or module must perform

_ User manual.

In this part you will refer to functional requirement part, mentioned each user, describing how to execute each function using step by step method.

Chapter (5): Conclusion and future work:

future work .

In this part you can mention any future updates and upgrades that you can add to your project, any new requirement and futures that can be added in later stages.

Conclusion.

Conclusion can be the most difficult parts of documentation to write. A writer needs to keep in mind that the conclusion is often what a reader remembers best. Your conclusion should be the best part of your paper.Conclusion frames your thoughts and bridges your ideas for the reader.Your conclusion is your chance to have the last word on the subject. The conclusion allows you to have the final say on the issues you have raised in your project, to summarize your thoughts, to demonstrate the importance of your ideas, and to propel your reader to a new view of the subject. It is also your opportunity to make a good final impression and to end on a positive note.

A conclusion should
  • Stress the importance of the project statement,
  • Give the documentation a sense of completeness, and
  • Leave a final impression on the reader.

Suggestions

  • Answer the question "So What?"

Show your readers why this project was important. Show them that your project was meaningful and useful.

  • Synthesize, don't summarize
  • Don't simply repeat things that were in your documentation. They have read it. Show them how the solution you made was not random.
  • Redirect your readers
  • Give your reader something to think about, perhaps a way to use your project in the "real" world. If your introduction went from general to specific, make your conclusion go from specific to general. Think globally.
  • Create a new meaning
  • You don't have to give new information to create a new meaning. By demonstrating how your ideas work together, you can create a new picture.

References.

1