part 1: introduction - quadc0re.files.wordpress.com · part 1: introduction 1.1 background of the...

AUF-CCS – College Property Management System

Part 1: Introduction 1.1 Background of the Study

The College of Computer Studies started as the AUF Computer Center which was conceptualized as a pilot project of Dr. Teresita B. Ireneo, then the Dean of the College of Business and Economics and Philippine Encoding Corporation (PENCOR). After a very successful class demonstration in June 1983, and after receiving its government recognition, the center started its formal operation.

On October 05, 1990, the University entered into collaboration with ATS

Technologies, Inc., which is based in Singapore, designating the center as an Authorized Advanced Training Center (AATC) for ATS software.

In May 1992, the Computer Technology Center (CTC) became the College of

Computer Studies (CCS) when the Department of Education, Culture and Sports granted the permit to offer BS Computer Science and Associate n Computer degrees. The College was eventually renamed as College of Computer Studies when it started to offer B.S. Information Technology.

To date, the University has earned the distinction of being the only Nodal Station

of Central Luzon which provides information technology training programs to different educational institution in Central Luzon. The College was also identified by the Commission on Higher Education as the Center of Excellence in Information Technology Education. As such, it receives support and subsidy from CHED for projects aimed at improving the quality of IT education in the region.

For 27 years in operation of catering the needs of the College of Computer Studies in terms of Property Management, since 1983, the College has been experiencing complexity in keeping track of the records of the supplies and the number of requests coming from various departments because there is no centralized record storage for it. Since keeping track of records manually is a lot of work, time -consuming, tedious and prone to errors, it would be efficient that a computerized property management system would be implemented.

Not only the Executive is having a hard time processing manually that causes delay but there are also some considerations you need to think about, these are the supplier and the requestor. For the supplier, it is the poor delivery time from the distributor. If a certain item is out of stock, there is a need for a new stock that should be delivered on time. If the item is not delivered at the time it was needed, then it may cause delay.

And lastly, in processing the request, the requestor needs a lot of signatories to be

signed but because of a hectic schedule of the signatories involved the requestor is also

1-1

PDF created with pdfFactory Pro trial version www.pdffactory.com

http://www.pdffactory.com



experiencing a complication and/or delay of filling up the necessary requirements that causes poor central purchasing response time.

A more feasible and efficient procedure would be experienced.

1.2 Statement of the Problem The Property Management Executive of the College of Computer Studies is experiencing a complexity in keeping track of the records of the supplies and the number of requests coming from various departments because there is no centralized record storage for it. Since keeping track of records manually is a lot of work, time -consuming, tedious and prone to errors, it would be efficient that a computerized property management system would be implemented.

Not only the Executive is having a hard time processing manually that causes delay but there are also some considerations you need to think about, these are the supplier and the requestor. For the supplier, it is the poor delivery time from the distributor. If a certain item is out of stock, there is a need for a new stock that should be delivered on time. If the item is not delivered at the time it was needed, then it may cause delay.

And lastly, in processing the request, the requestor needs a lot of signatories to be

signed but because of a hectic schedule of the signatories involved the requestor is also experiencing a complication and/or delay of filling up the necessary requirements that causes poor central purchasing response time. The procedure for requesting is the student/faculty/NTP (non-teaching personnel) will fill up a certain form having this basic information: Name of the college, the name of the requested item and its quantity, then he will give the form to the College Secretary, then the latter will let the Dean sign it. If the form is approved, then the College Secretary will look for the item stocks from the department. If the item is available, the College Secretary will grant the request. If not, the College Secretary will give the request to the Central Processing Office (CPO), and then it will verify if the stock is available and upon verifying the request, if the item is available, they will give the item else they will order stocks from the distributor. And the requestor will wait for the confirmation, from the College Secretary, of his order until the stock is provided.

For these reasons, the proponents are faced with the problem of developing a computerized property management system that will encompass the monitoring or keeping track of the records and the number of requests made by different departments through a centralized record storage.

1-2





