Lecture-Week-1-4 (2).pdf

1 TECHNOLOGICAL UNIVERSITY OF THE PHILIPPINES VISAYAS Capt. Sabi St., City of Talisay, Negros Occidental College of Engineering Technology...

1 TECHNOLOGICAL UNIVERSITY OF THE PHILIPPINES VISAYAS Capt. Sabi St., City of Talisay, Negros Occidental College of Engineering Technology Office of the Program Coordinator LEARNING MODULE COMP213: Systems Analysis and Design DEPARTMENT: COMPUTER ENGINEERING TECHNOLOGY COMPILED BY: JULIUS J. VISTAR 2020 This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  i VISION The Technological University of the Philippines shall be the premier state university with recognized excellence in engineering and technology at par with leading universities in the ASEAN region. MISSION The University shall provide higher and advanced vocational, technical, industrial, technological and professional education and training in industries and technology, and in practical arts leading to certificates, diplomas and degrees. It shall provide progressive leadership in applied research, developmental studies in technical, industrial, and technological fields and production using indigenous materials; effect technology transfer in the countryside; and assist in the development of small-and-medium scale industries in identified growth center. (Reference: P.D. No. 1518, Section 2) QUALITY POLICY The Technological University of the Philippines shall commit to provide quality higher and advanced technological education; conduct relevant research and extension projects; continually improve its value to customers through enhancement of personnel competence and effective quality management system compliant to statutory and regulatory requirements; and adhere to its core values. CORE VALUES T - Transparent and participatory governance U - Unity in the pursuit of TUP mission, goals, and objectives P - Professionalism in the discharge of quality service I - Integrity and commitment to maintain the good name of the University A - Accountability for individual and organizational quality performance N - Nationalism through tangible contribution to the rapid economic growth of the country S - Shared responsibility, hard work, and resourcefulness in compliance to the mandates of the university This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  ii TABLE OF CONTENTS Page Numbers TUP Vision, Mission, Quality Policy, and Core Values……………… i Table of Contents………………………………………………………. ii Course Description………………………………………………. iii Learning Outcomes……………………………………………… iii General Guidelines/Class Rules…………………………………. iii Grading System………………………………………………….. iv Learning Guide (Week No. 1) …………………………………... 1 Introduction to Information Systems …………………….. 1 Expected Competencies ………………………………….. 1 Content/Technical Information…………………………… 1-6 Progress Check…… ……………………………………… 7 References………………………………………………… 8 Learning Guide (Week No. 2) …………………………………… 9 Approaches to Systems Development……………………… 9 Expected Competencies…………………………………… 9 Content/Technical Information …………………………… 9 - 21 Progress Check…… ………………………………………. 22 References…………………………………………………. 22 Learning Guide (Week No. 3) …………………………………….. 23 Systems Analysis Fundamentals…………………………… 23 Expected Competencies……………………………………. 23 Content/Technical Information……………………………. 23 - 30 Progress Check…… ………………………………………. 30 References…………………………………………………. 30 Learning Guide (Week No. 4) …………………………………….. 31 Information Requirements Analysis……………………….. 31 Expected Competencies……………………………………. 31 Content/Technical Information …………………………… 31 - 39 Progress Check…… ………………………………………. 40 References…………………………………………………. 40 List of References………………………………………………………… 41 About the Author/s……………………………………………………….. 42 This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  iii COURSE DESCRIPTION This course introduces established and evolving methodologies for the analysis, design, and development of an information system. Emphasis is placed on system characteristics, managing projects, prototyping, CASE/OOM tools, and systems development life cycle phases. Upon completion, students should be able to analyze a problem and design an appropriate solution using a combination of tools and techniques. COURSE OUTCOMES 1. Introduce general systems analysis concepts and principles. 2. Explain the purpose and various phases of the system development life cycle. 3. Identify system requirements of an organizational system. 4. Come up with a systems proposal using identified materials. 5. Draft a system flowchart. 6. Describe fundamental concepts related to systems analysis and design. GENERAL GUIDELINES/CLASS RULES 1. Make-up exams and quizzes will only be given with prior approval of the professor and under exceptional circumstances. For excused absences during the exam, the university policy will be followed. 2. Students are not allowed to leave the classroom once the class has started, unless extremely necessary. Students who leave the classroom without any valid reason will be marked absent. 3. Students are expected to comply strictly with the university’s rule on dress code, class tardiness and attendance. 4. Cell phones or any e-gadgets must be turned off or put in a silent mode during class hours. 5. Late homework or projects will not be accepted. Students are expected to maintain complete honesty and integrity in their academic work. Acts of academic dishonesty, such as cheating, plagiarism, or inappropriately using the work of others to satisfy course requirements, will not be tolerated and may result in failure of the affected assignments and/or failure of this class. Students with Special Needs: A student with special medical needs is advised to inform the instructor as to how he/she can best assist him/her. All information will be considered confidential. GRADING SYSTEM Evaluation of the level of performance in the learning evidences shall be based on the grading criteria as follows: This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  iv Term percentage distribution Prelim (Week No. 1 - No. 5) ………………………….……………………. 30% (Allotted Lecture Week: 4 weeks) Midterm (Week No. 6 - Week No. 9) ………………………………………. 30% (Allotted Lecture Week: 3 weeks) Finals (Week No. 10 - Week No. 14) ………………………………………. 40% (Allotted Lecture Week: 4 weeks) Assessments may be given (within the prescribed allotted week) as part of the grade of a student. Assessments in a form of either of the following: Quizzes ……………………………………….. Note: Percentage distribution will Seatwork/Assignment/Board work …………… depend on what assessments are given Practical Activity (Individual / Group) ………. on that particular inclusive week Projects ……………………………………….. equivalent to 100% (as applicable) Grading System The student will be graded according to the following: Average of examinations - 50% Average of weekly assessment - 50% Prelim Grade: (Average of Weekly Assessments from Week 1 to 4) X 0.70 + (PTE x 0.30) Midterm Grade: (Average of Weekly Assessments from Week 5 to 10) X 0.70 + (MTE x.0.30) End term Grade: (Average of Weekly Assessments from Week 11 to 14) X 0.70 + (ETE x.0.40) Final Grade: (Prelim Grade + Midterm Grade + End term Grade) / 3 The passing grade for this course is 5.0. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  v This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  1 LEARNING GUIDE Week No.: 1 TOPIC/S: INTRODUCTION TO INFORMATION SYSTEMS EXPECTED COMPETENCIES Upon completing this Learning Module, you will be able to: 1. Define what a system is and identify its components and elements. 2. Define what business systems and information systems are. 3. Identify the components in information systems. 4. List the reasons for the need of an information system. 5. Enumerate and describe each type of information systems. 6. Discuss the general system principles. 7. Identify the players in a system. 8. Identify the roles of the systems analyst. 9. Describe the knowledge and skills required of a systems analyst. CONTENT/TECHNICAL INFORMATION System Definition A system is an interrelated set of components that function together to achieve an outcome. Basically, there are three major components in every system, namely input, process, and output. In a system, the different components are connected with each other and they are interdependent. For example, human body represents a complete natural system. We are also bound by many national systems such as political system, economic system, educational system and so forth. The objective of the system demands that some output is produced as a result of processing the suitable inputs. One view shows the system as a computer system and the components that make up a computer system. The system is made up of three components: a computer, a file, and a terminal that provides an interface to the user. It also shows the connections between these three components. Theoretical approaches to systems have introduced many generalized principles. Goal setting is one such principle. It defines exactly what the system is supposed to do. Then there are principles concerned with system structure and behaviour. One such principle is the system boundary. System boundary defines the components that make up the system. Anything outside the system boundary is known as the system environment. A system can be made up of any number of subsystems. Each subsystem carries out part of the system function. Subsystems are important because they can help handle system complexity and thus improve the understanding of a system. Each subsystem carries out some part of the system goal. The subsystems communicate by passing messages between themselves. A good system will be made up of This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  2 highly independent subsystems with minimal flows between them. Minimizing flows in turn minimizes complexity and simplifies the system. There are also a number of principles concerned with system behaviour. One such important principle is feedback. Feedback is the idea of monitoring the current system output and comparing it to the system goal. Any variations from the goal are then fed back into the system and used to adjust it to ensure that it meets its goal. To do this, it is necessary to monitor the system to see if it is meeting its goal. The following are the elements of a system:  Purpose - the reason it exists or the reference point for measuring its success.  Subsystems - parts or elements which perform specified tasks that are compatible with the goals of the larger system of which these are parts.  Environment - the people, facilities, rules, policies, and regulations that surround a system.  Boundary - the perimeter or line of demarcation, between a system and the environment.  Connections - transmit the flow of material and information that coordinate the system’s components.  Control Mechanisms - rules and logic that govern the individual subsystems and the interactions among them. System Concepts Business system is a collection of policies, procedures, methods, people, machines, and other elements that interact and enable the organization to achieve its goals. Information system is a collection of interrelated components that collect, process, store, and provide as output the information needed to complete a business task. Information Systems The following are the components of an information system:  Work Practice - methods and procedures used by people and technology to perform work.  Information - can include formatted data, text, images and sounds.  People - persons, who enter, process, and use data.  Information Technology - includes hardware and software that perform one or more data processing tasks. Below are the reasons for the need of an information system:  growing size of the organization and the number of competitors  growing ability of computers to process large amount of data with great speed  dramatic increase in volumes of data generated  advances in communication technologies to permit faster data transmission  increase in pace of business transactions  much more sophisticated technology today This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  3 Types of Information Systems Organizations and individuals use different types of systems for different purposes. Here are some of the main types of information systems and their uses. Transaction Processing Systems (TPS) TPS process large amount of data for routine business activities or transactions. A transaction is an event that generates or modifies data that is eventually stored in an information system (for example, sales orders from customers, or bank deposits and withdrawals). TPS are very important for the organization since they gather all the input necessary for other types of information systems. Management Information Systems (MIS) MIS provide a standard reports for managers about transaction data. MIS work on the purposeful interaction between people and computers. It supports a broader range of organizational tasks to include not only TPS but also decision analysis and decision making. Its output information is used in decision making processes. Also, MIS help unite some of the computerized information functions of a business, although it does not exist as a structure anywhere in the business. MIS are designed to take the relatively raw data available through a TPS and convert them into a summarized and aggregated form for managers, usually in a report format. The different types of reports that can be produced include summary report, exception report, on-demand report, and ad hoc report. Decision Support Systems (DSS) DSS are Instead of providing summaries of data, as with MIS, DSS provides an interactive environment in which decision makers can quickly manipulate data and models of business operations. DSS depend on a database as a source of data. Office Automation Systems (OAS) OAS support general office work for handling and managing documents and facilitating communication. Familiar aspects of OAS include word processing, spreadsheets, desktop publishing, electronic scheduling, and communication through voice mail, email, and video conferencing. Expert Systems (ES) Expert systems (also called knowledge-based system) perform a task that would otherwise be performed by a human expert. For example, there are expert systems that can diagnose human illnesses, make financial forecasts, and schedule routes for delivery vehicles. Some expert systems are designed to take the place of human expert, while others are designed to aid them. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  4 ES are part of a general category of computer applications known as Artificial Intelligence (AI). Executive Information Systems (EIS) EIS provide a generalized computing and communication environment to senior managers to support strategic decisions. These rely on the information generated by MIS and allow communication with external sources of information. EIS are designed to facilitate senior managers’ access to information quickly and effectively. General System Principles There are a few general principles that are of particular interest to people building automated information system. These include the following: 1. The more specialized a system is, the less able it is to adapt to different circumstances. 2. The more general-purpose a system is, the less optimized it is for any particular situation. But the more the system is optimized for a particular situation, the less adaptable it will be to new circumstances. 3. The larger the system is the more of its resources that must be devoted to its everyday maintenance. 4. Systems are always part of larger systems, and they can always be partitioned into smaller systems. 5. Systems grow. This principle could not be true for all systems, but many of the systems with which we are familiar do grow, because we often fail to take it into account when we begin developing the system. Players in the System Game There are different classes of actors in an information system. These are the system stakeholders, which are classified into five groups namely:  System sponsors/owners – pay for the system to be built and operated and set the vision and priorities for the system. Thus, they view information in terms of costs and benefits to solve problems and exploit opportunities. System sponsors may also be system users and they generally come from the ranks of executives and managers.  System users – are the people who actually use the system on a regular basis to support the operation and management of the organization. They define the business requirements and expectations for the system. System users are also internal system customers and they come from all levels of the organization.  System designers – are technical specialists that translate the business requirements into a feasible technical solution. Thus, they view an information system in terms of a design blueprint to guide the construction of the final system.  System builders – are technical specialists who build, test, and deliver the information system. Thus, they view an information system in terms of the actual working hardware and software to implement the system.  System analysts – are people who determine the requirements that must be met by the information system. Roles of the Systems Analyst This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  5 The systems analyst serves as a facilitator or coach, bridging the communications gap that can naturally develop between the nontechnical system owners and users and the technical system designers and builders. There are three primary roles of the systems analyst and these are as follows:  Systems Analyst as Consultant Most of the time, the systems analyst acts as a consultant to a business and therefore, may be hired to address specific information systems issues within a business.  Systems Analyst as Supporting Expert In this role, the systems analyst draws on professional expertise concerning computer hardware and software and their uses in the business. The analysts are merely serving as a resource for those who are managing the project.  Systems Analyst as Agent of Change This is considered as the most comprehensive and responsible role of the systems analysts. They are an agent of change whenever they perform any of the activities in the SDLC and are present in the business for an extended period. Also, as an agent of change, the systems analyst advocates a particular avenue of change involving the use of information systems. Required Skills of the System Analyst Systems analysts should have a variety of special skills. They need to have an understanding on how to build an information system that requires a technical knowledge. Also, they have to understand the business they are working for and how the business uses each of the types of systems. Moreover, the systems analysts need to understand about people and the way they work because they will use the information systems. The figure below depicts the knowledge and skills required of a systems analyst. Technical Knowledge and Skills It is a requirement for systems analysts to have a technical knowledge and skills. Even if they are not involved in programming duties, it is still crucial to have an understanding of different types of technology—what these are used for, how these work, and how these are evolving. Here are the fundamentals that a systems analyst should understand:  Computers and how they work This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  6  Devices that interact with computers, including input devices, storage devices, and output devices  Communications networks that connect computers  Databases and database management systems  Programming languages Operating systems and utilities  Software packages such as Microsoft Access that can be used to develop systems  Integrated development environments (IDEs) for specific programming languages  Computer-aided system engineering (CASE) tools that store information about system specifications created by analysts and sometimes generate program code  Program code generators, testing tools, configuration management tools, software library management tools, documentation support tools, project management tools, and others Business Knowledge and Skills Systems analysts should have an understanding of the business organizations in general since the problem to be solved is a business problem. Also, systems analysts need to understand the type of organization for which they work. There are some analysts who specialize in a specific industry for their entire career (e.g., manufacturing, financial services, etc.). The reason for this is that it takes a long time to understand the problems of a specific industry. A systems analyst with deep understanding on a specific industry can solve complex problems for companies in that industry. Being familiar with a specific company also provides important guidance on system needs and changes. It would take years of experience working for a company to really understand what is going on. Here are some specifics the analyst needs to know about the company:  What the specific organization does  What makes it successful  What its strategies and plans are  What its traditions and values are People Knowledge and Skills Systems analysts need to understand a lot about people since they usually work on development teams with other employees. Thus, they should possess many interpersonal skills. An analyst spends many of their time working with people, trying to understand their perspectives on the problems they are trying to solve. It is critical that the analyst understand how people:  Think  Learn  React to change  Communicate  Work (in a variety of jobs and levels) PROGRESS CHECK: This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  7 I. Identify and match the following terminologies. Write your answer on the space/blank provided. (2 points each) ___ 8. Is a collection of policies, ___ 1. Designed to help organizational procedures, methods, people, machines, decision makers identify and choose and other elements that interact and enable between options or decisions. D the organization to achieve its goals? J ___ 2. Are people who determine the ___ 9. Can include formatted data, text, requirements that must be met by the images and sounds. F information system? I ___ 10. Support general office work for ___ 3. Provide a generalized computing handling and managing documents and and communication environment to senior facilitating communication. B managers to support strategic decisions. H ___ 4. Includes hardware and software a. System users that perform one or more data processing b. OAS tasks. E c. Connections ___ 5. Are the people who actually use d. DSS the system on a regular basis to support the e. Information Technology operation and management of the f. Information organization? A g. System designers ___ 6. Transmit the flow of material and h. EIS information that coordinate the system’s i. System analysts components. C j. Business system ___ 7. Are technical specialists that k. System sponsors translate the business requirements into a l. MIS feasible technical solution? G II. Essay RUBRIC: CRITERIA PERFORMANCE INDICATOR POINTS Content Provided pieces of evidence, supporting details, and 8 factual scenarios Grammar Used correct grammar, punctuation, spelling and 4 capitalization Organization of ideas Express the point in a clear and logical arrangement of 4 ideas in the paragraph Format Adhere to the required style/appearance 4 Total 20 1. In your own words. Explain at least one Type of Information System. Write your answer below. (20 points) This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  8 REFERENCES Satzinger, John W., Jackson, Robert B., Burd, Stephen D., (2004), Systems analysis and design in a changing world (3rd ed.), Course Technology Kendall, Kenneth E. and Kendall, Julie E., (2004), Systems analysis and design (6th ed.), Pearson Education, Inc. Hoffer, Jeffrey A., George, Joey F., Joseph S., (2005), Modern systems analysis and design (3rd ed.), Upper Saddle River, N.J. : Prentice Hall Whitten, Jeffery L., Bentley, Lonnie D., Dittman, Kevin C., (2004), Systems analysis and design methods (6th ed.), Boston : McGraw-Hill Irwin This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  9 LEARNING GUIDE Week No.: 2 TOPIC/S: APPROACHES TO SYSTEMS DEVELOPMENT EXPECTED COMPETENCIES Upon completing this Learning Module, you will be able to: 1. Define what an SDLC is. 2. List the steps in SDLC methodology. 3. Illustrate the SDLC. 4. Describe each phase in SDLC and identify its activities. 5. Compare traditional approach from object-oriented approach. 6. Explain the variations of SDLC used by systems developers. CONTENT/TECHNICAL INFORMATION Systems Development Life Cycle (SDLC) The systems development life cycle (SDLC) is a conceptual model that describes the phases involved in an information system development project, from an initial feasibility study through maintenance of the completed application. In SDLC, it is possible to complete some activities in one phase in parallel with some activities of another phase. Sometimes the life cycle is iterative; that is, phases are repeated as required until an acceptable system is found. Some people consider the life cycle to be spiral, in which we constantly cycle through the phases at different levels of detail. Also, the life cycle can be thought of as circular process in which the end of the useful life of one system leads to the beginning of another project that will develop a new version or replace an existing system altogether. Generally, an SDLC methodology follows the following steps: 1. The existing system is evaluated. Problems are identified. These can be done through system user interview and with support personnel consultation. 2. The new system requirements are defined. The problems in the existing system must be addressed with specific proposals for improvement. 3. The proposed system is designed. Plans are laid out involving physical construction, hardware specifications, operating systems, programming, communications, and security issues 4. The new system is developed. New components and programs must be obtained and installed. System users must be trained with the new system, and all aspects of performance must be tested. At this stage, adjustments must be made, if necessary. 5. The system is put into use. The new system can stepped in, according to application or location. Then, the old system is gradually replaced. 6. The new system should be evaluated once it is up and running. Maintenance must be kept up rigorously at all times. System users should be updated with the latest modifications and procedures. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  10 The figure below depicts the systems development life cycle. Planning Phase Analysis Phase Design Phase Implementation Phase Maintenance Phase Planning Phase Project planning is the process of defining clear, discrete activities, and the work needed to complete each activity within a single project. The primary objectives of this phase are:  identify the scope of the new system  ensure that the project is feasible  develop a schedule, resource plan, and budget for the remainder of the project The activities that a systems analyst perform during the project planning phase include the following:  Define the problem – define precise business problem and scope of the required solution  Confirm project feasibility – feasibility analysis is conducted  Produce the project schedule – detailed listing of tasks and activities  Staff the project – detailed listing of required staff  Launch the project – initiation of the project Analysis Phase The primary objective of the analysis phase is to understand and document the business needs and the processing requirements of the new system. This phase is basically a discovery process. The activities in this phase include the following: This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  11  Gather information – observing the users as they do their work; by interviewing and asking questions to the users; by reading existing documents about procedures, business rules, and job responsibilities; and by reviewing existing automated systems  Define system requirements – drawing diagrams to express and model the new system’s processing requirements  Build prototypes for discovery of requirements – reviewing working prototypes of alternatives  Prioritize requirements – important needs must be identified and given priority for development  Generate and evaluate alternatives – building the system in-house, buying a software package, or contracting to a third party to develop and install a new system  Review recommendations with management – recaps the results of the analysis phase activities to make decisions about an alternatives Design Phase This phase is where the technical blueprint of the system is created. The primary objective of the design phase is to design the solution system based on the requirements defined and decisions made during the analysis phase. The activities done during this phase are:  Design and integrate the network – configuring computer equipment, network, and operating system platforms that will house the new information system  Design the application architecture – consists of using the diagrams showing the system’s requirements that were developed during analysis  Design the user interfaces – consists of forms, reports, screens, and sequences of interactions  Design the system interfaces – design of the method and details of the communication between the new information system and existing system must be precisely defined  Design and integrate the database – database for the specific system must be integrated with information databases of other systems already in use  Prototype for design details – ensure that prototypes function correctly in the operating environment; test and verify alternative design strategies by building prototypes of the new systems  Design and integrate the system controls – every new system must include adequate mechanisms to protect the information and assets of the organization Implementation Phase In the implementation phase, the final system is built, tested, and installed. The objective of the activities of this phase is not only to produce a reliable, fully functional information system, but also to ensure that the users are all trained and that the organization is ready to benefit as expected from use of the system. The activities that make up the implementation phase are:  Construct software components – constructed through various techniques, development tools, and existing components This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  12  Verify and test – prototypes are used to verify different implementation strategies and to ensure that the system can handle the volumes of transactions that will exist after it is placed in production  Convert data – convert to the format required in the new system  Train users and document the system – users should understand and use the new system appropriately  Install the system – new equipment must be in place and functioning, the new computer programs must be installed and working, and the database must be populated and available Maintenance Phase The objective of the maintenance phase is to keep the system running productively during the years following its initial installation. This phase begins only after the new system has been installed and put into use, and it lasts throughout the productive life of the system. At some stage in this phase, upgrades or enhancements may be carried out to expand the system’s capabilities. The activities occur during maintenance phase are:  Maintain the system – include both fixing the errors (also known as fixing bugs) and making minor adjustments to processing requirements  Enhance the system – the company must approve and initiate an upgrade development project  Support the users – a help desk is assigned to answer users’ questions and help increase their productivity; training new users and maintaining current documentation Approaches to System Development There are two general approaches to systems development and these are:  Traditional approach  Object-oriented approach Traditional Approach Also known as structured system development, this approach includes three techniques: structured analysis, structured design, and structured programming. These techniques are sometimes called structured analysis and design techniques (SADT). A structured program is one that has one beginning and one ending, and each step in the program execution is composed of one of three programming constructs:  A sequence of program statements  A decision where one set of statements or another set of statements executes  A repetition of a set of statements This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  13 Another idea associated with structured programming is the top-down programming, which divides more complex programs into a hierarchy of program modules. One module at the top of the hierarchy controls program execution by calling lower-level modules as required. The structured design technique was developed to provide some guidelines for deciding what the set of programs should be, what each program should accomplish, and how the programs should be organized into a hierarchy. There are two main principles of structured design and these are:  Loosely coupled – each module is as independent of the other modules as possible, which allows each module to be designed and later modified without interfering with the performance of the other modules.  Highly cohesive – each module accomplishes one clear task; it is easier to understand what each module does and to ensure that if changes to the module are required, it will not affect other modules. File and database design techniques were also developed to be used along with structured design. Newer versions of structured design assume database management systems are used in the system, and program modules are designed to interact with the database. The systems analysis technique helps the developer define what the system needs to do, what data the system needs to store and use, what inputs and outputs are needed, and how the functions work together as a whole to accomplish tasks. The graphical model of the system requirements used with structured analysis is called data flow diagram (DFD). This model shows inputs, processes, storage, and outputs and the way they function together. Object-Oriented Approach The object-oriented approach views an information system as a collection of interacting objects that work together to accomplish tasks. Conceptually, there are no processes or programs and data entries or files involved in this approach. The system consists of objects, which are things in the computer system that responds to messages. The object-oriented approach includes three techniques: object-oriented analysis (OOA), object-oriented design (OOD), and object-oriented programming (OOP). Object-oriented analysis defines all of the types of objects that do the work in the system and shows what user interactions are required to complete the tasks. Object-oriented design defines all of the additional types of objects necessary to communicate with people and devices in the system, shows how the objects interact to complete the tasks, and refines the definition of each type of object so it can be implemented with a specific language or environment. Object-oriented programming includes writing of statements using a programming language to define what each type of object does. There are many variations of the systems development life cycle (SDLC). Among the common models or methodologies used are discussed in the succeeding sections of this topic. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  14 The Waterfall Model Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. This model is based on the metaphor that when one phase was finished, the development proceeds to the next phase with no turning back. The figure below depicts a traditional waterfall SDLC. Planning Phase Analysis Phase Design Phase Implementation Phase Maintenance Phase A drawback in using the waterfall model is that it does not accept the expected changes and revisions that become necessary with most projects. Once an application is in the testing phase, it is very difficult to go back and change something that was not thought of in the concept stage. Some alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), and spiral model. The Prototyping Model A prototype is an early sample, model, or release of a product built to test a concept or process. It is a term used in a variety of contexts, including semantics, design, electronics, and software programming. A prototype is generally used to evaluate a new design to enhance precision by system analysts and users. Prototyping serves to provide specifications for a real, working system rather than a theoretical one. In some design workflow models, creating a prototype (a process sometimes called materialization) is the step between the formalization and the evaluation of an idea. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  15 A prototype can also mean a typical example of something such as in the use of the derivation 'prototypical'. This is a useful term in identifying objects, behaviours and concepts which are considered the accepted norm and is analogous with terms such as stereotypes and archetypes. The word prototype derives from the Greek πρωτότυπον prototypon, "primitive form", neutral of πρωτότυπος prototypos, "original, primitive", from πρῶτος protos, "first" and τύπος typos, "impression". Basic prototype categories Prototypes explore different aspects of an intended design:  A Proof-of-Principle Prototype serves to verify some key functional aspects of the intended design, but usually does not have all the functionality of the final product.  A Working Prototype represents all or nearly all of the functionality of the final product.  A Visual Prototype represents the size and appearance, but not the functionality, of the intended design. A Form Study Prototype is a preliminary type of visual prototype in which the geometric features of a design are emphasized, with less concern for colour, texture, or other aspects of the final appearance.  A User Experience Prototype represents enough of the appearance and function of the product that it can be used for user research.  A Functional Prototype captures both function and appearance of the intended design, though it may be created with different techniques and even different scale from final design.  A Paper Prototype is a printed or hand-drawn representation of the user interface of a software product. Such prototypes are commonly used for early testing of a software design, and can be part of a software walkthrough to confirm design decisions before more costly levels of design effort are expended. Differences in creating a prototype vs. a final product In general, the creation of prototypes will differ from creation of the final product in some fundamental ways:  Material: The materials that will be used in a final product may be expensive or difficult to fabricate, so prototypes may be made from different materials than the final product. In some cases, the final production materials may still be undergoing development themselves and not yet available for use in a prototype.  Process: Mass-production processes are often unsuitable for making a small number of parts, so prototypes may be made using different fabrication processes than the final product. For example, a final product that will be made by plastic injection mouldings will require expensive custom tooling, so a prototype for this product may be fabricated by machining or stereo lithography instead. Differences in fabrication process may lead to differences in the appearance of the prototype as compared to the final product.  Verification: The final product may be subject to a number of quality assurance tests to verify conformance with drawings or specifications. These tests may involve custom inspection fixtures, statistical sampling methods, and other techniques appropriate for ongoing production of a large quantity of the final product. Prototypes are generally This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  16 made with much closer individual inspection and the assumption that some adjustment or rework will be part of the fabrication process. Prototypes may also be exempted from some requirements that will apply to the final product. Engineers and prototype specialists attempt to minimize the impact of these differences on the intended role for the prototype. For example, if a visual prototype is not able to use the same materials as the final product, they will attempt to substitute materials with properties that closely simulate the intended final materials. The Spiral Model The spiral model is an SDLC model used in information technology that combines the features of the prototyping model and the waterfall model. The model shows the life cycle as a spiral, starting in the centre and works its way around, over and over again, until the project is complete. A spiral model is illustrated in the figure below. Figure 0 Spiral Model The spiral model is intended for large, expensive, and complicated projects. The spiral model can be generalized in the following steps: 1. The new system requirements are defined in details. This involves interviewing a number of users representing all external or internal users and other aspects of the existing system. 2. An initial design is created for the new system. 3. A first prototype of the new system is constructed from the initial design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. 4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  17 5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than satisfactory final product. 6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. 7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. 8. The final system is constructed based on the refined prototype. 9. The final system is completely evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime. The advantages of using a spiral model are  Estimates of the budget and schedule become more realistic as work progresses because of the questions that have been raised  Easier to cope with the changes inherent to software development  Software engineers can start working on the project earlier rather than wading through a lengthy early design process However, a drawback of a spiral model is that estimation of budget and time are harder to judge at the beginning of the project since the requirements evolve through the process. Extreme Programming (XP) eXtreme Programming (XP) is a discipline of system development that follows a specific structure that is designed to simplify and expedite the process of developing new software. This approach was developed by Kent Beck to be used with small teams of developers who need to develop software quickly in an environment of rapidly-changing requirements. The key emphases of eXtreme Programming are its use of two-person programming teams and having a customer on-site during the development process. The relevant parts of XP that relate to design specifications are: 1. How planning, analysis, design, and construction are all fused into a single phase of activity, and 2. Its unique way of capturing and presenting system requirements and design specifications. With XP, all phases of the life cycle link into a series of activities based on the basic processes of coding, testing, listening, and designing. In XP, coding and testing are related parts of the same process, which means the programmers who write the code can also develop the tests. The overall philosophy of XP is that code will be integrated into the system it is being developed for and tested within a few hours after it has This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  18 been written. When all the tests run successfully, then proceed with the development. Otherwise, the code is reworked until the tests are successful. Another part of XP that makes the code-and-test process work smoothly is the practice of pair programming. This means that two programmers work together on the problem they are trying to solve, exchanging information and insight, and sharing skills. The advantages of pair programming practice are:  More and better communication among developers  Higher levels of productivity  Higher-quality code  Reinforcement of the other practices in XP, such as the code and-test discipline However, there are several potential drawbacks of XP and these include:  Problems with unstable requirements  No documented compromises of user conflicts  Lack of an overall design specification or document The Unified Process (UP) The Unified Process is an object-oriented system development methodology offered by Rational Software, which was recently acquired by IBM. In addition to providing several unique features, UP uses UML (a standard modelling notation for OO approach) for system models. The UP is designed to reinforce six “best practices” for system development that are common to many system development methodologies. These are:  Develop iteratively  Define and manage system requirements  Use component architectures  Create visual models  Verify quality Control changes There are four phases under UP and these include: 1. Inception – defines the scope of the project by specifying use cases 2. Elaboration – focuses on several iterations that take part of the system and define the requirements, design the solution, and implement the solution 3. Construction – continue to build the system using additional iterations that also include requirements, design, and implementation 4. Transition – turn the system over to the end users and focus on end-user training, installation, and support These four phases of the UP are different from the traditional SDLC because they do not define generic analysis, design, and implementation phases. Rather, they define the project sequentially by indicating the emphasis of the project team at any point in time. The UP defines disciplines within each phase to make iterative development manageable. These include This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  19 business modelling, requirements modelling, design, implementation, testing, deployment, configuration and change management, and project management. Also, the UP defines roles played by developers and models created during the project. Usual roles include designer, use case specified, systems analysts, implementer, and architect. Agile Modelling Popularized by Scott Ambler, agile modelling is a practice-based methodology for modelling and documentation of software-based systems. This is proposed to be a collection of values, principles, and practices for modelling software that can be applied on software development project in a more flexible manner than traditional modelling methods. The following are core practices of the agile modelling:  Iterative and Incremental Modelling – Apply the right models, create several models in parallel, and model in small increments.  Teamwork – Model with others, get active stakeholder participation, encourage collective ownership, and display models publicly.  Simplicity – Create simple content, illustrate models simply, and use the simplest modelling tools.  Validation – Consider testability, and then prove the model is right with code. A typical agile modelling process would go like:  Listen for user stories from the customer.  Draw a logical workflow model to gain an appreciation for the business decisions represented in the user story.  Create new user stories based on the logical model.  Develop some display prototypes. In doing so, show the customer what sort of interface they will have.  Using feedback from the prototypes and the logical workflow diagrams, develop the system until you create a physical data model. Rapid Application Development (RAD) Rapid application development is a system development methodology that emphasizes speed of development through extensive user involvement in the rapid, iterative, and incremental construction of a series of functioning prototypes of a system that eventually evolves into the final system (or a version). This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  20 This figure is a conceptualization of James Martin’s original RAD phases. Requirements Planning User Design Construction Cutover In the requirements planning phase, high-level users decide on what functions the application should feature. In the user design phase, the users are characterized as being engaged in discussing the non- technical design aspects of the system, with the assistance of the analysts. In the construction phase, any designs that were created in the previous phase are further enhanced with RAD tools. The analysts are able to make continuous changes in the design of applications using these RAD tools. In the cutover phase, the old application will be replaced with the new one. The newly developed application is tested, users are trained, and organizational procedures are changed before the cutover occurs. Consider using RAD when:  The team includes programmers and analysts who are experienced with it  There are pressing business reasons for speeding up a portion of an application development  Working with a novel ecommerce application and the development team believes that the business can sufficiently benefit over their competitors from being an innovator if this application is among the first to appear on the Web  Users are sophisticated and highly engaged with the organizational goals of the company The RAD methodology has several advantages:  It is useful for projects in which the user requirements are uncertain or imprecise.  It encourages active user and management participation, which increases end-user enthusiasm for the project. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  21  Projects have higher visibility and support because of the extensive user involvement throughout the process.  Errors and omissions tend to be detected earlier in prototypes than in system models.  The iterative approach is a more “natural” process because change is an expected factor during development. There are also disadvantages of the RAD approach. These are as follows:  RAD prototypes  A RAD-based prototype may discourage analysts from considering other, more useful technical alternatives.  The emphases on speed can adversely impact quality because of ill-advised shortcuts through the methodology. Joint Application Development (JAD) Joint application development is a systems development methodology that involves the client or end users in the design and development of an application, through a succession of collaborative workshops called JAD sessions. Participants of these sessions would typically include a facilitator, end users, developers, observers, mediators, and experts. This methodology was developed in the late 1970s by Chuck Morris and Tony Crawford, which were both from IBM. In comparison with the Waterfall model, the JAD approach is thought to lead to faster development times and greater client satisfaction, since the client is involved throughout the development process. Alternatively, in the traditional approach, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews. A variation on JAD is the RAD which attempts to create an application more quickly through strategies that include fewer formal methodologies and reusing software components. A major advantage of JAD is that allows for the simultaneous gathering and consolidating of large amounts of information. However, a drawback of JAD is that it opens up a lot of scope of inter-personal conflict. PROGRESS CHECK This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  22 RUBRIC: CRITERIA PERFORMANCE INDICATOR POINTS Content Provided pieces of evidence, supporting details, and 8 factual scenarios Grammar Used correct grammar, punctuation, spelling and 4 capitalization Organization of ideas Express the point in a clear and logical arrangement of 4 ideas in the paragraph Format Adhere to the required style/appearance 4 Total 20 I. Essay Discuss and differentiate at least 2 SDLC Models. Minimum 400 words. Write your answers below. (20 points) REFERENCES Retrieved March 7, 2020, http://en.wikipedia.org/wiki/Spiral_model Retrieved March 10, 2020, http://en.wikipedia.org/wiki/Prototyping Retrieved April 1, 2020, http://en.wikipedia.org/wiki/Agile_Modeling Satzinger, John W., Jackson, Robert B., Burd, Stephen D., (2004), Systems analysis and design in a changing world (3rd ed.), Course Technology Hoffer, Jeffrey A., George, Joey F., Joseph S., (2005), Modern systems analysis and design (3rd ed.), Upper Saddle River, N.J. : Prentice Hall LEARNING GUIDE This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  23 Week No.: 3 TOPIC/S: SYSTEM ANALYSIS FUNDAMENTALS EXPECTED COMPETENCIES Upon completing this Learning Module, you will be able to: 1. List three general driving forces of project initiation. 2. Discuss each area of feasibility. 3. Identify the elements of feasibility analysis. 4. Describe project scheduling using WBS, PERT/CPM, and Gantt chart. CONTENT/TECHNICAL INFORMATION Project Initiation Information system development projects are initiated for several reasons. There are three general driving forces and these are: 1. To respond to an opportunity 2. To resolve a problem 3. To conform to a directive Most companies continue to look for ways on how to increase their market share or to open up new markets. One way these companies create opportunities is through strategic plans, which is both short term and long term. An optimal way to identify new projects is through planning. The advantage of this approach is that it provides a more stable and consistent environment in which to develop new systems. Projects are identified, prioritized, and scheduled as strategic plans are developed. Projects are initiated to solve immediate business problems. These projects try to close the gap between what information processing is required to run the business correctly and what is currently in operation. They can be initiated as part of a strategic plan but more commonly are requested by middle managers to resolve some difficulty in company operations. Projects are initiated to respond to outside directives. One common outside pressure is legislative changes that require new information gathering and external reporting requirements (such as changes in tax laws and labour laws). Furthermore, legislative changes can expand or contract the range of services and products that an organization can offer in the market. Latest laws and regulations can affect the strategic plan which results in an expedited need for new systems. These regulatory changes can be seen in the telecommunications industry, with cable TV and telephone companies competing for opportunities to provide cellular services, Internet access, and personalized entertainment. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  24 Project Feasibility According to Pressman, all projects are feasible given unlimited resources and infinite time. Unfortunately, most of the projects must be developed within tight budgetary and time constraints. During project feasibility, the project manager answers questions such as, “Are the expected benefits reasonable?” and “Are the assumed costs realistic?” A required activity for all information system projects is to assess project feasibility. The objective of this activity is to determine whether a development project has a reasonable chance of success. Feasibility analysis basically identifies all the risks of failure. A project team considers the original assumptions and identifies other risks that could endanger the success of the project. The team identifies first those risks and then establishes plans and procedures, if necessary, to make sure that these risks don’t interfere with the project’s success. If the team thinks that there are serious risks that could affect the project, the members should discover and evaluate them immediately. Economic Feasibility Economic feasibility is the process of identifying the financial benefits and costs associated with a development project. This consists of two tests: 2. Is the anticipated value of the benefits greater than projected costs of development? 3. Does the organization have adequate cash flow to fund the project during the development period? A determination of the economic feasibility of the project always requires a thorough cost- benefit analysis. Cost-benefit analysis is the analysis to compare costs and benefits to see whether investing in the development of a new system will be beneficial. When developing a cost-benefit analysis, it requires a three-step process. 1. Estimate the anticipated development and operational costs. Development costs are those that are incurred during the development of the new system. Operational costs are those that will be incurred after the system is put into production. 2. Estimate the anticipated financial benefits. Financial benefits are the expected annual savings or increases in revenue derived from the installation of the new system. 3. The cost-benefit analysis is calculated based on the detailed estimates of costs and benefits. Frequent error that most inexperienced analysts make during cost-benefit analysis is to try to do the calculations before thoroughly defining costs and benefits. Generally, benefits can be viewed as tangible and intangible. Tangible benefits refer to items that can be measured or estimated quantitatively and that accrue to the organization. Examples of tangible benefits include reduced personnel expenses, lower transaction costs, or higher profit margins. Intangible benefits may have direct organizational benefits, such as the improvement of employee morale, or they may have broader societal implications, such as the reduction of waste creation or resource consumption. In parallel with benefits, an information system can have both tangible and intangible costs. Tangible costs refer to items that you can easily measure or estimate quantitatively and with This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  25 certainty. While intangible costs are those items that you cannot easily measure in terms of quantity and with certainty. There are three popular techniques to assess economic feasibility and these are the following:  Net Present Value (NPV) The two concepts behind NPV are that all benefits and costs are calculated in terms of today’s present value and that benefits and costs are combined to give a net value. The objective of NPV is to determine a specific value based on a predetermined discount rate.  Payback Period Also called the breakeven point, is the point in time at which the increased cash flow (benefits) exactly pays off the costs of development and operation.  Return On Investment (ROI) This is a measure of the percentage gain from an investment such as a new system. The objective of the ROI is to calculate a percentage return (like an interest rate) so that the costs and the benefits are exactly equal over the specified time period. The Time Value of Money (TVM) is the concept that should be applied to each technique. This refers to the concept of comparing present cash outlays to future expected returns. Technical Feasibility A large part of determining resources has to do with assessing technical feasibility. The purpose of assessing technical feasibility is to gain understanding of the organization’s ability to construct the proposed system. Technical feasibility should include an assessment of the development group’s understanding of the possible target hardware, software, and operating environments to be used as well as system size, complexity, and the group’s experience with similar systems. Operational Feasibility Operational feasibility is the process of assessing the degree to which a proposed system solves business problems or takes advantage of business opportunities. This is a measure of how well the solution will work in the organization. Also, this is a measure of how people feel about the system/project. Operational feasibility is dependent on the human resources available for the project and involves projecting whether the system will operate and be used once it is installed. Schedule Feasibility The purpose of assessing schedule feasibility is for systems analyst to gain understanding of the likelihood that all potential time frames and completion date schedules can be met and that meeting these dates will be sufficient for dealing with the needs of the organization. Schedule feasibility is a measure of how reasonable the project timetable is Resource Feasibility The project team must assess the availability of resources for the project. The most important resource consists of the members of the team. In developing projects, it requires the involvement of systems analysts, system technicians, and users. At necessary times, some This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  26 required people may not be available to the team. Another risk to consider here is that the people who are assigned may not have the essential skills for the project. Other resources needed for a project to be successful include adequate computer resources, physical facilities, and support staff. Feasibility Analysis Feasibility analysis is the process by which feasibility is measured. It is designed to determine whether or not a project will be successful. A feasibility analysis may be conducted for a project with an emphasis on financial feasibility, environmental integrity, cultural acceptability, or political viability. It is a determination as to the likelihood of success and a description of how that determination was achieved. In general terms, the elements of a feasibility analysis for a project should cover the following:  Need analysis – This implies recognition of a need for the project. The need may affect the organization itself, another organization, the public, or the government. A preliminary study is then conducted to confirm and evaluate the need. A proposal of how the need may be satisfied is then made.  Process work – This is the preliminary analysis done to determine what will be required to satisfy the need. The work may be done by a consultant who is an expert in the project field. The preliminary study often involves system models or prototypes. A simulation of the proposed system can be carried out to predict the outcome before the actual project starts.  Engineering and design – These involve a detailed technical study of the proposed project. Written quotations are obtained from suppliers and subcontractors as needed. Technology capabilities are evaluated as needed. If necessary, product design should be done at this time.  Cost estimate – This involves estimating project cost to an acceptable level of accuracy. Both initial and operating costs are included in the cost estimation.  Financial analysis – This involves an analysis of the cash flow profile of the project. This should consider rates of return, inflation, sources of capital, payback periods, breakeven point, and residual values. Moreover, this analysis determines whether or not and when funds will be available to the project.  Project impacts – This provides an assessment on how much impact the proposed project has. Some of the factors that will determine how a project is perceived by the public include environmental, social, cultural, political, and economic impacts. Also, the value added potential of the project should be assessed.  Conclusions and recommendations – The feasibility study should end with the overall outcome of the project analysis. This may indicate an endorsement or disapproval of the project. A recommendation on what should be done is included in the feasibility report. Project Scheduling Project scheduling determines the order in which activities will be performed, setting start and end times for each activity, and assigning specific tasks to team members. The activity of developing project schedule is one of the most difficult efforts of the project planning phase, yet it is one of the most important. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  27 Work Breakdown Structure A work breakdown structure (WBS) is a hierarchy of phases, activities, and individual tasks that are required to complete the project. This is important in planning and executing the project since it is the foundation for developing the project schedule, for identifying milestones in the schedule, and for managing cost. WBS is developed before dependencies are identified and activity durations are estimated. This can be used to identify the tasks in PERT diagram. Since the WBS is a hierarchical structure, it may be conveyed in outline form: Each organization uses its own terminology for categorizing WBS components according to their level in the hierarchy. Some organizations refer to different levels as tasks, subtasks, and work packages, as depicted in the outline above. While others use the terms phases, entries, and activities. It is somehow difficult to develop a WBS from scratch. The project team can meet to brainstorm and try to think of everything that it needs to complete the project. This meeting is a type of bottom-up approach— brainstorm for each single task and make sure to cover everything. The major advantage of a good WBS is that it provides the most accurate estimate for the duration and effort required for the project. Also, schedules built from a good WBS are much easier to monitor and control. Therefore, WBS is a key to a successful project. PERT/CPM Diagram PERT is an acronym for Program Evaluation and Review Technique and CPM stands for Critical Path Method. Formerly these were two distinct techniques, however recently these were merged into a single scheduling technique. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  28 PERT/CPM is a diagram of all the tasks identified in the WBS, illustrating the sequence of dependencies of the tasks. This begins with the list of activities and tasks developed in the WBS. The WBS is analysed, including the duration and expected resources for each task, to determine the dependencies. For every task, the chart identifies all the immediate predecessor tasks and the successor tasks. The figure below is an example of a PERT/CPM diagram. The critical path is the longest path through the PERT/CPM diagram and contains all the tasks that must be done in the defined sequential order. It is called critical path since if any task on the critical path is delayed, the entire project will be completed late. The tasks on critical path are monitored very carefully by project managers. There are rules in PERT/CPM diagram and these are the following:  Each activity must be represented by its own branch on the chart.  Direction of time flows is indicated by arrows. An activity line meeting an event node indicates activity completion. The length of an activity branch is not representative of the time the activity will take.  Relationships between activities are determined by the sequence of the branches.  If several activities terminate at one node, no activities starting at that node may begin until all entering activities are completed.  For analysis reason, no two activities are allowed to both start and end at the same nodes. If the project network would seem to require this, a dummy activity must be inserted. A dummy activity has no time; it merely preserves the proper sequencing in the network design. One of the advantage of the PERT/CPM technique is that it produces a diagram that makes it easy to see dependencies and the critical path. Though it is not easy to view the project’s This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  29 progress on a PERT chart. A different chart is used in viewing the activities spread out over a calendar and this is called a Gantt chart. There are also disadvantages of PERT/CPM and these are the following:  There can be potentially hundreds or thousands of activities and individual dependency relationships.  The lack of a timeframe on most PERT/CPM charts makes it harder to show status although colours can help (e.g., specific colour for completed nodes).  When the PERT/CPM charts become unwieldy, they are no longer used to manage the project. Gantt Charts Developed in 1917 by Henry Gantt, a Gantt chart is a bar chart that represents the tasks and activities of the project schedule. This chart is good for monitoring the progress of the project as it moves along. The Gantt chart below shows three kinds of schedule dependencies (in red) and percent complete indications. The major advantage of the Gantt chart is its simplicity. The systems analyst will not only find this technique easy to use, but also it lends itself to worth-while communication with end users. Another advantage of Gantt chart is that the bars representing activities or tasks are drawn to scale—that is, the size of the bar indicates the relative length of time it will take to complete each task. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  30 PROGRESS CHECK RUBRIC: CRITERIA PERFORMANCE INDICATOR POINTS Content Provided pieces of evidence, supporting details, and 8 factual scenarios Grammar Used correct grammar, punctuation, spelling and 4 capitalization Organization of ideas Express the point in a clear and logical arrangement of 4 ideas in the paragraph Format Adhere to the required style/appearance 4 Total 20 I. Essay. Write your answers below. 1. What is the purpose of the cost-benefit analysis used to assess economic feasibility? (20 points) 2. When is a PERT/CPM diagram useful for systems projects? (20 points) 3. What is the difference between a PERT/CPM diagram and a Gantt chart? (20 points) REFERENCES Satzinger, John W., Jackson, Robert B., Burd, Stephen D., (2004), Systems analysis and design in a changing world (3rd ed.), Course Technology Kendall, Kenneth E. and Kendall, Julie E., (2004), Systems analysis and design (6th ed.), Pearson Education, Inc Hoffer, Jeffrey A., George, Joey F., Joseph S., (2005), Modern systems analysis and design (3rd ed.), Upper Saddle River, N.J. : Prentice Hall Whitten, Jeffery L., Bentley, Lonnie D., Dittman, Kevin C., (2004), Systems analysis and design methods (6th ed.), Boston : McGraw-Hill Irwin This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  31 LEARNING GUIDE Week No.: 4 TOPIC/S: INFORMATION REQUIREMENTS ANALYSIS EXPECTED COMPETENCIES Upon completing this Learning Module, you will be able to: 1. List the general steps conducted in information gathering. 2. Describe each method used in information gathering. CONTENT/TECHNICAL INFORMATION Information Gathering Information gathering is used to discover business information details to define the information structure. This helps systems analysts to establish the priorities of the information needs and further leads to opportunities that highlight key issues which may cross functional boundaries or may touch on policies or the organization itself. Information gathering is a complicated task especially in a large and complex system. Therefore, this must be organized to ensure that nothing is overlooked and all system details are eventually captured. The following are the general steps conducted in information gathering:  Schedule initial visit to user site  Gather and read background materials  Establish data gathering objectives  Determine what data gathering techniques to use  Identify contact persons  Schedule data gathering activities  Assign to data gathering teams  Identify deliverables Methods for Information Gathering The core of systems analysis is the collection of information. The systems analysts must collect information about the information systems that are currently being used and how the users would like to improve the current systems and organizational operations with new or replacement information systems. One of the best ways to get this information is to talk to the people who are directly or indirectly involved in the different parts of the organizations affected by the possible system changes, such as users, managers, etc. Other way to find out about the current system is to gather copies of documentation relevant to current systems and business processes. The figure below illustrates the relationship between information gathering and model building. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  32 As shown in the figure above, the focus of analysis activities nowadays is to develop a set of logical system requirements for the new system as soon as possible. The system analyst develops the logical model of the new system as they gather information. Then, the project team constructs the physical model (how the system will be built) as part of system design. There are several methods that a system analyst can use in gathering information. All these methods have been proven to be effective, though some are more efficient than others. That is why in most cases, analysts tend to combine methods to increase both their effectiveness and efficiency. The most commonly used methods are the following”:  Review existing reports, forms, and procedure description  Conduct interviews and discussion with users  Observe and document business processes  Distribute and collect questionnaires  Conduct joint application design (JAD) sessions Review Existing Reports, Forms, and Procedure Description Review of documentation helps identify business rules that may not come up in the interviews. Written procedures help discover discrepancies and redundancies in the business processes. But procedure manuals are not frequently kept up-to-date, and these include errors. To make sure that assumptions and business rules derived from existing documentation are correct, the analysts should review them along with the users. There are two sources of information for existing procedures and forms. These are: 1. External to the organization—at industry-wide professional organizations and at other companies 2. Existing business documents and procedure description within the organization Information obtained from other companies is a potential source of important information. Industry journals and magazines sometimes report the findings or “best practices” studies. This module is a property of Technological University of the Philippines Visayas and intended for EDUCATIONAL PURPOSES ONLY and is NOT FOR SALE NOR FOR REPRODUCTION.  33 Furthermore, with systems crossing organization boundaries more and more, external sources are an important source of system requirements. The existing business documents and procedure description within the organization serves two purposes. First, it is a good way to get a preliminary understanding of the processes. The analysts need to learn about the industry or the specific application that they are studying. They ask users to provide copies of the forms and reports that they currently are using. Also, they request copies of procedural manuals and work descriptions. The review of these materials provides an understanding of the business functions. They also form the basis for the development of detailed interview questions. Second, it is in the interviews themselves. Forms and reports can serve as visual aids for the interview, and the working documents for discussion. Discussion can focus on the use of each form, its objective, its distribution, and its information content. In addition, the discussion should contain specific business events that initiate the use of the form. It is also helpful to have forms filled with real information to ensure that the analyst obtains the correct understanding of the fields and data content. Conduct Interviews and Discussions with Users An information gathering interview is a directed conversation with a specific purpose that uses a question-and-answer format. During the interview, the analysts want to get the opinions of the interviewee and his or her perspectives about the current state of the system, organizational and personal goals, and informal procedures. To conduct an effective interview, a system analyst need to organize in three areas: 1. Prepare for the interview 2. Conduct the interview 3. Follow-up the interview Prepare for the Interview There are five major steps in preparing for the interview. These are the following: 1. Read background material – Read and have an understanding of the background information of the interviewees and their organization. Be particularly sensitive to the language the organizational members use in describing themselves and their organization. 2. Establish interviewing objectives – Know what you want to accomplish with the interview. Write down the objective so that it is firmly established in your mind. 3. Decide who to int