Transaction Processing Systems and System Development Life Cycle

An organization's transaction processing systems (TPSs) must support the routine, day-to-day activities that occur in the normal course of business and help a company add value to its products and services

TPS–Transaction Processing Systems Process detailed data for fundamental business operations Provides data for the MIS/DSS/AI/ES systems On-line Transaction Processing (OLTP) – transaction is processed immediately Batch Processing – transactions are accumulated and processed at one time Large amounts of input and output w/o complex or sophisticated programming. When you work in a business, TPS systems will be the ones you work with the most. OLTP customer changes name, address, pays a bill, etc. Batch payroll gets timecards but processes the data bi-weekly or weekly to create checks Can be more cost-effective

TPS vs. MIS/DSS and AI/ES

Transaction Processing Cycle Basic data processing activities… Data Collection: capture all necessary data Data Editing: check for validity of data Data Correction: prompt for reentry of data Data Manipulation: perform any necessary calculations on data Data Storage: update database with data Basic data processing activities… Data Collection: capture all necessary data Can be done manually or using special input devices (scanners, etc.) Data Editing: check for validity of data Ex: Check for entry of letters in a price or # of hours field Ex: Check that stock number exists Data Correction: prompt for reentry of data Once the error has been detected in “Data Editing”, a prompt should be given explaining the problem Data Manipulation: perform any necessary calculations on data Supermarket: scan one product, clerk enters that 4 have been purchased, TPS will determine final price for all four. And will determine total at the end Data Storage: update database with data Once it is stored in database, can be exported into other systems (MIS/DSS/AI/ES) for further analysis

SDLC Systems Development Life Cycle Careers are made and taken away based on the outcome of system development.

Who are the players in SDLC? Business: Stakeholders: employees who should benefit from the system Users: employees using the system Business Owners: employees playing an active role in developing the system

Who are the players in SDLC? IT: Manager: Ultimately responsible for system. Handles Funding Communication with upper level management Resolves major issues Can manage several systems at any point in time Project Lead: Head systems analyst Reports to manager Manages all day to day activity for system Determines schedule (could be determined by outside forces) Main contact for stakeholders and users

Who are the players in SDLC? IT (cont): Systems Analyst: Specializes in analyzing business problems and designing a system to resolve problems. Programmer: Builds and modifies programs based on direction of systems analyst and project lead.

Traditional SDLC Investigation Analysis Design Implementation Maintenance and Review

SDLC – Step 1: Investigation What is the problem and is it worth solving? Feasibility study may be created by IT Short, Inexpensive study Objective: Define scope of problem, cost vs. benefits technical, operational, schedule, economic, legal feasibility End Result: Systems Investigation report Continue on with project? Modify project? Drop it? Methods: IT interviews business employees and observes current system and processes Systems Request Form: Filled out by someone in the business who wants IT to start investigating Problems / opportunities Objectives, Overview of what is necessary Expected costs and benefits CONED had Application Planning Sessions in Summer for the next year. Feasibility Technical – hardware, software, etc. can be acquired Operational – acceptance of change, considerations Schedule – can project be completed in a reasonable amount of time Economic – cost vs. benefits. Does it make sense $$$ wise? Legal – any laws or regulations that may limit the system?

SDLC – Step 2: Analysis Most critical step What must the system do to solve the problem? Objectives: Detailed business/functional requirements End Results: Logical requirements (Data Model, Flowcharts, expected volume, etc.) Methods: Interviews, Data Collection and Analysis, Data-flow diagrams Everyone must spend the necessary time here, planning is everything. All parties should review results (IT and Business). NO CHANGES SHOULD BE MADE TO THE SPECS AFTER THIS!!! Interviews Asking Directly: asks users stakeholders and other managers what they want and expect from the system Many people do not know exactly what they want or cannot put it into words. Especially if there is not something they can compare it to (Prototype helps here) Determine Critical Success Factors: What is critical to the success of your organization?

SDLC – Step 3: Design How will the system solve the problem? Objective: Develop detailed technical specifications for hardware, software, database, etc. End result: Make or buy? RFP (Request for Proposal) Program, interface and response time specs Methods: IT uses technical knowledge to create requirements. Small amount of input from business organization. Freeze is placed on Design. Technical specifications design Hardware Design Software Design Database Design Telecommunications Design Personnel Design Procedure and control design MAKE/BUY – talk about ethics for computer analysts – accepting gifts, etc. If a large amount of new hardware/software is needed a RFP should be created… RFP (Request for Proposal) specifies requirements for hardware and software Provided to companies so they can bid on providing what is needed.

SDLC – Step 4: Implementation Objective: A system delivered to the business users End result: System works correctly, users are trained IT will provide status updates to Business Any changes made to the system during this phase will need more time/money. “Given time and money, anything is possible”

Phases of Implementation Purchase of Hardware/Software Programming Testing (Initially by IT and then by Business users) Training (Done by IT and Business users) Conversion from old to new system: Direct Cutover (manual work may also be done as a fail-safe) Phased In (most critical components first) Pilot (released to one area at a time) Parallel (old and new run together for a short time) Direct Cutover (manual work may also be done as a fail-safe) Least desirable because of potential for problems and errors Phased In (most critical components first) When everyone is confident the system is performing correctly, the old system is phased out Pilot (released to one area at a time) Parallel (old and new run together for a short time) Output of old is compared closely with output of new. When everyone is comfortable with output, old system is eliminated

SDLC – Step 5: Maintenance/Review Objective: Fix “Bugs”, add enhanced functions End Result: Fully functional system User acceptance document Need to watch for changing business environment. Any enhanced functions should follow through the SDLC. During WWI, Grace Hopper went to investigate a computer that was no longer calculating data correctly. She found a moth caught inside of the computer. Grace Hopper was familiar with the earlier uses of the term "bug" for a problem in a system, used the term facetiously in reference to the moth, and that this helped popularize the term in the computer world. Thomas Edison used the term "bugs" as early as 1878, for flaws in a system. It was a common "shop" term even in Edison's time for such systems faults. Why "bug" was used for "fault" may be induced from the fact that the term appeared as early as the 14th cent. to mean "an object of dread“ Cost of Maintenance – WHO DOES IT? Maintenance costs could be 5 times more then it originally cost to develop Reasons for maintenance: changes in business processes new requests from stakeholders, users, and managers bugs or errors in the program technical and hardware problems corporate mergers and acquisitions government regulations change in the operating system or hardware on which the application runs. REVIEW: Event-driven review: review done when problem or opportunity occurs Error, corporate merger , new market for products Time-driven review: done every 6 months, year, 2 years, etc.

Other things to consider… Prototyping: Portions of the system are developed May not be fully functional Feedback from users provides future direction Rapid Application Development (RAD): Uses tools and techniques designed to speed development JAD (Joint application development) involves heavy interaction of users and analysts. RAD: based on empowerment of workers/users structure the user participation in the design process A variety of techniques for incorporating user participation in the design process

CASE Tools CASE: Computer-Aided Software Engineering Tools that automate tasks in SDLC Upper-CASE tools: Aid in early stages of SDLC (investigation, analysis and design) Lower-CASE tools: Aid in later stages of SDLC (development, maintenance). Can generate code Integrated-Case tools: Provide links between upper and lower. Can generate code based on data from analysis and design. Enforce adherence to the SDLC Pass out case study on page 317 of book.