1. BUILDING INFORMATION SYSTEMS
CHAPTER 11
BUILDING INFORMATION SYSTEMS

2. Organizational Change (1)
Reengineering systems happens at several “levels”
At each level
There is some degree of risk
There is some expected return

3. Organizational Change (2)
Automation (low risk / return)
We put in a new POS system to replace old cash registers
Many tasks have already been automated
We are automating tasks without changing processes

4. Organizational Change (3)
When automating an organization may find that existing procedures no longer work
We therefore make improvements to existing procedures
Using TQM / ISO900 / CMMI

5. Organizational Change (4)
This might lead to a complete overhaul of procedures
Processes get redesigned
Workflows get redesigned
Ford cut AP staff by 75%
Used an ERP for PO and receiving
In a paradigm shift, we change the nature of the business

6. Introduction to the Systems Approach
It’s methodology for problem solving
The more time spent planning, the better the outcome
Note the process is typically iterative
Systems approach masters
Ed Yourdon
Grady Booch
The GOF
Gamma, Helm, Johnson, Vlissides

7. The Systems Approach (Steps)
Problem identification (planning)
Systems analysis
Systems design
Systems development
Systems testing
Systems deployment (implementation)
Systems maintenance

8. The Systems Approach (Problem Identification)
An existing system does not meet a need or expectation
Conduct feasibility studies
If a project seems feasible, assemble a project management plan and team

9. The Systems Approach (Feasibility Domains)
Organizational
Do we have the human resources
Do we have the organizational resources
Technical
Does the hardware / software exist
Economic
Cost / benefit analysis
Accounting ROI
Present value analysis
Operational

10. The Systems Approach (Systems Analysis)
Analyze information needs of constituents
Develop a system’s functional requirements
Analysis tools
Brainstorming
Lateral thinking

11. The Systems Approach (Systems Analysis)
Develop a list of functional requirements
User interface requirements
Processing requirements
Storage
Controls
Input validation
Event notification
Human controls

12. The Systems Approach (Systems Design)
We need to completely understand the existing system
If it’s not broke, don’t fix it
Understand how users use the existing system
Interviews
Know what users want out of the new system
At times, users don’t know what they want

13. The Systems Approach (Systems Design)
Logical design
Design how the system will work
Design workflow and information flow
Design the user interface
Screen diagrams
Navigation diagrams
Appropriate use of color
Data design
Entity relationship diagrams

14. The Systems Approach (Systems Design)
Process design
Tools
Flowcharts
IP charts
UML use-case diagrams
UML activity diagrams
UML Statechart diagrams

15. The Systems Approach (Systems Design)
Physical design
Select physical hardware and software
Note that there may be site preparation requirements

16. The Systems Approach (Development)
Hardware and software acquisition
Use RFPs and RFQs to evaluate alternatives
Hardware and software benchmarking
Decisions
Make vs. buy
Lease vs. buy
Internal implementation or outsourcing
Documentation
For users
For IS staff
Preserve organizational memory

17. End User Development Positives Negatives Users get what they want
Users don’t know what they want
Users may have a narrow minded vision of the system
They may not see how a system contributes to the organizational mission
Loss of centralized control
Users are not experienced in system design methodologies

18. Testing My rule is, you cannot ever test too much or be too thorough

19. The Systems Approach (Deployment)
User training
Data conversion
Systems testing
Parallel (run 2 systems at once)
Pilot study (deploy in limited sited)
Phased (deploy functionality in stages)
Plunge (only fools rush in)
Systems deployment

20. The Systems Approach (Maintenance)
Perform a postimplementation audit to determine whether goals were met
Revise system as necessary

21. Development Methodologies (1)
Waterfall
The systems lifecycle operates as a sequence of states
Sequential development

22. Development Methodologies (2)
Agile processes and iterative development
Break a large project into several small projects
Deliver results in small stages

23. Development Methodologies (3)
Extreme programming
It’s an agile methodology at its best
Relies on close communication between users and developers
Relies on experienced developers
Uses small incremental deliverables

24. Development Methodologies (4)
Scrum delivers small software pieces every 30 days
The term derives from the game of rugby
The development effort is monitored and controlled daily
Some organizations use a combination of these methodologies

25. Waterfall (Illustration)

26. Scrum (Illustration)

27. Successful Software Development Metrics
Control costs – Don’t keep throwing money at a bad project
Avoid scope creep and feature creep
Test and deliver
Involve all constituents

28. Modeling Techniques (1)
Data flow diagrams depict information flow and steps
Structure charts decompose a system into more and more detailed parts
Object-oriented development uses “classes” to build systems
CASE tools help us write tedious code

29. Prototyping and RAD
We build “prototypes” of what a system will look like
Iteratively improve prototypes until system goals are fulfilled
Agile and Scrums are examples of rapid application development tools

30. Project Outsourcing We outsource to Tap into outside expertise
Focus on core business goals rather than develop extensive IT infrastructure
Reduce head count and expenses
Minimize technology investment
Reduce cost

31. Types of Outsoucring
Onshore
Nearshore
Offshore

32. Trends Organizations need to develop apps for a plethora of devices
Handsets
Tablets
Traditional computers
The web