150 likes | 182 Views
Understand system boundary, control, and feedback in information systems. Learn hardware and software technology, project management, and software engineering processes for effective system development. Explore methodologies, tools, and coping strategies for evolving technology and changing user requirements.
E N D
CSCC40Analysis and Design of Information Systems • These lecture slides are provided for the personal use of students • taking CSCC40 in the Fall term of 2007 at the University of Toronto. • Copying for purposes other than this use, and all forms of distribution • are expressly prohibited. • Some slides are adapted from the course textbook: • Object-Oriented Systems Analysis and Design Using UML. • 3rd ed. Bennett, McRobb, Farmer. McGraw-Hill. 2002. • The following sources of information are also recommended • Project Management Institute • Association of Computing Machinery • IEEE Computer Society
ACM computing curricula 2001 • software engineering • processes • requirements and specifications • design • validation • delivery of systems • evolution • project management • tools and environments • component-based computing • formal methods • reliability these topics are covered in CSCC40 and CSCD08
missions, strategies and their realization drives and sets goals business strategy where IT can help what must be done information systems strategy hardware capabilities system requirements informs and enables information technology strategy Fig. 1.10 the relationship between business, IS and IT strategies
system boundary what the system does inputs outputs control feedback feed-forward how the system is controlled all systems (manual and/or automated) have these characteristics
types of systems transaction processing systems management information systems decision support systems expert systems real-time (control) systems other each can be implemented as online and/or batch distributed and/or centralized corporate and/or departmental and/or public
the three perspectives • technological • hardware, networks, databases, CASE tools ... • social • how do individuals and organizations use information, • how are they affected by technology… • professional • practices and standards, policies, quality practices ...
hardware software communication personal computers, workstations, mainframes, hardware components, CPUs, memory, disks, peripherals palmtops ... word processing, spreadsheets, presentation software, website design, web search engines, document management CASE tools ... e-mail, fax, wireless communication, telephone, networks, internet ... technologies for analysis and design
Hoffer, George, Valacich. Modern Systems Analysis and Design. 2nd ed. Addison Welsey 1999. functional decomposition of business business function supporting function
conceptual complexity ! • Where does one system end, and another start? • If a system is a subjective view of reality, • then who’s view do we work with? • How do we cope when: • the system is too large to be understood by any one person? • technology is changing all the time? • user requirements are changing all the time? • new development tools and techniques and methodologies • are constantly needed?
we have coping strategies ! methodologies: waterfall, prototype, extreme . . . time-tested techniques for: verification, validation, estimating . . . abstraction and decomposition modeling methods: structured, object-oriented . . . tools for: project control, design control, configuration management . . .
what we want to avoid / prevent ... from end user’s perspective ... What system? I haven’t seen a new system. (vaporware) It might work, but it’s dreadful to use. (lots of reasons) It’s pretty, but does it do anything useful? (not an improvement) from client’s perspective ... If I’d known the real price, I’d never have agreed. It’s no use delivering it now –we needed it last April. OK, so it works, but the installation was such a mess, my staff will never trust it. I didn’t want it in the first place. Everything’s changed now –we need a completely different system.
what we want to avoid / prevent ... from the developer’s perspective ... We built what they said they wanted. There wasn’t enough time to do it any better. Don’t blame me –I’ve never done O-O analysis before. How can I fix it –I don’t know how it’s supposed to work. We said it was impossible, but no-one listened. The system’s fine –the users are the problem.