You are on page 1of 8

APPENDIX F – PROJECT DESCRIPTION FORM

The original is to be submitted along with F1. Any deviation from the proposal should be explained by the group/individual in the project study submitted. The group/individual should keep a copy of the project description form.

PROJECT DESCRIPTION FORM (F2)

Index No.

Title of the Project: Payment and Cashiering System

Name of pilot client: Caloocan City Hall

Address of pilot client:

Web based project or not? : Web based project

1. Statement of Objectives (a) Goals and objectives of your proposed project with measurable outcomes.      A web based solution where users can access their bills and payment details. Intend to improve operational flow of the organization. Since it is web based, inquiry of payment bills is easier and will lessen crowd at cashier desk. Support financial infrastructure Process all LGU collections Provide improved input

(b) Scope. Itemized list of deliverables of the system with respect to the functionality of the system – user and management reports. Further, include the limitations.  Entering any type of payment including: o Payments for multiple bills o Payments without a bill o Partial payments Voiding payments Final Assessment will be catered

 

(c) Reasons for choosing the proposed project?  There are no reasons, just acceptance, because this project was destined to be developed by us until the last semester of this academic year.

(d) Your strategy for getting started.     Gather information and study related systems Interview a profile client or a person that knows the process of the system Organize gathered information and analyse the business process Designation of workloads and preparation of work plan

2. Required Development and Testing Environment (a) Hardware requirements – (processor, RAM, storage capacity etc.), Software requirements – (OS, Language versions, libraries etc.), Special requirements (if any).

Hardware Requirements Hardware Processor Hard Drive RAM Monitor Keyboard Mouse Printer Minimum Processor with speed of at least 2.T6 GHz Memory of at least 80 GB Memory of 2 GB 800 x 600 resolution 15 inches compatible pointing device compatible input device compatible device for printing Recommended Processor with speed of at least 3.3 GHz Memory of at least 500 GB Memory of 4 GB or higher 1280 x 760 resolution 17 inches compatible pointing device compatible input device compatible device for printing

Software Requirements Software Operating System Database Server Internal Development Software Minimum Windows XP MySQL Eclipse IDE Recommended Windows 7 Home MySQL

(b) How do you intend to obtain access for these facilities? Indicate the location, frequency of access to use these facilities and its approximate durations on monthly/weekly/daily basis. Weekly basis, every Thursday for 10 hours. (c) How do you intend to demonstrate your project work? Indicate access to software, hardware, data required for the demonstration. The hardware to be used (laptop) will be provided by the group. MySQL is an open source software and can be easily accessed. For the payment process, the group intend to use a trial over a particular type of payment mode (PayPal, BankAccounts) or if any mode is available. (d) Will the final system be tested / evaluated by real users?

Yes, to ensure if we met the needed requirements and to know the efficiency of our system.

(e) State the way of generating test data / test cases.  Study the application Getting as much information about the application as possible through available documentation (requirement specs, use cases, user guides) , tutorials, or by exercising the software itself (when available) Determine a list of features and different user roles. Standardize an approach for test case writing-

Write test cases for different features into different documents (usually excel sheets) and name according to the feature. In case a particular application has well defined user roles, differentiate the test cases based on a combination of user role and feature. Write tests involving interaction between different user roles and modules separately for complex applications.    Identify sets of test cases Identify logical sets of test cases based on individual features/ user roles or integration between them. Create separate test cases for special functional tests e.g. browser specific tests (using browser specific functions like back button, closing the browser session etc), UI tests, usability tests, security tests, cookie/ state verification etc. to ensure that all tests under these categories are covered. Effective test cases verify functions in isolation. If a particular feature has a lot of input combinations, separate the test into subtests. For e.g. to verify how the registration feature works with invalid input, write sub tests for different values. Main test case: Register_01- Verify user cannot register with invalid inputs in registration form Sub test cases: Register_01a- Verify with invalid email id. Register_01b- Verify with invalid phone number Register_01c- Verify with large number of characters in password field.  Decide on a structure

The test case format given below serves well for functional test case writing. Some of the information may be redundant if written for each test case e.g.

