Chapter 3 METHODOLOGY Research Design The Sashimi model (so called because its features overlapping phases, like

the overlapping fish of Japanese Sashimi) was originated by Peter DeGrace. The name comes from a Japanese hardware development model (from Fuji-Xerox) and refers to the Japanese style of presenting sliced raw of fish, with the slices overlapping each other. It is also referred to as waterfall model with overlapping process or the waterfall model with feedback. Since phases in the sashimi model overlap, information of the problem spots can be acted upon during phases of the waterfall model that would typically precede others in the pure waterfall model. For example, since the design and implementation phases will overlap in the sashimi model, implementation problems may be discovered during the design and implementation phases of the development process. This helps alleviate many of the problems associated with the Big Design Up Front philosophy of the waterfall model. (Desoyo, 2010) Sashimi Waterfall model is the model used by the developers in this study. This model suggests a well-built scale of overlap between the phases of a software development life cycle. For instance, architectural design and detailed design may be partially completed before requirement study is considered complete. This approach is especially appropriate for projects requiring profitable insights into each layer as it move through their development life cycles.

An advantage of permitting overlap between the phases in the Sashimi is that issues can be discovered earlier in the software development process helping result in the minimization of re-work and a better final product. Engineers working on the design phase of a project may discover potential implementation problems prior to full production work beginning. Conversely, since the implementation phase begins prior to design going final, engineers may discover core design issues not intuitive prior to proceeding to development. The iterative method inherent within the Sashimi has been found to eliminate or reduce the cost associated with the classic Waterfall model line. (Ching, 2006) Unlike the Pure Waterfall model where complete documentation is provided to the team handling the next phase, Sashimi Waterfall Model suggests personnel continuity between phases. (DeGrace and Stahl, 1990)
Software Concepts Requirement Analysis Architectural Design Detailed Design Coding and Debugging System Testing

Figure 3.1: Sashimi Model

The developers used the sashimi model as a guide for the software design. This model allows for a stronger degree of phase overlap, suggesting the developer might well be into architectural design and detailed design before to consider requirements analysis to be complete. This project approach is reasonable for most projects which tend to gain important insights into what the developers are doing as moving through development cycles and which function poorly with strictly sequential development plans. It permits substantial reduction in documentation by providing personnel continuity between all phases. The following phase in sashimi model was discussed: Software Concepts. In this phase, developers establish the conceptual view and general definition of a project. This starting point is critical because it is essential for those who will deliver the technology, those who will use that technology, and those who have a stake in the project to reach agreement on its concept and definition In this phase, developers must comprehend and construct a generalized arrangement on how to develop good software. This include gathering of facts through direct or indirect communication between the developer and the staff of the Jesus Is Lord Church San Carlos. Requirement Analysis Phase. The requirements analysis process is intensified and focused specifically on the proposed system. To understand the nature of the programs to be built, the developer must understand the information realm for the system as well as required function, behavior performance and interfacing.

In this phase, the developers gathered requirements for the system and will documented and reviewed by the developer to come up with the system design. Architectural Design Phase. In this phase, the software requirements are transformed into definitions of software components and their interfaces, to establish the framework of the software. The developers, after the gathering all the necessary information, in this phase, will construct the possible output of the system through usage of the chosen platform. Detailed Design Phase. Once the requirement has been finalized, detailed system specification is prepared. As design work progresses, in the Sashimi model, it is common for requirements to be refined with resulting changes in the architecture as the teams work through the problem set. At the end of the phase, a solid plan will be defined for use in development and a working prototype may be created based on the project. The developer used data flow diagram to represent the flow of data through the proposed system, entity relationship diagram to represent the structure data, database instances to describe a complete database environment and lastly, the database schema to describe the tables and views in a database together with the relationship between them. Coding and Debugging Phase. This phase in sashimi model is where the designs must be translated into a machine readable form. This is where the developer must use the skills in programming in a certain problems on the detailed design the code generation step performs in this task. This phase

is also where the developer must identify and remove the bugs occurred in coding phase. The localized errors and syntax errors must be debugged in this phase. System Testing Phase. The process of performing a variety of tests on a system, to explore functionality or to identify problems. System testing is usually required before and after a system is put in place. A series of systematic procedures are referred to while testing is being performed. These procedures tell the tester how the system should perform and where common mistakes may be found. Tester usually try to break the system by entering data that may cause the system to malfunction or return incorrect information. The developers will test the functionality of the system to determine if the system is ready for deployment. Sources of Data The developers gathered information at the Jesus Is Lord Church San Carlos, through an interview with the National Area 2 Pastor, Rev., Arturo B. Velasquez Jr., the church MIS head, Carlito Parganel, and the church secretary, Analyn Palmani, the developers were able to determine the existing system in the company. Through gathering the information of the members and different certificates, and the user requirements, the design of the database and system can organized. Secondary source of data is through internet research wherein the developers were able to determine the possible hardware and software specification of the system as well as the features of the system that can be adopt by the developers. It is also through

internet research, wherein the developers were able to identify the possible features that can be included in the research. Published articles and research in the internet and the library help a lot for the developers to identify the criteria that should be included in the questionnaire to ask to the target clients to test the acceptability of the system.

Instrumentation and Data Collection Structured Interview. This is the direct verbal integration between the Head Pastor of the Jesus Is Lord Church San Carlos with the developers in order to collect information. The developers conducted a series of interviews concerning the filing and retrieving of records of the Jesus Is Lord Church San Carlos. The developers obtained a systematic flow of the existing system as well as the requirements of the proposed system. Based on the interview the developers can be able to identify the existing business process of the company. Questionnaire. The developers used questionnaire that includes the different questions that should asked to the target clients. The questionnaire is also used in getting the feedback about the system. Internet Research. The developers used this instrument to further understand the features of the system. Thus, information from the libraries is not sufficient to fulfill these goals of collecting useful varieties of information that can help in giving ideas for designing a system. Developers decided to browse into the internet to collect useful information.

Tools for Data Analysis Use Case Diagram. A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can use together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case thought of as a collection of possible scenarios related to particular goal, indeed, the use case and goal sometimes considered to synonymous. Database Schema. A database schema is a collection of meta-data that describes the relations in a database. A schema simply described as the "layout" of a database or the blueprint that outlines the way data organized into tables. Schema are normally described using Structured Query Language as a series of CREATE statements that may be used to replicate the schema in a new database. Database Instance. The term instance is typically used to describe a complete database environment, including the Relational Database Management System (RDBMS) software, table structure, stored procedures and other functionality. It is most commonly used when administrators describe multiple instances of the same database. Entity Relationship Diagram. An entity-relationship diagram is a data modeling technique that creates a graphical representation of the entities, and the relationships between entities, within the system.

Flowchart. A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem. Process operations are represented in these boxes, and arrows connecting them represent flow of control. Data flows are not typically represented in a flowchart, in contrast with data flow diagrams; rather, they are implied by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields. Weighted Mean. An average calculated by taking into account not only the frequencies of the values of a variable but also some other factor such as their variance. The weighted average of observed data is the result of dividing the sum of the products of each observed value, the number of times it occurs, and this other factor by the total number of observations.