1.3 Project Charter Project Name: Property Management System Project Sponsor: AUF-CCS Project Team Name: QuadCore Project Team Members:

1. Samuel Neil Garsain, Team Lead 2. Jaenor Pasamonte, Analyst Programmer 3. Kemuel Ronald V. Toledo, Analyst Programmer 4. Bernice Aethena Salunga, Programmer

Project Goal: That a computerized Property Management System will be implemented

throughout the College of Computer Studies and upon the system’s success, the team is looking forward of having it implemented University wide. Business Case:

There is something innovative happening at the College of Computer Studies and it’s not just any new system. It is a college-based computerized Property Management System that will replace the manual set up of the said system.

The requesting student/faculty/NTP (non-teaching personnel) will no longer manually fill up a certain form having the basic information: Name of the college, the name of the requested item and its quantity. Then the said form will no longer be given to the College Secretary, to be signed by the Dean. Lesser or even no more paper works is to be done by the Secretary in search for the item stocks from the department. If the item is available, the College Secretary will grant the request through the use of the system. Else, the College Secretary will give the request to the Central Processing Office (CPO), and then it will verify if the stock is available and upon verifying the request, if the item is available, they will give the item else they will order stocks from the distributor. And the requestor will not anymore wait for a long time for the confirmation, from the College Secretary, of his order until the stock is provided. Instead you will just click and up to date. Required Resources:

Of course, with this technology there are fundamental changes that will take effect. As a start, the user will receive the latest version of Microsoft Visual Basic 6.0 and the My SQL Server as an additional software required to run the system.

Our College Property Management System will later on be University wide for faster and feasible transactions.

1-3





Part 2: Review of Related Literature 2.1 Related Articles

A point of view on TPS...

Transaction processing system or TPS is a type of information system wherein it is used in replace of a large number of man power. It is not absolute in it to take place on all the roles of computer users, but in deed it is a big help on businesses with large day by day processes. Instead of employing number of people on a same task due to complexity of the business, it is now important to have a transaction processing system in which it will provide immediate response to the rapid grow of the business. Although it will require the company to invest on such computer system, but if the system was planned, created, and evaluated very well and it blends what the people usually do without the system, it will assure the business on more success and will make the company global competent.

Speaking of globalization, TPS are not just what they usually denote. Online transaction processing systems are becoming the more well-known in terms of large businesses. Ecommerce and automated teller machines are just few examples of online TPS. They are very useful nowadays to actually compete on fast growing computer based industries

TPS’ complexity.. nuts and bolts..

Transaction processing has always been complex and critical. However, with the advent of MTS and EJB, transaction processing has caught the interest and attention of both developers and IT organizations simultaneously. This is not without reason. These recent technologies simplify distributed transaction management, and are fueled by three major developments: Distributed Computing: The two competing distributed computing models (CORBA and COM/DCOM) simplified distributed computing. Component Based Development: Based on the above interface centric paradigms, component based distributed application development has become a reality. Object Orientation: The maturity of object-oriented programming assisted by design patterns and frameworks, made implementation of these technologies feasible. In addition, these technologies address the scalability and robustness that are required for today’s enterprise applications. The purpose of this document is to focus on the issues and concepts involved in distributed transaction management. By no means this is a comprehensive enough to cover all the finer details of the underlying technologies. At the same time, this document does not attempt to compare technologies, but attempts to map various concepts to each of the technologies. Only the nuts and the bolts are discussed, not how nuts and bolts are made, and not how machines are built with them.

2-1.a





Transaction Processing Systems – Features. .

The success of commercial enterprises depends on the reliable processing of transactions to ensure that customer orders are met on time, and that partners and suppliers are paid and can make payment. The field of transaction processing, therefore, has become a vital part of effective business management, led by such organizations as the Association for Work Process Improvement and the Transaction Processing Performance Council.

Transaction processing systems offer enterprises the means to rapidly process transactions to ensure the smooth flow of data and the progression of processes throughout the enterprise. Typically, a TPS will exhibit the following characteristics:

