Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling

1. Introduction to InformationSystems AnalysisSystems DesignApplication Architecture & Modeling INFO 503 Glenn Booker Lecture #5

2. System Design • System Design (a.k.a. physical design) includes the evaluation of alternative solutions, and specification of a detailed solution • Focus is the shift from logical to physical design; now technology counts! • Critical to consider off-the-shelf options Lecture #5

3. Design Strategies • Modern structured design • Information engineering • Prototyping • Object-Oriented Design (OOD) • Joint Application Development (JAD) • Rapid Application Development (RAD) Lecture #5

4. Modern Structured Design • A.k.a. top-down program design and structured programming • Is a process-oriented technique to break a program into smaller pieces (modules) by using certain rules and guidelines • Each module is a set of instructions to perform a specific function Lecture #5

5. Modern Structured Design • Modules should be cohesive - perform only one function; this helps reusability too • Modules should be loosely coupled - have minimal interaction or dependency on each other • Capture design in a structure chart, p. 474 (314) • Not event driven or object-oriented Lecture #5

6. Information Engineering • Analysis was based on defining applications to support the requirements of various business areas • IE does not have its own unique design technique; tools such as the ERD are the starting point • Address process issues later Lecture #5

7. Prototyping • Developing prototypes: • Encourages end user involvement • Is well suited to iterative development • Allows hands-on verification of requirements • Provides quick feedback • Often speeds several life cycle phases Lecture #5

8. Prototyping • But prototyping: • Encourages irresponsible code-and-fix life cycle • Can only augment paper specifications and other design techniques • Omits several design issues; storage, control, performance Lecture #5

9. Prototyping • And prototyping: • Can lead to premature design commitment (lock in design options) • Can reduce creativity • Can lead to feature (scope) creep • Can result in slower performance Lecture #5

10. Object-Oriented Design • OOD uses the results of OOA to design objects which will implement the system • Addresses data and process issues at the same time • Can, for example, focus on defining objects, and then defining the methods which communicate between them, p. 478 (546) Lecture #5

11. Joint Application Development • JAD can be used for participative development of a design, in conjunction with other design techniques Lecture #5

12. Rapid Application Development • RAD blends other design techniques (structured design, information engineering, prototyping and JAD) to speed system development • Often based on using specific tools which support the process Lecture #5

13. FAST Design Methodology • Design covers the following FAST phases: • Decision Analysis (Configuration) Phase, from Chapter 5 in the 6th edition • Procurement Phase (not a separate phase, it is addressed during System Design phase in the 6th edition) • Physical Designand Integration Phase, this is detailed design before construction of the system Lecture #5

14. Decision Analysis (Configuration) Phase • The decision analysis phase identifies candidate configurations, and picks the best • Activities are: • 5.1 Identify Candidate Solutions • 5.2 Analyze Candidate Solutions • 5.3 Compare Candidate Solutions • 5.4 Update the Project Plan • 5.5 Recommend a System Solution Lecture #5

15. Identify Candidate Solutions • This activity identifies the candidate system design solutions, based on business needs and possible implementation technology • Ideas may come from system owners, users, and others involved in the analysis effort • Candidates may be based on the technology architecture of your organization Lecture #5

16. Identify Candidate Solutions • Activity consists largely of brainstorming for ideas, followed by research to assess their characteristics • Do not judge the solutions - yet • Output is a table to describe possible solutions, p. 221 (322), the Candidate Systems Matrix Lecture #5

17. Analyze Candidate Solutions • Now assess each candidate solution for: • Technical feasibility (practical and staffable) • Operational feasibility (effect on users) • Economic feasibility (is it cost effective?) • Schedule feasibility (can it be done on time?) • Need to define hardware, training, and software costs for each solution • Output: feasibility assessment, p. 223 (324) Lecture #5

18. Compare Candidate Solutions • Based on the relative importance of the feasibility criteria (i.e. their weight in %), score each of the candidate solutions • Weighting of feasibility criteria often done by the system owner • Throw out infeasible solutions (those which are impossible) • Pick the best solution! Lecture #5

19. Update the Project Plan Does this task seem familiar yet? • Update the project plan to reflect the chosen system configuration • Reevaluate scope and tasks as needed Lecture #5

