Download presentation
Presentation is loading. Please wait.
1
The System Life Cycle Week 14 LBSC 690 Information Technology
2
Agenda Questions Systems analysis Building complex systems Managing complex systems Final exam review
3
The System Life Cycle Systems analysis –How do we know what kind of system to build? User-centered design –How do we discern and satisfy user needs? Implementation –How do we build it? Management –How do we use it?
4
Systems Analysis First steps: –Understand the task Limitations of existing approaches –Understand the environment Structure of the industry, feasibility study Then identify the information flows –e.g., Serials use impacts cancellation policy Only then can you design a solution
5
Analyze the Information Flows Where does information originate? –Might come from multiple sources –Feedback loops may have no identifiable source Which parts should be automated? –Some things are easier to do without computers Which automated parts should be integrated? What other systems are involved? –And what information do they contain?
6
Analyzing Information Flows Process Modeling –Structured analysis and design –Entity-relationship diagrams –Data-flow diagrams Object Modeling –Object-oriented analysis and design –Unified Modeling Language (UML)
7
Some Library Activities Acquisition Cataloging Reference –Online Public Access Catalog (OPAC) Circulation Weeding Reserve, recall, fines, interlibrary loan, … Budget, facilities schedules, payroll,...
8
Discussion Point: Integrated Library System What functions should be integrated? What are the key data flows? Which of those should be automated?
9
User-Centered Design Start with user needs –Who are the present and future users? –How can you understand their needs? Evaluate available technology –Off-the-shelf solutions –Custom-developed applications Implement something Evaluate it with real users
10
The Waterfall Model Key insight: invest in the design stage –An hour of design can save a week of debugging! Requirements –Specifies what the software is supposed to do Specification –Specifies the design of the software Test plan –Specifies how you will know that it did it
11
The Waterfall Model Requirements Specification Software Test Plan
12
The Spiral Model Build what you think you need –Perhaps using the waterfall model Get a few users to help you debug it –First an “alpha” release, then a “beta” release Release it as a product (version 1.0) –Make small changes as needed (1.1, 1.2, ….) Save big changes for a major new release –Often based on a total redesign (2.0, 3.0, …)
13
The Spiral Model 1.0 0.5 2.0 3.0 1.1 1.2 2.1 2.2 2.3
14
Some Unpleasant Realities The waterfall model doesn’t work well –Requirements usually incomplete or incorrect The spiral model is expensive –Redesign leads to recoding and retesting
15
The Rapid Prototyping Model Goal: explore requirements –Without building the complete product Start with part of the functionality –That will (hopefully) yield significant insight Build a prototype –Focus on core functionality, not in efficiency Use the prototype to refine the requirements Repeat the process, expanding functionality
16
Rapid Prototyping + Waterfall Update Requirements Choose Functionality Build Prototype Initial Requirements Write Specification Create Software Write Test Plan
17
Implementation Requirements Availability –Mean Time Between Failures (MTBF) –Mean Time To Repair (MTTR) Capacity –Number of users for each application –Response time Flexibility –Upgrade path
18
Alternative Architectures Batch processing (e.g., recall notices) –Save it up and do it all at once Timesharing (e.g., OPAC) –Everyone uses the same machine Client-Server (e.g., Web) –Some functions done centrally, others locally Peer-to-Peer (e.g., Kazaa) –All data and computation is distributed
19
Management Issues Retrospective conversion –Even converting electronic information is expensive Management information –Peak capacity evaluation, audit trails, etc. –Sometimes costs more to collect than it is worth! Training –Staff, end-users Privacy
20
Total Cost of Ownership
21
Open Source: Pros Peer-reviewed code Dynamic community Iterative releases, rapid bug fixes Released by engineers, not marketing people High quality No vendor lock-in Simplified license management
22
Cons of Open Source Dead-end software Fragmentation Developed by engineers, often for engineers Community development model Inability to point fingers
23
Hands On: What Goes Wrong? Check out Risks Digest for a random date –http://catless.ncl.ac.uk/Risks –Pick a random date near your birthday Find a case of unexpected consequences Try to articulate the root cause –Not the direct cause
24
Discussion Points: Managing Complex Systems Critical system availability –Why can’t we live without these systems? Understandability –Why can’t we predict what systems will do? Nature of bugs –Why can’t we get rid of them? Auditability –How can we learn to do better in the future?
25
Critical Infrastructure Protection Telecommunications Banking and finance Energy Transportation Emergency services Food and agriculture Water Public health Postal and shipping Defense industrial base Hazardous materials SCADA: Supervisory Control and Data Acquisition
26
National Cyberspace Strategy Response system –Analysis, warning, response, recovery Threat and vulnerability reduction Awareness and training program –Return on investment, best practices Securing government systems International cooperation
27
Summary Systems analysis –Required for complex multi-person tasks User-centered design –Multiple stakeholders complicate the process Implementation –Architecture, open standards, … Management –Typically the biggest cost driver
28
Talk to Me About the Exam! About 5 questions –Same question styles as the midterm –Some may require use of the computer Comprehensive - covers the entire course –Emphasis and structure from the second half Two hours Post-exam discussion at Bentley’s
29
The Grand Plan Networking HTML/XML Multimedia ComputersHCI Search CMC Web Life Cycle Policy Databases Programming Web Databases Midterm Project Final Quiz LBSC 733 LBSC 795 LBSC 795 LBSC 790 LBSC 793 INFM 718N
30
Computers Hardware –Types of hardware –Storage hierarchy –Moore’s law Software –Types of software –Types of interfaces
31
Networks Types of Networks –LAN, WAN, Internet, Wireless Packet Switching –Ethernet, routers, routing tables Layered Architecture and protocols –TCP/UDP –IP address/domain name
32
Structured Documents My Browser The Web –HTTP, HTML, URL XML
33
Multimedia Compression, compression, compression –Image: lossy vs loseless –Video: frames are alike –Speech: voice predictable –Music: masking Streaming Media Sever Internet Buffer
34
Programming Programming languages –Machines require specific instructions –Humans require high-level abstraction Control structures –Sequential execution –Conditional –Iteration Javascript ??
35
Databases Structured information –Field->record->table->database –Primary key Normalized tables (relations) –Remove redundancy, inconsistency, error –Easy update, search Join links tables together –Through foreign key Access provides visual operations
36
Web-Database Integration Microsoft “Data Access Pages” Server-side database integration Ajax Mythical person-month
37
Human-Computer Interaction Human-machine synergy Mental models Input and output devices Interaction styles –Direct manipulation, menu, language based
38
Computer-Mediated Communication Synchronous / Asynchronous Remote / local One-to-one / many-to-many Computer-Supported Cooperative Work
39
The Web Huge, dynamic, redundant, and diverse Multimedia, multilingual, multicultural Deep Web Internet Archive
40
Search Engines Exact match Term-based ranked retrieval Recommender systems Web search –Links and anchor text Evaluation
41
Policy Ownership –Equitable access –Controlled access Identity –Choosing good passwords Privacy –Government / commercial Integrity
42
System Life Cycle Systems analysis Software development models Managing complex systems
43
R.J. Bentley’s Filling Station Monday May 19, 2008 at 8:30 P.M.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.