Rapid Processing, Reliability, Standardisation, Controlled Access, Transactions Processing Qualifiers, Atomicity, Consistency, Isolation, Durability, Types of Transactions, Batch Processing, Real Time Processing.

TPS’ crucial part of effectivity.. The success of business enterprises depends on the consistent processing of

transactions to guarantee that customer orders are met on time, and that partners and suppliers are waged and can make payment. The field of transaction processing, therefore, has become a crucial part of effective business management, led by such organisations as the Association for Work Process Improvement and the Transaction Processing Performance Council.

TPS a Sneak peak . .

A Transaction Processing System (TPS) is a type of information system that collects, stores, modifies and retrieves the data transactions of an enterprise. A transaction is any event that passes the ACID test in which data is generated or modified before storage in an information system. Transaction processing systems offer enterprises the means to rapidly process transactions to ensure the smooth flow of data and the progression of processes throughout the enterprise. The success of business enterprises depends on the consistent processing of transactions to guarantee that customer orders are met on time, and that partners and suppliers are waged and can make payment. The field of transaction processing, therefore, has become a crucial part of effective business management, led by such organizations as the Association for Work Process Improvement and the Transaction Processing Performance Council.

2-1.b





2.2 Software Development Methodologies

We were choosing between Rapid Application Development and Waterfall methodology. Until such time that we’ve come up with choosing RAD as the methodology for our software development. We chose RAD for the fast development of the software. Choosing RAD, we focused on the requirements of the user, for us to develop an application that would meet the constraints of the existing system. Upon the process of the applications development, the application went through several testing and debugging. And as analysts and programmers we give first aid to the application, debugging. Rapid Application Development is Also sometimes referred to as Rapid Prototyping, Rapid Application Development is a method of decreasing the time taken to design software systems. It uses incremental development and the construction of prototypes - and encourages constant feedback from users/customers by keeping lines of communication clear - with the end goal of expediting the development cycle.

Basic principles:

• Key objective is for fast development and delivery of a high quality system at a relatively low investment cost.

• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.

• Aims to produce high quality systems quickly, primarily through the use of iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques.

• Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance.

• Project control involves prioritizing development and defining delivery deadlines or “timeboxes”. If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline.

• Generally includes Joint Application Development (JAD), where users are intensely involved in system design, either through consensus building in structured workshops, or through electronically facilitated interaction.

• Active user involvement is imperative. • Iteratively produces production software, as opposed to a throwaway prototype. • Produces documentation necessary to facilitate future development and

maintenance. • Standard systems analysis and design techniques can be fitted into this

framework.

Rapid Application Development was a software development methodology introduced in the 1990s and presented in book form by information technology guru

2-2.a





James Martin. A reaction to the then well-established methodologies which emphasised careful and prolonged requirements gathering before the actual software development began, Rapid Application Development encouraged the creation of quick-and-dirty prototype-style software which fulfilled most of the user’s requirements but not necessarily all. Development would take place in a series of short cycles, called time boxes, each of which would deepen the functionality of the application a little more. Features to be implemented in each time box were agreed in advance and this game plan rigidly adhered to. The strong emphasis on this point came from unhappy experience with other development practices in which new requirements would tend to be added as the project was evolving, caused massive chaos and disrupting the already carefully prepared plans and development schedules. Rapid Application Development methodology advocated that development be undertaken by small, experienced teams using CASE (Computer Aided Software Engineering) tools to enhance their productivity.

Rapid Application Development advocates believed that the development of rapid prototypes was a good way to flush out customer requirements by gaining immediate feedback from the client. One of the problems that had been identified with other software development practices was that clients often didn’t really know what they wanted or didn’t want until they saw a practical implementation. It was through the process of customers commenting on an evolving application that new requirements were teased out. Usually, this would be seen as an unwelcome development which could play havoc with agreed schedules. With the Rapid Application Development methodology, however, it became a standard and accepted part of the development process.