20. Recommend a System Solution • Now use the updated project plan to recommend a solution to the system owner, with other key interested parties present • Might give recommendations (the system proposal) verbally or in writing • Salesmanship is often helpful to pitch the solution • Hopefully ends with approval to continue Lecture #5

21. Procurement Phase p. 487 (326) • The procurement phase is to assess off-the-shelf options for supporting system design • This phase is a blend of two new tasks for the “Procurement phase,” and three revised tasks for the “Decision Analysis phase” • Task numbering in the 6th edition looks weird; it’s intended to replace the specified steps in phases 4 and 5, respectively Lecture #5

22. Procurement Phase • New tasks for the Procurement phase are: • 4.1 Research Technical Criteria and Options • 4.2 Solicit Proposals from Vendors • Revised Decision Analysis phase tasks: • 5A.1 Validate Vendor Claims and Performance • 5A.2 Evaluate and Rank Vendor Proposals • 5A.3 Award Contract and Debrief Vendors Lecture #5

23. Research Technical Criteria and Options • Identify specifications for hardware and software - functions, features, and critical performance needs - based on the system requirements • May be based on internal standards, and research of trade journals and magazines • Use to define technical criteria, product options, and potential vendors Lecture #5

24. Solicit Proposals from Vendors • Based on the technical criteria, prepare a request for quotation (RFQ) or arequest for proposal (RFP) • An RFQ is used for a predefined product • Use an RFP when the product is ill defined • The RFQ/RFP must define the selection criteria, and classify requirements as mandatory, essential, or optional Lecture #5

25. Validate Vendor Claims and Performance • Proposals from prospective vendors must be validated to ensure their individual merits • For major software proposals, a Software Capability Evaluation (SCE) may be used • Validation may be through site visits, contacting other clients, and other research • Results in validated or invalidated proposals • ‘Invalidated’ means you don’t believe them Lecture #5

26. Evaluate and Rank Vendor Proposals • Throw out all invalidated proposals • Validated proposals can now be evaluated and ranked, using the predefined criteria • This is a form of feasibility assessment, but it might include criteria about the stability of the vendor, or their level of support • Results in a recommendation to use a particular vendor (we hope) Lecture #5

27. Award Contract and Debrief Vendors • The vendor selection is approved by management or the system owner • Contracts are prepared, negotiated, and reviewed by winning vendor and system owner • All candidate vendors are briefed on the results of the evaluation (if you’re nice) • Update affected interface requirements Lecture #5

28. Physical Design & Integration Phase • This phase bridges the gulf between the user requirements and the builders’ input needs • 6.1 Design the Application Architecture • 6.2 Design the System Database • 6.3 Design the System Interface • 6.4 Package Design Specifications • 6.5 Update Project Plan Lecture #5

29. Design the Application Architecture • Defines technologies used by the system, including data, process, interface, and network components • How will data, process, and interface be distributed across locations? • Based on data and process models • Might include physical data flow diagram, p. 482 (373) Lecture #5

30. Design the System Database • System database(s) are designed in more detail – allowing not only for full 3NF, but also addressing performance, design flexibility, storage, security, record size, and backup/recovery needs • Capture in a database schema (often ERD) Lecture #5

31. Design the System Interface • Design the user interfaces to the system – inputs and outputs • Design preprinted forms and reports • Lots of existing user input is helpful! • Consider ease of learning, as well as use • Define controls to help get complete and correct data (minimize input errors) Lecture #5

32. Package Design Specifications • Take the results of the previous three steps and put it into a design specification document – essentially a blueprint to guide the system builders • Need to balance how much design must be specified for the builders, and how much can be left to their discretion and creativity • Review with all affected parties Lecture #5

33. Update Project Plan Mary had a little lambWhose fleece was white as snowAnd everywhere that Mary wentShe updated the project plan to reflect her progress • Update the project plan, now that full design information is available (last sanity check before the start of construction!) Lecture #5

34. Application Architecture • Return to general design focus, not detailed • Application architecture addresses general system design and technology issues: • How distributed is computing (processing)? • How distributed is data storage? • Make or buy technology? • Which technologies are used for user and system interfaces, and for programming? Lecture #5

