Development Method Description of the Prototype Conclusion and Recommendations Note: Provide an introductory paragraph of what the reader should expect in this section. Overview of the Current State of Technology This section gives the reader an overview of the specific technology or field in the international or local setting. The information regarding the technology or field should be contemporary and not based on outdated sources. Discussion must not be too technical or too detailed. This section ends with a discussion on the problems faced by or that still exist in the pacific technology or field (e. . , limitations of existing software or algorithms). The problem statement would lead to the project objectives. However, in some instances there will be no existing problem that can be identified but possible opportunities that can be looked into. This section states the over-all goal that must be achieved to answer the problem. This subsection is an elaboration of the general objective. It states the specific steps that must be undertaken to accomplish the general objective. These objectives must e SMART (specific, measurable, attainable, realistic, and time-bounded).
Each specific objective may start with "to design/survey/review/analyze... " Studying a particular programming language or development tool (e. G. , to study Windows/ObJect-Oriented/Graphics/C++ programming) to accomplish the general objective is inherent in all project paper and, therefore, must not be included here. This section explains why the project must be done in this area. It rationalizes the objectives of the project with that of the stated problem/opportunity. Avoid including ere sentences such as "This project will be beneficial to the proponents/ department/college" as this is already an inherent requirement of all projects.
Focus on the project's contribution to the field of Information and Communications Technology. Some things you may want to consider when writing this section is the answer to the question - Why is this product required? This section can provide Justification when requirements are being negotiated, to assess whether a particular change is a good idea. This section will also provide readers an initial understanding why retain requirements have been included in the Requirements Analysis and Documentation section.
Include a brief narrative here which describes the product as you intend it to be realized. Use this section to define boundaries and set expectations. Did you work under any constraints such as platform or development environment? Did you have to make your product compatible with any existing software or other products currently in use? What does your product do? What activities can users perform while using it? List the main functions that you will build into your product here. User Characteristics Who do you expect to use your finished product, and why?
What is their technical background, their training or education, their motivation to use it? What obstacles might they encounter, and what specialized skills will they need? Assumptions and Dependencies In this section, list any assumptions you made about your project (for example, did you assume that the finished product would need to be delivered over the internet? ). If your project depends on any particular technical infrastructure, or requires administrators or others with specific skills, note that here.
You may also provide additional description to any assumptions or dependencies regarding the software and its use. These may concern such issues as: -Related Software and Hardware -Operating Systems -user characteristics -Possible and/or probable changes in functionality Design of Software, Systems, Product, and/or Processes This section presents the internal design of the system, by discussing its major components and their interactions. These components include the software components (e. G. , modules, database systems, etc. ), as well as the hardware components (e. , processors, devices, etc. ). The components and their interactions are graphically represented using data flow diagrams, system and program flowcharts, entity-relationship diagrams, hierarchical or structure charts, network diagrams, and block diagrams. In addition, discussion on why certain alternative and trade-offs was chosen must be included (e. G. , issues on software decomposition, cost of hardware). Formal/published methods were adopted or adapted, then include a reference to a more detailed description of these methods.
If several methods were seriously noninsured, then each such method should be mentioned, along with a brief explanation of why all or part of it was used or not used. This section provides a listing of all the functions that must be performed or delivered by the system, and a description of each. Screen designs must be included, to help visualize the function being discussed. When using corrections, be sure to explain major features or functions with narrative to avoid confusion or omission of desired features. Usually, the functions are based on the menu and toolbar options.
If a function generates reports, the report formats must be included in this section. This chapter gives an assessment of what happened in this project. It presents explanations and Justifications on how the objectives of the project were met, to what extent and why some objectives were not met. This chapter also includes a discussion of possible improvements that can be made on the software, as well as future directions of the project in general. This serves as a springboard for projects that may be done by future project proponents. Font Style: Times New Roman Font Size: 12 Spacing: Double