With its emphasis on small teams and short development cycles, it is not surprising that, in Rapid Application Development doctrine, code reuse was also prized as a means of helping get the work done. This caused early Rapid Application Development adopters to embrace object-oriented languages and practices before they had really penetrated into the mainstream.

Today, Rapid Application Development as a formal methodology is no longer widely practiced. Some would argue, however, that it is a case of revolutionaries evolving into statesmen, and once boldly innovative thinking becoming the new orthodoxy. In its embrace of the object-oriented paradigm, and the use of software engineering tools to enhance programmer productivity, it was certainly ahead of its time. And in its emphasis on small teams, short, iterative development cycles and an avoidance of prolonged requirements gathering up front, it shares many similarities with the extreme programming or agile development methodologies which still remain in vogue.

As well as denoting a formal software development methodology, the phrase rapid application development became something of a marketing buzzword and was casually applied to a variety of software development products. Although hardly hardcore implementations of the methodology’s ideas, these products did incorporate some of its key concepts. For example, to facilitate rapid development, strong emphasis was placed on the idea of software re-use. The notion of software components began to be nurtured.

2-2.b





Supporters believed that complex software systems could be constructed largely by stitching pre-built software components together. In this grandiose vision, software components would be re-used from project to project within a company’s development team or even bought in from outside. In fact, it was hoped that a healthy market for third-party software components would develop, allowing even small companies to thrive by authoring niche software components designed to be used by others. Although reality never quite fulfilled the aspirations of some of the visionaries, the ActiveX control and JavaBeans software component standards did acquire some degree of traction, and a market for third-party code components written to these standards did emerge, even if it was never all that vigorous.

Another key element of the Rapid Application Development-lite approach was visual programming. According to this concept, it should be possible to construct software with little or no knowledge of programming. The ideal was that programs could be built by non-programmers hooking components together in some kind of workshop-like development application. Again, this ideal was never quite fulfilled, but visual development practices did become a standard part of the typical programmer’s toolkit and are now routinely used to develop some parts of software applications, while more traditional coding accounts for the rest. Graphical interfaces, for example, are now constructed visually more often than not, with programmers or user interface designers modifying the desired look of the user interface from within a visual editor and the Rapid Application Development tool then generating the appropriate code to create that look automatically. The automatically-generated code then forms a skeleton framework for the application as a whole which the software developers then build upon and edit it by hand.

In common use today, the phrase Rapid Application Development has lost most of its original meaning, and even in the ranks of IT professionals, many would be unaware that it once referred to a formal software development methodology. Almost any software tool which is used in the creation of other software will be described in its marketing literature as something that facilitates Rapid Application Development. When used informally in this sense, the phrase Rapid Application Development usually indicates that the tool in question takes some of the burden from the programmer’s back by automatically generating part of the program code. Today the software tools used by the majority of programmers to develop new software are called Integrated Development Environments (IDEs). Almost all of them include some Rapid Application Development features. When creating a new program, for example, the software engineer can indicate what kind of application it should be, such as a console application, a program with a graphical user interface or one that is database-driven. The IDE will then generate a base template of code which the programmer takes as a starting point for his or her own work.

2-2.c





Part 3: Analysis

3.1 Fishbone Diagram

3-1





3.2. a. DFD of the Existing System (Context Level)

3-2.a





3.2. b. DFD of the Existing System (Level 0)

Transaction Management Report

3-2.b





3.2.c. DFD of the Existing System(Level 1-Part 1)

3-2.c





3.2. d. DFD of the Existing System (Level 1-Part 2)

3-2.d





3.3. a. DFD of the Proposed System (Level 1-Part 1)

3-3.a





3.3. b. DFD of the Proposed System (Level 1-Part 2)

3-3.b





3.3. c. DFD of the Proposed System (Level 1-Part 3)

3-3.c





3.4 Structured English

1.0 Commit Request Transaction DO READ ID number from Requestor Item Request Data

FIND Processed Request Data ID no. ADD Transaction Management Report

UNTIL End –of – File 2.0 Control Requestor Record