35. Modeling Application Architecture • Application architectures can be captured in many ways • A physical data flow diagram (PDFD) can show the technical design, such as the software or people involved in each process • Physical data flows can identify both the name of each data flow, and how it is implemented (person’s role, bar code, HTML, VB, etc.) Lecture #5

36. Modeling Application Architecture p. 504 (373) • Physical data flows expand on the logical model; may also show user vs machine lines • Physical data flows may include: • Input or output to/from a process • Database commands (CRUD) with data stores • Import or export of data from another system • Flow of data between two modules or subsystems within your system Lecture #5

37. Modeling Application Architecture • Physical data stores might include: • An entire database • A table in a database • A file on the computer (whether temporary or permanent) • A tape backup device • Any other kind of file, paper, or form Lecture #5

38. Modeling Application Architecture • A network topology data flow diagram can show which processors or people support various processes • System flowcharts were popular for showing all programs, inputs, outputs, data, and processes at once - whew! • CASE tools can automate generation of flowcharts and DFDs Lecture #5

39. IT Architecture • IT architecture is evolving rapidly; stay tuned for current events! (see SEI, ACM) • Networking architecture issues drive many others, so look at them first • Historic footnote: early PCs weren’t designed for multiple users or local networks • Wireless communications emerging as newest key factor in networking Lecture #5

40. Five Application Layers • Presentation layer is what the user sees • Presentation logic layer determines what needs to be displayed on the screen • Application logic layer controls how the application runs • Data manipulation layer controls getting data, which lives in the data layer Lecture #5

41. IT Architecture • Architecture options range from centralized to distributed in varying degrees • Purely centralized computing was the mainframe philosophy (one box does it all) • Web-based systems are the most decentralized • “Servers” are computers shared by many users at once • “Clients” are used by one user at a time Lecture #5

42. IT Architecture • Servers might fulfill many purposes • File servers hold data files used by many users • Database servers run the database program and store its data • Application servers get data inputs from the clients, and get data from the database server • Web servers host a web site, and communicate among clients and application servers Lecture #5

43. IT Architecture • Clients can be ‘fat’ or ‘thin’ • Fat clients have a custom application installed to communicate with the servers (now rare) • If you had to install a special program to use that system, you are probably using a fat client • Thin clients communicate with the servers through an ordinary (not customized) program, such as a web browser (now common) • Thin clients act like a dumb terminal Lecture #5

44. IT Architecture • Architecture options (see p. 511 (355)) are: • Centralized computing (not shown) • File server architecture • Distributed presentation (2 tier) • Distributed data (2 tier) • Distributed data & application (n tier) • Network computing (web) Lecture #5

45. Centralized Computing • Centralized computing was the only architecture approach through the 1970’s • Used a mainframe or minicomputer to do all the work, accessed through terminals • VT100 or IBM 3270 terminals; really dumb clients, they only displayed what text the mainframe sent to them • Very few systems still use this Lecture #5

46. File Server Architecture • This primitive form of distributed computing stores data on a file server, and everything else is done by the clients • The file server just holds the shared data files and lets the clients read it or write to it when needed • Is a common cheap way to share data across a local area network (LAN) Lecture #5

47. Client/server Architecture • Client/server architecture (distributed or cooperative computing) is the dominant network architecture starting in the 1980’s • Data, software, and interfaces may be distributed across many clients and servers • ‘Distributed presentation’, ‘distributed data’, and ‘distributed data and application’ structures are all types of client/server architecture Lecture #5

48. Server Types • Client/server may use many server types • Database server for data and data manipulation • Transaction server to control groups of business transactions together • Application server for the same layer • Messaging or groupware for Notes or Exchange • Web server for hosting Internet or Intranet sites Lecture #5

49. Distributed Presentation • Distributed presentation (a.k.a. chintzy client/server) puts a pretty GUI on what were text-based (character user interface, or CUI) terminal screens • May use CASE tool called a screen scraper to generate a quick GUI from a CUI • Client does presentation and pres. logic layers • Still is fundamentally centralized computing Lecture #5

50. Distributed Data • Distributed data (two-tier client/server) puts stored data on the server, and business logic and user interfaces on the clients • A local or wide area network (LAN or WAN) connects clients and servers • Reduces network traffic compared to file server architecture; easier to maintain data integrity • This is classic 1980’s client/server design Lecture #5