Information Systems 622 Study Hub

1.3 Make, Buy, Customize or Empower Users

The guide treats software acquisition as a practical decision, not a slogan. A company can develop software in-house, purchase a package, customize a package, create user applications from tools such as Microsoft Office, outsource, offshore, use SaaS, or combine several of these. The analyst must explain what the organization gains and what it gives up.

1.4-1.6 Outsourcing, Offshoring and SaaS

Outsourcing transfers development, operation, or maintenance work to an external service provider for a fee. It can range from a small programming task to a full IT function, business process outsourcing, application service provider support, or managed hosting through internet business services.

Offshoring is global outsourcing: IT development, support, or operations move to another country. The main attraction is cost saving, but the guide stresses project control, security, culture, language, and time-zone communication risk.

SaaS changes software from a product purchase into a hosted internet service. The customer receives the function of the software without carrying the same burden of installation, infrastructure, maintenance, and updates.

Worked Example: Choosing Software for an Order System

Scenario: a company wants a new order processing system. A website is expected to increase orders by almost 80%, but the company also has legacy accounting software and limited internal programmers.

1. Evaluate requirements: list required features, web access, network/intranet needs, data exchanged with customers or vendors, expected growth, and hardware/software/personnel constraints.
2. Prepare an RFP or RFQ: use an RFP if vendors must propose how they will satisfy the requirement; use an RFQ if the exact product/service is already known and pricing is needed.
3. Identify vendors or outsourcing options: use vendor sites, industry trade sources, consultants, forums, and references from existing users.
4. Evaluate alternatives: compare package features against the RFP, ask existing users, run application tests, and use benchmarks for volume-sensitive performance.
5. Perform cost-benefit analysis: include licenses, support, maintenance, training, volume-based fees, staffing, customization, and what-if scenarios.
6. Recommend: present costs, benefits, advantages, disadvantages, and the option that best fits strategy and risk.

2.3 Seven Habits of Successful Interface Designers

The guide's user interface chapter keeps returning to one idea: a good interface supports real work so smoothly that users can focus on the task instead of the system. That is why the analyst must understand business functions, user skill levels, user language, and feedback from actual use.

2.4 Ten UI Design Guidelines

The second guideline group is more operational: it turns the design habits into concrete checks for screens, menus, feedback, data entry, and volume reduction.

Worked Example: Redesigning a Sales Return Form and Report

Scenario: users complain that returned goods are recorded incorrectly and managers receive a confusing monthly report.

2.7-2.9 Technology, Controls and Emerging Trends

Technology choices affect both input and output. Screen output, printed output, source documents, RFID, automated data capture, responsive layouts, and modular design must still be judged by user needs and control requirements. The guide also keeps security inside interface design: reports can expose confidential information, and input screens can let unauthorized or inaccurate data enter the system.

3.1 Mario and Danica: File-Oriented vs Relational Design

The guide's auto shop example is a clean way to remember why relational databases matter. Mario stores mechanic and job data in two separate file-oriented systems. Because Mechanic No, Name, and Pay Rate are duplicated, one file can show Jim Jones at one rate and another file can show a different rate. The issue is not just storage waste; it is data quality and integrity.

Danica uses a DBMS with two related tables joined by a common field, Mechanic ID. The pay rate appears in only one place, while the common field connects the mechanic table to the job table. This is the basic idea of the relational model: tables are separate, but meaningful relationships allow them to work together.

3.2-3.3 DBMS Components and Web-Based Data Design

A DBMS sits between the database and the users, DBAs, applications, and related systems that need access. The guide highlights user interfaces, DBA interfaces, related-system interfaces, a data manipulation language, a schema, subschemas, and a physical data repository.

In web-based design, the database must support many users and applications over internet-style access. That makes scalability, security, and flexible access central design concerns.

Worked Example: From Order Form to Normalized Tables

Unnormalized source: ORDER (ORDER_NO, DATE, CUSTOMER_NO, CUSTOMER_NAME, (PRODUCT_NO, DESCRIPTION, QTY_ORDERED, SUPPLIER_NO, SUPPLIER_NAME)). The repeating product group means one order record can contain many product lines.

1. 1NF: remove repeating groups. Put each product line into its own row or separate child table so every field stores one value per record.
2. 2NF: if a table has a combined key such as ORDER_NO + PRODUCT_NO, every non-key field must depend on the whole key. Product description depends only on product, not on the whole order line key, so it belongs in PRODUCT.
3. 3NF: remove dependencies between non-key fields. If SUPPLIER_NAME depends on SUPPLIER_NO, store supplier details in SUPPLIER rather than repeating them in order lines.

3.7-3.9 Codes, Storage, Access and Controls

Codes simplify input, output, and storage by representing data with letters or numbers. The guide identifies seven code types and warns that code design should be concise, expandable, stable, unique, sortable, simple, non-confusing, and meaningful.

Data control protects stored data with access privileges, encryption, backup/recovery procedures, audit logs, and audit fields. Storage and access decisions must distinguish logical design from physical storage.

4.1 Architecture Checklist in Exam Form

System architecture is the physical design of the information system. The guide's checklist asks whether the design fits corporate culture, enterprise systems, costs, growth, web integration, legacy systems, processing options, security, and portals.

4.2-4.3 Architecture Evolution and Client/Server Design

The guide traces architecture from centralized mainframes, through personal computers, toward networked and distributed systems. In client/server architecture, clients request services and servers provide data, logic, storage, or processing.