DO READ Requestor Data BEGIN IF Requestor Data is given THEN Generate Requestor Management Report END IF UNTIL End –of File

3.0 Control Item Record

DO READ Item data Record ADD Item Record IF Item Data Record is given by the management THEN Generate Item management report END IF UNTIL End - of - File

3-4





3.5 E-R Diagram

a. One or more REQUESTOR request from only one DEPARTMENT b. A DEPARTMENT provides request of one or more REQUESTOR c. One or more DEPARTMENT request for MAIN SUPPLY ITEM d. One or more MAIN SUPPLY ITEM is/are served by various DEPARTMENT e. A DEPARTMENT is providing one or more DEPARTMENT ITEM f. One or more DEPARTMENT ITEM is/are served by one DEPARTMENT

3-5





Appendix:

A. Endorsement Letter

October 2, 2009 Date Miclat, Alvin C. College of Computer Studies Angeles University Foundation Mc Arthur Highway, Angeles City 2009 Dear Sir:

A contingent part of the requirements of the B.S. Computer Science course SAD310A-Systems Analysis and Design is a thorough study of a particular system. Students enrolled in the course are required to identify a system and perform a project proposal which will include data gathering and interviews. The objective of the course is to provide the students the opportunity to develop an analysis and design documentation.

The following students have expressed their intention to consider your system for their proposal:

1. Garsain, Samuel Neil S. 2. Pasamonte, Jaenor D. 3. Salunga, Bernice Aethena 4. Toledo, Kemuel Ronald

Through this letter, I would like to seek your approval for the above undertaking. Rest

assured that the information that will be given to them will be for academic purposes only and will be treated with utmost confidentiality. Thank you. Very truly yours, James A. Esquivel SAD310A Instructor Noted by: Ms. Lilibeth T. Cuison Dean, CCS

A-1





B. Interview Transcript

ANGELES UNIVERSITY FOUNDATION COLLEGE OF COMPUTER STUDIES SAD310A-Systems Analysis and Design

INTERVIEWEE: Ms. Leilani Palabasan, Property Management Executive DATE: 25 – September – ‘09 TIME: 3:30 P.M. PLACE: Dev B, Information Technology Training Center Bldg. SUBJECT: Current Credit-Checking Policy

• Good afternoon sir/ma’am, we are 3rd year students coming from the College of Computer Studies, BS Computer Science our team would like ask for some details about the property management System of our college.

• Thank you sir/ma’am

• As analysts, our team would like to obtain an understanding about the college’s

existing property management system and its policies.

• On what circumstances would determine whether a client’s request for the college’s certain property is approved for use?

• What are the feasible assessments or actions that might be taken once these

circumstances have been evaluated?

• How would clients be informed when any of the college’s property is not approved for their request?

• After a new request is approved for use and placed in the queue of requests for

processing, a client might request that a change be made to the request. Would the request have to go through the whole process of requesting if the new total request exceeds the number of requests?

• Who are the individuals that benefits with the system?

B-1





C. Gantt Chart

CCoolllleeggee PPrrooppeerrttyy MMaannaaggeemmeenntt SSyysstteemm ‘‘0099--‘‘1100 PPrroocceesssseess PPrreecceeddeennccee BBuurrsstt ttiimmee

((wweeeekkss))

A. Planning None 2

B. Data Gathering None 4

C. Conduct Interviews A 2

D. Administer Questionnaires C, E 2

E. Read Company Reports B 2

F. Analyze Data Flow D 3

G. Define the Problem D 2

H. System Proposal F 2

I. System Approval H 2

J. System Design H,I 3

K. Programming J 10

L. Testing

M. Debugging

N. System authentication

O. Defense

P. Recommendations

Q. Polishing

R. Implementation

K

L

M

N

O

P

Q

2

3

3

1

1

5

2

Total 51

Source: Proposed project execution time

C-1





C-2





D. Pert Diagram

D-1




part 1: introduction - quadc0re.files.wordpress.com · part 1: introduction 1.1 background of the...

Documents