1. Transaction Processing Systems and System Development Life Cycle

2. 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

3. 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

4. TPS vs. MIS/DSS and AI/ES

5. 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

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

7. 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

8. 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

9. 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.

10. Traditional SDLC Investigation Analysis Design Implementation
Maintenance and Review

11. 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?

12. 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?

13. 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.

14. 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”

15. 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

16. 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.

17. 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

18. 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.