1 / 67

Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling

Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling. INFO 503 Glenn Booker. System Design. System Design (a.k.a. physical design) includes the evaluation of alternative solutions, and specification of a detailed solution

parker
Download Presentation

Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related