references, in which case it can be mentioned only once in the beginning of the test case. In some cases when the use cases or requirement specs are well written, there could be a perfect mapping of each test case to a particular section of the document.  Test case name- Decide on a test case naming convention based on the approach used. The test case name should be unique, so that when test cases document is used as an input to the automation scripts, all/combination of test cases can be included in a single suite of tests. Description- Explain the function under test. Clearly state exactly what attribute is under test and under what condition. Prerequisites- Every test needs to follow a sequence of actions, which lead to the function under test. It could be a certain page that a user needs to be on, or certain data that should be in the system (like registration data in order to login to the system), or certain action. State this precondition clearly in the test case. This helps to define specific steps for manual testing, and more so for automated testing, where the system needs to be in a particular base state for the function to be tested. Steps- Sequence of steps to execute the specific function. Input- Specify the data used for a particular test or if it is a lot of data, point to a file where this data is stored. Expected result – Clearly state the expected outcome in terms of the page/ screen that should appear after the test, changes that should happen to other pages, and if possible, changes that should happen to the database. Actual result – State the actual result of the function execution. Especially in case the test case fails, the information under „actual result‟ will be very useful to the developer to analyse the cause of the defect. Status- Write status separately for tests done using different environments, e.g. various OS/browser combinations. Test case status could beo “Passed” – The expected and actual results match. o “Failed”- The actual result does not match the expected result. o “Not tested”- The test case has not been executed for the test run, maybe is a lower priority test case. o “Not Applicable”-The test case does not apply to the feature any more since the requirement changed. o “Cannot be tested” – May be the prerequisite/ precondition is not met. There could be a defect in one of the steps leading up to the function under test. Comments- Write additional information under this column. For e.g. the actual result occurs only under a particular condition or a defect is reproducible only

 

  

sometimes. This information gives the developer/ client additional info about the feature behaviour which can be very useful in determining the root cause of a problem. It is especially useful for ”failed” cases, but also serves as a feedback if additional observation is mentioned in the “passed” cases. References- Refer / map a test case to the corresponding requirement spec or use case or any other reference material that you used. This information helps gauge the test coverage against the documented requirements. Conclusion: write effective cases with all the appropriate details.

(f) State the way of determining the acceptability / success of final system. The following procedure will be used in gaining sufficient evidence of the system‟s accuracy and functionality to be able to proceed to System Implementation with the highest level of confidence possible in the success of the system.    Prepare for System Acceptance - where the system acceptance environment is established, and where the testing team is instructed in the use of processes and tools necessary throughout this phase. Validate Data Initialization and Conversion- where the processes and utilities used to populate the system database are tested to confirm that they provide a starting point from which the new system can begin processing. Test, Identify, Evaluate, React (TIER) - where the system functions and processes undergo a series of exhaustive acceptance tests to validate their performance to specifications, and where examination of test results determines whether the system is ready to begin production. Refine Supporting Materials - where the various materials that support the use, operation, and maintenance of the System are updated to reflect any necessary Adjustments resulting from acceptance test results.

(g) The procedure to evaluate the performance of the system. Evaluating the system includes the following activities:
      

Identify the user-facing functionality of the system. Identify non–user-initiated (batch) processes and functions. Determine expected user activity. Develop a reasonable understanding of potential user activity beyond what is expected. Develop an exact model of both the test and production architecture. Develop a reasonable model of actual user environments. Identify any other process/systems using the architecture.

These activities can be accomplished by following these steps:

 

Capture system functions and/or business processes - identify the system‟s core functions to help build the performance acceptance criteria. Subsequently, workload models can be assessed to validate both the acceptance criteria and the collection of system functions. To ensure that all of the system functions are captured, start by meeting with stakeholders to determine the overall purpose of the system or application. Capture user activities- identify the key user activities for the application under test. Capture the logical and physical architecture- identify the relationship between the application and the structure of the hardware and software.

3. The Work Plan Use a project management tool such as Microsoft Project. Include each schedule in a separate sheet. A schedule should fit into a single A4 page. (a) The project schedule (using a Gant chart) July August September Tasks Week 2 3 4 1 2 3 4 1 2 3 4 Studying Related Systems Conduction of Interview Formulate Solutions Designation of Workloads Research and Prototyping

October 1 2 3 4

(b) The production schedule for the project study (using a Gant Chart) Tasks July August September October Requirements Analysis System Analysis Specification Systems Design

4. Additional Information (only for clarifications)

_____________________ Calado, Karen Joy C. _____________________ Labog, Althene Faustine T. _____________________ Servigon, Kayla Mae B. Group/Individual Signature Date: July 13, 2013