Worked Example: Architecture for a Retail Chain

Scenario: a retail chain has local stores, a head office, an online shop, and shared inventory data.

4.7-4.9 Network Models, Wireless and Design Completion

The guide uses the OSI model to organize network communication into seven layers: physical, data link, network, transport, session, presentation, and application. It also compares topologies such as hierarchical, bus, ring, star, and mesh.

Wireless networks add flexibility through IEEE 802.11 standards such as 802.11b, 802.11g, 802.11n, and 802.11ac, but the guide warns about interference and security exposure.

At completion, the system design specification should include a management summary, system components, system environment, implementation requirements, time/cost estimates, and additional material from earlier phases. Presentations usually move from technical team, to users/managers, to final management approval.

5.1 Quality Assurance, Software Engineering and ISO

The implementation phase includes application development, testing, documentation, training, and changeover, but quality assurance starts before code is written. The guide states that testing can find problems during implementation, but preventing or detecting mistakes earlier is cheaper and better.

Software engineering applies engineering principles to requirements, design, construction, testing, and maintenance/evolution. Systems engineering widens the view to hardware, networks, people, procedures, and interfaces. The guide also names ISO as an international quality standards body; ISO-style work emphasizes documented testing, records, procedures, and quality evidence.

5.2-5.5 Structured, Object-Oriented and Agile Development

Implementation method affects how the design turns into working software. Traditional structured or object-oriented approaches usually begin after design is complete; agile approaches begin with prioritized user stories and iterative releases.

OOA Essentials: Classes and Object Relationships

Object-oriented analysis organises a system around objects that combine data and behaviour. A class defines attributes and methods; an object is an instance of a class; and relationships show how objects collaborate to carry out business functions.

Sequence Diagrams and Business Process Modelling

A sequence diagram visualises event-driven interaction in time order. Lifelines represent actors or objects, and messages show the requests and responses passed between them. The guide identifies sequence diagrams alongside class, state transition and activity diagrams as key object-oriented design documents.

Use BPM for scenarios such as order fulfilment or employee onboarding when the main question is how work moves through the organisation. Use object modelling when the main question is how software objects represent and perform that work.

5.6-5.8 Coding, Testing and Documentation

After coding, testing proves whether programs and the whole system operate correctly. The guide separates programmer-level checks from analyst-planned integration and system testing.

Worked Example: Planning a Payroll System Changeover

Scenario: a payroll replacement passed system testing. Management must decide how to install it, convert data, train staff, and evaluate success.

1. Separate environments: keep the operational environment for live data separate from the test environment used for testing and training practice.
2. Choose changeover: direct cutover is cheapest but riskiest; parallel operation is safest but expensive; pilot tests in one location/group; phased introduces one module or function at a time.
3. Convert data: move existing employee, payroll, tax, and benefits data into the new format, then validate accuracy before live use.
4. Train people: identify users, managers, and IT staff; choose vendor, outside, or in-house training; use group sessions, hands-on practice, manuals, tutorials, webinars, podcasts, and previous trainees.
5. Evaluate after implementation: review output accuracy, user satisfaction, reliability, maintainability, controls, security, platform performance, database implementation, IT team performance, documentation, training, cost-benefit estimates, and schedules.
6. Report to management: include final documentation, evaluation results, unresolved issues, planned maintenance, and recommendations.

6.1 User Support and Help Desks

After implementation, a systems analyst often acts as an internal consultant. The guide notes that well-designed systems can require even more support because users discover features, ask for improvements, and need help applying the system to real work. Support can be in-house or outsourced, but quality must be actively monitored.

6.2-6.3 Maintenance Types and Management

Maintenance is a mini-version of the SDLC. A maintenance request is submitted, evaluated, prioritized, scheduled, investigated, analyzed, designed, developed, tested, documented, and implemented. The maintenance team often includes analysts and programmers; in larger IT departments, maintenance and new development can be separate teams.

6.4-6.6 Performance and Security

System performance management covers fault management, workload measurement, and capacity planning. The guide's performance terms are useful in short questions because they look similar but measure different things.

Security begins with policy and risk management. The guide frames risk management as identifying, analyzing, anticipating, and reducing risks to an acceptable level. Security should be evaluated across physical, network, application, file, user, and procedural levels.

Worked Example: Recovering and Retiring an Ageing System

Scenario: an old inventory system has rising corrective maintenance, slow reports, repeated outages, and users asking for web access. A power failure damages a server during peak trading.

1. Business continuity: use the disaster recovery plan to identify roles, emergency actions, damaged equipment, recovery sequence, and communication responsibilities.
2. Backup and recovery: restore data from approved backups, follow retention rules, verify the latest clean copy, and test restored data before normal operations resume.
3. Performance review: measure response time, throughput, turnaround time, workload, and capacity to see whether the system can still support business needs.
4. Maintenance classification: fix the outage as corrective maintenance, improve slow reports as perfective maintenance, add web access as adaptive maintenance, and reduce future failure through preventive work.
5. Retirement decision: rising maintenance, expensive changes, user demands, new technology, poor support for new requirements, and declining value indicate that replacement planning should begin.

6.9 Future Challenges, IT Careers and Cyberethics

The closing section looks beyond day-to-day maintenance. IT professionals need technical knowledge, strategic planning ability, credentials or certifications where useful, and critical thinking. The guide also emphasizes cyberethics: security, privacy, fair use of systems, and responsible professional judgment become more important as systems connect more people, suppliers, and data.