​​ Preliminary Project Descriptions (PPDs) Preliminary Project Descriptions (PPDs) express early design ideas that are understandable by AusEd, academic staffs , and the general student Stage 1: Analyse AusEd's requirements for an accounting system and produce necessary documentation. Stage 2: Review open source accounting systems, short-list and assess 3 to 5 possibilities, and implement the chosen system (perhaps after significant modification if such is considered necessary). Review the relative benefits of running the system on an in-house server and externally maintained server.. Project Preliminaries: It provides online education in Information Technology and Business to student world-wide, a commitment to quality in teaching, researching and service anywhere in the world. The majority of their students are from outback areas of Australia, Papua New Guinea and the South Pacific Islands. Through fostering and advancing knowledge in education By providing education programs through online learning, AusEd gives students the flexibility to study a university degree without the need to visit a campus. AusEd students pursue their study programs through a variety of means including the use of special study centres, online discussion forums, electronic library resources, direct communication with lecturers, and by receiving study materials online or by post. These learning opportunities assist in the development of discipline-specific skills and generic skills relevant to life-long learning. Aim: There are two elements to AusEd's strategic plan. The first is to increase income by diversifying sources of funding (ie. beyond existing sources such as Australia's AusAid and New Zealand's NZAid). In tactical terms this means; first, extending educational services to areas with poor and/or unreliable Internet connections; and second, improving reliability of student assessments. The second element of AusEd's strategic plan is to minimise the cost of non-core activities, particularly support operations (eg. accounting, staff recruitment) and technology development. As part of meeting this objective AusEd hopes, wherever practical, to utilise and participate in the development of open source software. Use Case Diagram: While a use case itself might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level view of the system. It has been said before that "Use case diagrams are the blueprints for your system". They provide the simplified and graphical representation of what the system must actually do. Due to their simplistic nature, use case diagrams can be a good communication tool for stakeholders. The drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to stakeholders and that they were "interpreted more completely than class diagrams". The purpose of the use case diagrams is simply to provide the high level view of the system and convey the requirements in layman's terms for the stakeholders. System Context Diagram: System Context Diagrams... represent all external entities that may interact with a system... Such a diagram pictures the system at the centre, with no details of its interior structure, surrounded by all its interacting systems, environments and activities. The objective of the system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of systems requirements and constraints. System Context Diagrams are used early in a project to get agreement on the scope under investigation. Context diagrams are typically included in a requirements document. These diagrams must be read by all project stakeholders and thus should be written in plain language, so the stakeholders can understand items within the document. ER-diagram: An entity-relationship model is a systematic way of describing and defining a business process. The process is modeled as components (entities) that are linked with each other by relationships that express the dependencies and requirements between them, such as: one building may be divided into zero or more apartments, but one apartment can only be located in one building. Entities may have various properties (attributes) that characterize them. Diagrams created to represent these entities, attributes, and relationships graphically are called entity–relationship diagrams. An ER model is typically implemented as a database. In the case of a relational database, which stores data in tables, every row of each table represents one instance of an entity. Some data fields in these tables point to indexes in other tables; such pointers represent the relationships. The three schema approach to software engineering uses three levels of ER models that may be developed.