Glossary.doc
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Glossary.doc as PDF for free.
More details
- Words: 2,281
- Pages: 9
Version: <1.0> Date:
COLLEGE BUS MANAGEMENT SYSTEM <document identifier>
Revision History Date
Confidential
Version <x.x>
Description <details>
Author
ii
COLLEGE BUS MANAGEMENT SYSTEM <document identifier>
Version: <1.0> Date:
Table of Contents 1.
Introduction 1.1 Purpose 1.2 Scope 1.3 References 1.4 Overview
1 1 1 1 1
2.
Definitions 2.1
1 1 4 4 4 4 4 4 5
Confidential
iii
COLLEGE BUS MANAGEMENT SYSTEM <document identifier>
Version: <1.0> Date:
COLLEGE BUS MANAGEMENT SYSTEM 1.
Introduction [The introduction of the Glossary should provide an overview of the entire document. Present any information the reader might need to understand the document in this section. This document is used to define terminology specific to the problem domain, explaining terms that may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. This document should be saved in a file called Glossary.] The Bus Management System is a desktop system aimed at students, college administration to maintain bus facility. The system takes student information as input source and attempts to maintain the bus services. It also provides an easy accessibility of bus services provided by the college.
1.1
Purpose [Specify the purpose of this Glossary.] To develop software such that students and college authorities can avoid the difficulties of college bus management. Trainer can store and retrieve data easily. Non-technical users can also handle the software easily.
1.2
Scope [A brief description of the scope of this Glossary; what Project(s) it is associated with, and anything else that is affected or influenced by this document.] The Bus Management System is being developed to provide a tool for the different colleges to easily maintain the college bus information. The system will give an effective output for the Java and Microsoft excel given as input to the system. The compiled java program given as input to the system, after scanning the program will generate different reports. At the start of the project setup, Microsoft Access provides an interactive part to store information about buses; different routes of buses, student details and bus pass etc. During the period of finalizing the idea of the system, the primary goal was to design the system i.e. those who don’t know how to handle the software. As designing work began and things started taking shape, the system got developed to a stage where it would be used by entry level.
1.3
References [This subsection should provide a complete list of all documents referenced elsewhere in the Glossary. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.] Software Engineering: A Practitioner’s Approach-6th Edition- Roger S. Pressman
1.4
Overview [This subsection should describe what the rest of the Glossary contains and explain how the document is organized.]
Confidential
1
COLLEGE BUS MANAGEMENT SYSTEM <document identifier>
Version: <1.0> Date:
The purpose of the system is to provide a simpler method to store and access information related to buses and students. It also provides a simple interface which will be easily used without much training. It reduces paper work and makes all related information accessible easily This is a tool for the easy management of the college bus management and makes the services access to students without any dilemma.
2.
Definitions [The terms defined here form the essential substance of the document. They can be defined in any order desired, but generally alphabetic order provides the greatest accessibility.] BMS – Bus Management System WWW- World Wide Web DB- Database
2.1
actor Someone or something, outside the system that interacts with the system.
2.2
artifact A piece of information that is used or produced by a software development process. An artifact can be a model, a description, or software. Synonym: product.
2.3
baseline A reviewed and approved release of artifacts that constitutes an agreed basis for further evolution or development and that can be changed only through a formal procedure, such as change management and configuration control .
2.4
customer A person or organization, internal or external to the producing organization, who takes financial responsibility for the system. In a large system this may not be the end user. The customer is the ultimate recipient of the developed product and its artifacts. See also stakeholder.
2.5
change control board (CCB) The role of the CCB is to provide a central control mechanism to ensure that every change request is properly considered, authorized and coordinated.
2.6
change management The activity of controlling and tracking changes to artifacts. See also scope management.
2.7
change request (CR) A general term for any request from a stakeholder to change an artifact or process. Documented in the Change Request is information on the origin and impact of the current problem, the proposed solution, and its cost. See also enhancement request, defect.
2.8
configuration manager The configuration manager is responsbile for setting up the product structure in the Change Management system, for defining and allocating workspaces for developers, and for integration. The configuration manager also extracts the appropriate status and metrics reports for the project manager .
Confidential
2
COLLEGE BUS MANAGEMENT SYSTEM <document identifier> 2.9
Version: <1.0> Date:
defect An anomaly, or flaw, in a delivered work product. Examples include such things as omissions and imperfections found during early lifecycle phases and symptoms of faults contained in software sufficiently mature for test or operation. A defect can be any kind of issue you want tracked and resolved. See also change request.
2.10
developer A person responsible for developing the required functionality in accordance with project-adopted standards and procedures. This can include performing activities in any of the requirements, analysis & design, implementation, and test disciplines.
2.11
document A document is a collection of information that is intended to be represented on paper, or in a medium using a paper metaphor. The paper metaphor includes the concept of pages, and it has either an implicit or explicit sequence of contents. The information is in text or two-dimensional pictures. Examples of paper metaphors are word processor documents, spreadsheets, schedules, Gantt charts, web-pages, or overhead slide presentations.
2.12
enhancement request A type of stakeholder request that specifies a new feature or functionality of the system. See also change request.
2.13
feature An externally observable service provided by the system which directly fulfills a stakeholder need.
2.14
I/T Information Technology
2.15
iteration A distinct sequence of activities with a base-lined plan and valuation criteria resulting in a release (internal or external).
2.16
quality assurance (QA) The function of Quality Assurance is the responsibility of (reports to) the Project Manager and is responsible for ensuring that project standards are correctly and verifiably followed by all project staff.
2.17
project manager The role with overall responsibility for the project. The Project Manager needs to ensure tasks are scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements.
2.18
requirement A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document. A desired feature, property, or behavior of a system.
2.19
requirement attribute Information associated with a particular requirement providing a link between the requirement and other project elements—for example, priorities, schedules, status, design elements, resources, costs, hazards.
Confidential
3
COLLEGE BUS MANAGEMENT SYSTEM <document identifier>
Version: <1.0> Date:
2.20
requirement type A categorization of requirements—for example, stakeholder need, feature, use case, supplementary requirement, test requirement, documentation requirement, hardware requirement, software requirement, and so on—based on common characteristics and attributes.
2.21
requirements management A systematic approach to eliciting, organizing and documenting the requirements of the system, and establishing and maintaining agreement between the customer and the project team on the changing requirements of the system.
2.22
requirements specifier The requirements specifier details the specification of a part of the system's functionality by describing the requirements aspect of one or several use cases and other supporting software requirements. The requirements specifier may also be responsible for a use-case package, and maintains the integrity of that package. It is recommended that the requirements specifier responsible for a use-case package is also responsible for its contained use cases and actors.
2.23
requirements tracing The linking of a requirement to other requirements and to other associated project elements.
2.24
role A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization.
2.25
Rational Unified Process The Rational Unified Process (RUP) is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.
2.26
scope management The process of prioritizing and determining the set of requirements that can be implemented in a particular release cycle, based on the resources and time available. This process continues throughout the lifecycle of the project as changes occur. See also change management.
2.27
stakeholder An individual who is materially affected by the outcome of the system.
2.28
stakeholder need The business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use.
2.29
stakeholder request A request of any type—for example, Change Request, enhancement request, request for a requirement change, defect—from a stakeholder.
2.30
software requirement A specification of an externally observable behavior of the system; for example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment .
2.31
team leader The team leader is the interface between project management and developers. The team leader is responsible for ensuring that a task is allocated and monitored to completion. The team leader is responsible for ensuring that development staff follow project standards, and adhere to project
Confidential
4
COLLEGE BUS MANAGEMENT SYSTEM <document identifier>
Version: <1.0> Date:
schedules. 2.32
traceability The ability to trace a project element to other related project elements, especially those related to requirements. Project elements involved in traceability are called traceability items.
2.33
use case (class) A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A use case contains all alternate flows of events related to producing the "observable result of value". More formally, a use case defines a set of use-case instances or scenarios.
2.34
user A person who will use the system that is developed.
2.35
vision (document) The user's or customer's view of the product to be developed, specified at the level of key stakeholder needs and features of the system
2.36
2.37
2.38
2.38.1
2.39.1
5
COLLEGE BUS MANAGEMENT SYSTEM <document identifier>
Version: <1.0> Date:
concept should be presented.]
Confidential
6
More Documents from "Salma"
Glossary.doc
December 2019 42
Gambar Anatomi 2.1 (1).pdf
November 2019 40
Poem.docx
May 2020 22
Pemberdayaan Masyarakat.docx
October 2019 28
Absen Kp.xlsx
December 2019 22