INFS 347 Final

Tracking Project Tasks

- Gantt Chart: has a bar chart format + useful for monitoring project status at any point in time - PERT Chart: flowchart format + useful for illustrating task dependencies and the critical path

Steps to Create the Physical DFD

- add implementation references - draw a human-machine boundary - add system-related data stores, data flows and processes - update data elements in the data flows

Acceptance Testing

- alpha testing: performed by users to assure they accept the system; frequently repeats earlier tests - beta testing: uses real data, not test data; actual users monitor for errors or needed improvements - user sign-off following acceptance testing indicates the system is ready to be placed into production

Basic Principles of Navigation Design

- analysts usually must assume that users have not read the manual, have not attended training, and do not have external help readily at hand - all controls should be clear and understandable and placed in an intuitive location on the screen - prevent mistakes (limit choices) - simplify recovery from mistakes - use consistent grammar order (action-object, object-action)

Requirements Elicitation Technique - Electronic JAD - e-JAD

- any group activity may experience problems with group dynamics - helps group overcome group dynamics issues - dominance, status differences, fear of reprisal - provides ways for members to contribute, comment on, and rate ideas anonymously - requires a trained e-JAD facilitator and groupware software

Outsourcing

- application service providers (ASP) supply access to software on a pay-as-you-go basis - many applications today are "in the cloud" - risks include: fear of losing confidential information, performance - analyze the vendor as well as the software functionality

Requirements Analysis Strategies - Problem Analysis

- asking users to identify problems and solutions - improvements tend to be small and incremental - often very effective at improving a system's efficiency or ease of use, but provides minor improvements to business value

Project Manager's Tasks During Programming

- assigning programming tasks - coordinating activities - managing the schedule

Elements of a Use Case

- basic information: name, number and brief description, trigger (can be external or temporal), viewpoint of use cases should be consistent - major inputs and outputs: sources and destinations, goal is to be all inclusive - details: steps performed and the data inputs and outputs - preconditions: define what must occur before beginning the use case - postconditions: define what is complete when the use case ends

Process of Determining Requirements

- both business and IT perspective are needed to determine requirements during the analysis phase - most effective approach is to have both businesspeople and analysts working together to determine requirements - analyst must also consider how best to elicit the requirements from the stakeholders - process of determining requirements continues throughout the analysis phase, and the requirements definition evolves over time

Steps in Building DFDs

- build the context diagram - create a decomposition diagram: hierarchy of use cases - organize fragments into level 0 diagram - decompose level 0 processes into level 1 diagrams as needed - validate DFD with user to ensure completeness and correctness

Identifying Projects with Business Value

- business needs should drive projects - project sponsor recognizes business need for new system and desires to see it implemented - business needs determine the system's functionality (what it will do) - project's business value should be clear

Common Project Team Specializations (Systems Analyst Roles)

- business oriented roles: business analyst + requirements analyst - technically oriented roles: infrastructure analyst + software architect - people oriented roles: change management analyst + project manager

Depicting Business Processes with DFDs

- business processes are too complex to be shown on a single DFD - deliberate hierarchy is created with multiple "levels" of DFDs - use decomposition to build the hierarchy: child diagrams show a portion of the parent diagram in greater detail

Two-Tiered Client-Server Architecture

- client devices handle presentation and application logic - server handles data access logic and data storage

Three-Tiered Client-Server Architecture

- client devices handle presentation logic - application server handles business logic - database server handles database-related tasks

N-Tiered Client-Server Architecture

- client devices handle presentation logic - web server handles web-related business logic - application server handles business logic - database server handles database-related tasks

Developing an Alternative Matrix

- combine several feasibility analyses into one matrix - include technical, budget, and organizational feasibilities - assign weights to indicate the relative importance of the criteria - assign scores to indicate how well the alternative meets the criteria

Optimizing Data Storage

- conflicting goals: storage efficiency (minimizing storage space) and speed of access (minimizing time to retrieve desired information - 3 techniques commonly used to speed up data access: denormalization, clustering, indexing

Moving into Implementation

- construction: development of all parts of the system: software itself, documentation, and new operating procedures - testing: helps ensure the system performs as outlined in the specifications - documentation: provides information to make the system easier to use and repair

Physical DFD

- contains same components as the logical DFD - same rules pertaining to balance and decomposition apply - contains additional details describing how the system will be built

Level 1 Diagram

- create one level 1 diagram for every major process on the level 0 diagram - shows the internal processes that comprise a single process on the level 0 diagram - shows how information moves to and from each of these processes

Selecting an Architecture Design

- creating an architecture design begins with the nonfunctional requirements - refine the nonfunctional requirements into more detailed requirements for the selection of architecture - nonfunctional requirements and the architecture design are used to develop the hardware and software specification

System Acquisition Strategies

- custom development (build from scratch) in-house - purchase software package (and customize) - outsource development to third party

Types of Coupling

- data coupling: only data that is required - stamp coupling: entire record - control coupling: control passed down - common coupling: modules referring to the same global area - content coupling: one module manipulating the logic of another module

ERD Building Tips

- data stores of the DFD generally correspond to entities - only include entities with more than one instance of information - don't include entities associated with implementation of the system

System Design

- design phase: decide how to build the system + create system requirements that describe technical details for building the system - system specification: final deliverable from design phase, conveys exactly what system the development team will implement during the implementation phase

Types of Reports

- detail report: lists detailed information about all the items requested - summary report: lists summary information about all items - turnaround document: outputs the "turn around" and become inputs - graphs: charts used in addition to and instead of table of numbers

Feasibility Analysis

- detailed business case for the project - includes 3 types of feasibility 1. technical: studying can we actually build the system 2. economic: should we build it? 3. organizational: if we build it will it be used?

Design Phase Steps

- determine system acquisition strategy: make, buy, or outsource - determine the technical architecture for the system - address security concerns and globalization issues - make hardware and software selections - determine the ways users will interact with the system (interface, inputs, and outputs) - design the programs for the underlying processes - design the way data will be stored - create final deliverable - the system specification

Guidelines for Crafting Documentation Topics

- don't omit any step because you "assume" the user knows how to do that step - use active voice with direct instructions - use consistent terms - use simple, friendly language - use parallel grammatical structure - use steps correctly (as actions) - use short paragraphs

Project Team Review

- each member prepares 2-3 page document regarding her or his actions during the project - excellent behaviors are acknowledged and diffused to others - team leader summarizes and distributes lessons learned

Cloud Computing - Advantages

- elasticity: the resources allocated can be increased or decreased quickly, based on demand - cloud customers can obtain cloud resources in a straightforward fashion - cloud services typically have standardized APIs (application program interfaces) - customers are billed for resources as they are used

Understanding Resistance to Change

- even changes that benefit the organization don't necessarily benefit a given individual - adapting to new work processes requires extra effort, and there may not be additional compensation

Margins of Error in Cost and Time Estimates

- even projects with high-quality estimates will need refinement - project managers must adjust estimated time throughout the project

Enabling Adoption: Training

- every new system requires new skills - new skills may involve use of technology itself or to handle the changed business processes - training: should focus on helping users accomplish their tasks, use scenarios provide an outline for common activities and a basis to plan training

System Review

- examine extent to which the costs and benefits of the system are realized - use this information to help in more accurately estimating costs and benefits for future projects

Requirements Elicitation Technique - Joint Application Development (JAD)

- extensive structure group process - goal: produce complete requirements definition document - directly involves project sponsor, key managers, and key users with system analysts - requires a trained facilitator - requires a comfortable facility for long-term, intensive group work, preferably off-site - expensive but valuable

Data Storage Formats

- files: electronic lists of data, optimized to perform a particular transaction - database: collection of groupings of information that are related to each other in some way - database management system (DBMS): software that creates and manipulates the databases

Types of Cohesion

- functional: module does one task only - sequential: output of one task is input into another - communicational: tasks in the same module because they use the same data - procedural: similar but unrelated tasks in a module - temporal: tasks performed at the same time, but they are unrelated - logical: unrelated tasks in one module, appropriate task is selected by control module - coincidental: no apparent reason for tasks to be in the same module

Project Methodology Options: Agile Development

- group of programming-centric methodologies that focus on streamlining the SDLC - includes face-to-face communication - extreme programming: emphasizes customer satisfaction and teamwork - development team focuses on adapting to the current business environment

Producing Documentation

- high quality documentation takes about 3 hours per page or 2 hours per screen - task should not be left to end of the project - time required to develop and test user documentation should be built into project plan - on-line documentation is growing in importance

Design Guidelines

- high quality structure charts result in programs that are modular, reusable and easy to implement - measures include: cohesion, coupling, appropriate levels of fan-in and fan-out

Organizational Feasibility

- how well the system will ultimately be accepted by users and incorporated into ongoing operations of the organization - stakeholders: champion, organizational management, users of the system

Special Issues for Touch Screen Design

- ideal for information display but not data entry - place content at top and navigation controls at bottom so finger does not obscure content area - place labels on top of navigation controls - size objects correctly for "fat fingers" - include adequate spacing between objects - consider needs of left-handed and right-handed users - bright colors/backgrounds can help reduce glare and hide fingerprints - use each device's standardized gesture interactions to enhance the user's ease of learning and ease of use

Creating an Entity Relationship Diagram

- identify the entities: identify major categories of information, verify that there is more than one instance of the entity that occurs within the system - add appropriate attributes for each entity - draw relationships that connect associated entities

Project Assessment

- important for continued project improvement - especially important for junior personnel to improve quickly

Structure Chart

- important program design technique - shows all components of code in a hierarchical format: sequence, selection, iteration - illustrates the organization and interactions of the difference program modules

Motivating Adoption

- information strategy: aims to convince adopters that change is better - political strategy: uses organizational power to motivate change - differentiate between ready adopters, reluctant adopters, and resistant adopters -- 20-205 ready adopters, 20-30% resistant adopters, 40-60% reluctant adopters

Basic Principles of Input Design

- input mechanisms facilitate the entry of data into the computer system - goal is to simply and easily capture accurate information for the system

User Interface Design Process - Organize the Interface

- interface structure diagram (ISD): defines the basic components of the interface and how they work together to provide functionality to users - shows how all screens, forms and reports are related - similar to DFD in using boxes and lines: boxes denote screens, lines show movement from one to another - different from DFD in having no standard rules or format

Database Types

- legacy databases: based on older technology; seldom used to develop new applications -- hierarchical: inverted trees, to represent relationships -- network: collection of records that are related to each other through pointers - relational database: based on collections of tables, each of which has a primary key - object database: all things treated as objects that have both data (attributes) and processes (behaviors) - multidimensional database: type of relational database used extensively in data warehousing

Assuring Group Performance

- make sure team understands the project and its goals - establish operating procedures (Project Charter): availability, status reporting, meetings - ensure that team members get to know each other - establish methods for dealing with problems

File Types

- master files: store core information that's important to the application - look-up files: contain static values - transaction files: store information that can be used to update a master file - audit files: record "before" and "after" images of data as the data is altered - history (archive) files: store past transactions

Staffing the Project

- match skills to project needs whenever possible - consider technical skills and interpersonal skills: all IS work is done in teams, technical skills are not sufficient - need to be able to work with others, use training and outside sources when skills are not readily available - staffing level will change over a project's lifetime - adding staff adds overhead; not always productive

Types of Navigation Control

- menus: enable users to select action from an organized display of action categories and options; broad shallow design is preferred; logical categories can be objects or actions; common menu formats include menu bars, drop-down menus, popup menus, tab menus, icon tool bars, and image maps - direct manipulation: used with icons to start programs, used to shape and size objects, may not be intuitive for all commands

Pseudocode

- method used for representing the instructions inside a module - language similar to computer programming code - 2 functions: -- helps analyst think in a structured way about the task a module is designed to perform -- acts as a communication tool between analyst and programmer

Creating the Work Plan - Identifying Tasks

- methodology: using standard list of tasks - top-down approach: identify highest level tasks, break them into increasingly smaller units, organize into work breakdown structure

Assigning Programmers

- minimize number of programmers - match programming tasks with programmer capabilities - when skills are deficient, apply mentoring and training

Requirements Elicitation Technique - Interview

- most commonly used technique - basic steps: selecting interviewees, designing interview questions (open-ended, close-ended, + probing questions), preparing for the interview, conducting the interview, post-interview follow up - strengths: interviewee can respond freely and openly, can be asked for more feedback, questions can be adapted or reworded, interviewee's nonverbal communication can be observed - weaknesses: very time-consuming and costly fact-finding approach, success is highly dependent on the systems analyst's human relations skills, may be impractical due to location of interviewees

Comparing Architecture Options

- most systems are built to use the existing infrastructure in the organization, so often the current infrastructure restricts the choice of architecture - each of the architectures discussed has its strengths and weaknesses - client-server architectures are strongly favored on the basis of the cost of infrastructure - cloud computing deserves consideration today

Capture Data at the Source

- motivation: reduces duplicate work, reduces processing times, decreases cost, decreases probability of error - source data automation: bar code readers/scanners, optical character recognition. magnetic stripe readers, smart cards, RFID tags

Systems Development Life Cycle - The Project

- moves systematically through phases where each phase has a standard set of outputs - produces project deliverables - uses deliverables in implementation - results in actual information system - uses gradual refinement

Cultural/Political Requirements

- multilingual: language the system users will need - customization: specification of what aspects of the system can be changed by local users - making unstated norms explicit: explicitly stating assumptions that differ from country to country - legal: laws and regulations that impose system requirements

Minimize Keystrokes

- never ask for information that can be obtained other ways: lookups, dropdown lists, default values - carefully select types of: inputs, selection boxes, input validation

NoSQL Databases

- newest database approach; not based on the relational model or SQL - rapid processing on replicated database serves in the cloud - various types include: -- document-oriented databases: manage collection of documents of varying forms and structures -- wide column databases: store data in records holding very large numbers of dynamic columns (potentially billions of columns) - graph databases: collection of nodes and edges using graph theory to store, map, and query relationships

Revising Management Policies

- no computer system will be successfully adopted unless management policies support this adoption - management tools for supporting adoption: standard operating procedures (SOPs), measurements and rewards, resource allocation

Program Specifications - Content

- no standard approach - include program information - note events that trigger actions - list inputs and outputs - include pseudocode - present additional notes and comments

JAD Practical Tips

- obtain training as a facilitator - tp management supprt needed to enable the right people to commit to the JAD sessions - following completion of JAD sessions, distribute Requirements Definition document to group for confirmation and correction - introduce JAD to organization with small demo project and build on that experience

Types of System Support

- on-demand training at time of user need - online support: FAQs - help desk: phone service for known issues, level 1 support for broad knowledge, unresolved issues placed to level 2 support for specialists in the application system

Conversion Locations

- pilot: one or more locations are converted to work out bugs before extending to other locations - phased: locations are converted in sets - simultaneous: all locations are converted at the same time

Elements of a Migration Plan

- preparing the business: select a conversion strategy, prepare a business contingency plan - preparing the technology: install hardware and software, convert data - preparing the people: revise management policies, assess costs and benefits, motivate adoption, conduct training

Relational Database Concepts

- primary and foreign keys: used to identify and link tables - referential integrity: ensures that values linking the tables together are valid and correctly synchronized - structured query language (SQL): standard language for accessing the data in the tables

Balancing ERDs with DFDs

- process models contain 2 data components, data flows and data stores - DFD data components need to balance the ERD's data stores (entities) and data elements (attributes) - check that all data stores and elements correspond between models: data that's not used in unnecessary, data that's omitted results in an incomplete system

Project Estimation

- process of assigning projected values for time and effort - sources of estimates: methodology in use, actual previous projects, experienced developers - estimates begin as a range and become more specific as the project progresses

Building the Structure Chart

- processes in the DFD tend to represent one module on the structure chart -- afferent processes: provide inputs to system -- central processes: perform critical system operations -- efferent processes: handle system outputs - DFD leveling can correspond to the structure chart hierarchy

Project Identification and Initiation

- project initiation: create and assess goals + expectations for a new system -feasibility study: ensure the technical economic + organizational benefits outweigh the costs and risks - project selection: view the project within the context of an entire project portfolio and projects are selected that contribute to the balance of the portfolio

Project Management Balancing Act

- project management involves making trade-offs between the project size, cost and time to complete - modifying one element requires adjusting the others

Institutionalization of the Sytem

- provide support: assistance in using the system - provide maintenance: repair or fix discovered bugs or errors, add minor enhancements to provide added value - asses the project: analyze what was done well, discover what activities need improvement in the future

System Testing

- requirements testing: ensures integration did not cause new errors - usability testing: tests how easy and error-free the system is in use - security testing: assures that security functions are handled properly - performance testing: assures that the system works under high volumes of activity - documentation testing: analysts check the accuracy of documentation

Mobile Application Architecture

- rich client: involves processing on the mobile device using its resources; presentation logic, business logic, and data access logic are on the client side - thin web-based client: business and data access logic on the server side; always connected to server - rich internet application: browser-based; uses some technologies on client device to provide a rich user interface (ie. flash)

Managing Risk

- risk assessment: identify potential risks, their likelihood, + their potential impact on the project - actions to reduce risk: project team being made aware of risks - revised assessment: recognizes new risks when changes occur in the project

Key Factors in Selecting a Conversion Strategy

- risk: seriousness of consequences of remaining bugs - cost: parallel requires paying for 2 systems for a period of time. simultaneous requires more staff to support all locations - time: parallel, phased, and modular require more time

Managing Scope

- scope creep: users expectations can dramatically increase and system requirements may expand during the project - JAD and prototyping - formal change approval - defer additional requirements as future system enhancements

Value of Online Documentation

- searching is simplified - information can be presented in multiple formats - new methods of interacting with documentation are possible (ie. tool tips) - less costly than paper documentation

Migration Planning

- selecting conversion strategy - understanding resistance to change - revising management policies - assessing costs and benefits - motivating adoption - enabling adoption

Message Design Principles

- should be clear, concise, and complete - should be grammatically correct and free of abbreviations and jargon - avoid negatives and humor

Level 0 Diagram

- shows all major process that comprise the overall system - the internal components of process 0 - shows how the major processes are interrelated by data flows - shows external entities and the major processes with which they interact - adds stored data via the data stores

Request for Proposal (RFP)

- solicits proposals from vendor, developer, or service provider - explains the system to be built and criteria for selecting among applicants - contents include: description of desired system, special technical needs or circumstances, evaluation criteria, instructions on how to response, desired schedule. other information that will help the submitter to make a more complete or accurate proposal

Performance Requirements

- speed: time within which the system must perform its function - capacity: total and peak number of users and the volume of data expected - availability and reliability: extent to which the system will be available to the users and the permissible failure rate due to errors

Key Roles in Change Management

- sponsor: business person who initiated the request for the new system - change agent: person(s) who lead the change effort - potential adopter(s): people who must change

Creating Data Flow Diagrams

- start with the use cases and requirements definition, integrate the use cases - names of use cases become processes - inputs and outputs become data flows - "small" data inputs and outputs are combined into a single flow

Categories of Testing

- stub testing: tests control structures before all modules are written - unit testing: test each module, does it perform its function? - integration testing: tests the interaction of modules, do they work together? - system testing: tests to assure that the software works well as part of the overall system - acceptance testing: tests to assure that the system serves organizational needs

Usability Concept

- system is easy to use and easy to learn - tasks are completed more efficiently and with more accuracy - mistakes with system are reduced - use satisfaction with new system is increased - adoption of system is more likely

Preliminary Project Acceptance

- system request is reviewed by approval committee - based on information provided, project merits are assessed - worthy projects are accepted and undergo additional investigation (the feasibility analysis)

Security Requirements

- system value estimates: estimated business value of the system and its data - access control: limitations on who can access what data - encryption and authentication: defines what data will be encrypted where and whether authentication will be needed for user access - virus control: controls to limit viruses

Project Selection

- systems projects are evaluated in the context of an entire portfolio of projects - portfolio management takes into consideration the different types of projects that exist in an organization (characterized by size, cost, purpose, length, risk, scope, and economic value) - approval committee must be selective about where to allocate resources due to limited funds

Operational Requirements

- technical environment: special hardware, software, and network requirements imposed by business requirements - system integration: extent to which the system will operate with other systems - portability: extent to which the system will need to operate in other environments - maintainability: expected business changes to which the system should be able to adapt

Testing Philosophy

- testing helps ensure the system performs as outlined in the specifications - dangerous to test early modules without an overall testing plan - may be difficult to reproduce sequence of events causing an error - testing must be done systematically and results documented carefully

Context Diagram

- top-level DFD in every process model - shows context into which the business process fits - shows overall business process as just one process ('process zero') - shows all the external entities that receive information from or contribute information to the system

Types of Structure Charts

- transaction structure: control module calls subordinate modules (each handles a transaction) - transform structure: control module calls several subordinate modules in sequence

Types and Sources of User Documentation

- types: reference documents, procedures manuals, tutorials - sources: users' business tasks, commands and menus in the user interface, definitions of terms

Basic Principles of Output Design

- understand report usage: reference or cover-to-cover, frequency, real-time or batch reports - manage information load: all needed information, no more - minimize bias - utilize various report types and media to satisfy users' output requirements

Role of Use Cases

- use case: a set of activities that produce some output results - trigger: event that causes the use case to be executed - event-driven modeling: everything in the system is a response to some triggering event - benefits of use case modeling 1. provides tool for capturing functional requirements 2. helps to manage complexity 3. provides means of communicating with users

Guidelines for Creating Indexes

- use indexes sparingly for transaction systems - use many indexes to increase response times in decision support systems - for each table: create a unique index based on the primary keys, and create an index based on the foreign key - create an index for fields used frequently for grouping, sorting, or criteria

Managing the Schedule

- use initial time estimates as a baseline - revise time estimates as construction proceeds - fight against scope creep - monitor "minor" slippage - create risk assessment and track changing risks - fight the temptation to mower quality to meet unreasonable schedule demands

Motivation

- use monetary rewards cautiously - use intrinsic rewards including recognition, responsibility, advancement and the chance to learn new skills - things to be careful not to do: assigning unrealistic deadlines, ignoring good efforts, accepting a low-quality product, making an important decision without the team's input

Integration Testing

- user interface testing: tests each interface function - use-scenario testing: ensures each use scenario works correctly - data flow testing: tests each process in a step-by-step fashion - system interface testing: ensures data transfer between systems

User Interface Design Process - Understand the Users

- users likely will have very different goals and intentions when using the system - use personas to develop characterizations of various user groups: interests, typical behaviors, goals and objectives, expectations - plan a user interface that will be satisfying for the particular user group - use scenarios: outline the steps that the users perform to accomplish some part of their work - presented in a simple narrative tied to the related DFD - document the most common paths through the use case so interface designs will be easy to use for those situations

Fully Dressed Use Case

- very thorough, detailed, and highly structure - adds new sections, including: alternative courses, inputs and outputs for steps, summary inputs and outputs - use this format when: users are not closely engaged with development team, project has high complexity and high risk, test cases need to be fully described, remote collaborating teams need detailed shared understanding of user needs

Coordinating Activities

- weekly (hopefully brief) meetings - create and follow standards - organize programmer's work areas: development area, testing area, production area - implement change control mechanisms - use program log to monitor program changes

Unit Testing

- white-box testing: looks inside the module at actual code - black-box testing: focuses on whether the unit merits requirements stated in specification, not driven by programmer's interpretation

Conversion Modules

- whole system: all modules converted in one step - modular: when modules are loosely associated, they can be converted one at a time

The System Request

- written document that describes business reasons for the project and its expected value - 5 key elements: project sponsor: initiates project and serves as primary contact business need: business-related reason for initiating the system business requirements: new or enhanced business capabilities that the system will provide business value: benefits the system will create for the organization special issues or constraints: issues that pertain to approval committee's decision

Documenting Requirements

-Requirements definition report -Text document listing requirements in outline form -Organized in logical groupings -Priorities may be included Key purpose is to define the project scope -what is included -what is not included

Conversion Styles

-direct: new system instantly replaces the old - parallel: for a time both old and new systems are used, old is abandoned when new is proven fully capable

Steps in Change Management

1. Revise management policies 2. Assess costs and benefits models of potential adopters 3. Motivate adoption 4. enable people to adopt

Moving from Logical to Physical Data Models

1. change entities to tables or files 2. change attributes to fields 3. add primary keys 4. add foreign keys 5. add system-related components

Steps to Conduct an Economic Feasibility Analysis

1. identify costs and benefits 2. assign values to costs and benefits 3. determine cash flow 4. assess project's economic value: (ie. return on investment, break even point, net present value)

Building Use Cases

1. identify the use cases 2. identify the major steps 3. identify elements with each major step (inputs and outputs) 4. confirm use case with users

Steps in Building the Structure Chart

1. identify top level modules and decompose them into lower levels 2. add control connections 3. add couples 4. review and revise again and again until complete

Quality Checklist

1. library modules have been created where ever possible 2. the diagram has a high fan-in structure 3. control modules have no more than 7 subordinates 4. each module performs only one function (high cohesion) 5. modules sparingly share information (loose coupling) 6. data couples that are passed are actually used by the accepting module 7. control couples are passed from "low to high" 8. each module has a reasonable amount of code associated with it

Classic Mistakes in Project Management

1. overly optimistic schedules 2. failure to monitor the schedule 3. failure to update the schedule 4. adding people to a project late

Project Phases + Deliverables

1. planning: the why, identify reasons for building the systems, and how team should go about building it - system request, feasibility study, project plan 2. analysis: who uses the system, what it will do, and when and where it will be used - system proposal 3. design: determine how the system will work - alternative matrix, system specification 4. implementation: actual delivery of the system (usually longest and most expensive phase - test plan, programs documentation, migration and support plans, problem report, change request

Sources of Change Requests

1. problem reports from operations group 2. requests for enhancements from users 3. requests from other systems development projects 4. change requests from senior management

Avoid 4 Classic Mistakes

1. research-oriented development: if you use state-of-the are technology, lengthen planned time 2. using "low-cost" personnel: if using a significant number of entry level personnel, lengthen planned time 3. lack of code control: use source code library to keep programmers from changing the same code at the same time 4. inadequate testing: always allocate sufficient time for formal testing

User Interface Design Process - Interface Evaluation

4 common approaches: - heuristic evaluation: compare design to a checklist - walkthrough evaluation: team simulates movement through components - interactive evaluation: users try out the system - formal usability testing: expensive, detailed use of special lab testing

Analysis Phase

Analysis: breaking a whole into its parts with the intent of understanding the parts' nature, functions, and interrelationships - planning phase deliverables are the key inputs into the analysis phase - basic process of analysis involves 3 steps: 1. understand the existing situation 2. identify improvements 3. define requirements for the new system

CRUD Matrix

Create, Read, Update, Delete: operations done to attributes - technique used to compare and make sure there's a balance between the the DFD and the ERD

Business Contingency Plan

a plan for maintaining or resuming business operations should unexpected events occur - what do we do if things go very wrong during conversion?

Requirements Elicitation Technique - Observation

act of watching process being performed - use when validity of data collected using other methods is in question - use when the complexity of certain aspects of the system prevents end-users from providing a clear explanation - strengths: data gathered may be highly reliable, can see what is being done, relatively inexpensive, can do work measurements (if needed) - weaknesses: people may perform differently when being observed, work may vary in difficulty and volume, some activities may take place at odd times, tasks being observed are subject to various types of interruptions

Denormalization

add redundancy back to data storage design to reduce the number of joins performed in a query

Advances in Architecture Configuration

advances in hardware, software, and networking have given rise to a number of new architecture options - virtualization: creation of a virtual device or resource -- server virtualization: partitioning a physical server into smaller virtual servers -- storage virtualization: combining multiple network storage devices into what appears to be single storage unit - cloud computing: computing resources obtained as a service

Requirements Analysis Strategies - Activity Elimination

analysts and managers work together to identify: - how the organization could eliminate each and every activity in the business process - how the function could operate without it - what effects are likely to occur

System Analyst Role

analyze the business, identify opportunities for improvement, + design information systems to implement the improvements - must have both technical and business skills, be able to communicate effectively (particularly in writing)

Client-Server Architectures

balance the processing between client devices and one or more server devices - clients are responsible for the presentation logic, and the data access logic and data storage - a thick and fat client contains all or most of application logic, whereas a thin client contains a small portion of the application logic - benefits: scalable; can support different types of clients and servers through middleware; presentation logic, application logic, and the data processing logic can be independent; if a server fail, only the applications requiring that server are affected - major limitation: their complexity

Influences on Acquisition Strategies

business need, in-house experience, project skills, project management, time frame

Nonfunctional Requirements

characteristics or behavioral properties the system must have - operational: physical and technical environments in which the system will operate - performance: speed, capacity, and reliability of the system - security: who has authorized access to the system under what circumstances - cultural + political: cultural and political factors and legal requirements that affect the system

DFD Balancing

conservation of inputs and outputs to a data flow process when that process is decomposed to a lower level - balanced means: number of inputs to lower level DFD equals number of inputs associated process of higher-level DFD, and number of outputs from lower level DFD equals number of outputs from associated process of higher-level DFD

Using the ERD to Show Business Rules

constraints followed when the system is in operation - ERD symbols show different ways that instances of entities are related

Primary Goal of Information Systems

create value for organizations - reason many have been abandoned is that analysts have built systems without understanding the organization

Program Design

creating instruction for the programmers - top-down, modular approach: begin with the "big picture" and gradually add detail - program design document: all structure charts and specifications needed by programmers to implement the system

System Interfaces

define how systems exchange information with other systems

User Interfaces

define how the system will interact with the users - navigation mechanism: provides the way for users to tell the system what to do - input mechanism: defines the way the system provides information to users or other systems - output mechanism: defines the way the system provides information to users or other systems

Architectural Design Purpose

determine how the software components of the information system will be assigned to the hardware devices of the system - 3 primary components -- client computers: input-output devices employed by users -- servers: larger multi-user computers used to store software and data -- network: connects the computers

Project Methodology Options: System Prototyping

develop a simplified version to give to users to get feedback, done when users have difficult defining requirements

Project Methodology Options: Parallel Development

divides project into a number of sub-projects, doing multiple sub-projects at the same time can accelerate the speed of the project - sub-projects must be independent of each other

Hardware and Software Specification

document that describes what hardware and software are needed to support the application - used if new hardware or software must be purchased - communicates project needs - actual acquisition of hardware and software usually left to a purchasing department - determine software needs: operating system, special purpose software; training, warranty, maintenance and licensing needs - determine hardware needs: server(s), clients, peripherals, backup devices, storage, minimum configuration needs

Developing Documentation

documentation provides information to make system easier to use and repair - system documentation: intended to help programmers and analysts understand and maintain the system after it is installed - user documentation: intended to help users operate the system

Project Methodology Options: Waterfall Development

each phase is completed before proceeding to next phase, very difficult to go back, takes longer, favored for very large projects when you want to identify all details completely before moving ahead - advantage: requirements are clearly identified + changes are limited as project goes on - disadvantage: can lead to issues if changes are required

Requirements Analysis Strategies - Activity Based Costing

examines cost of each major process or step in a business process - both direct and indirect costs are considered - analyst identifies the most costly steps and focuses improvement efforts on them

Technical Feasibility

extent to which the system can be successfully designed, developed, + installed by the IT group - following risks should be considered: 1. are users and analysts familiar with the application? 2. are they familiar with the technology? 3. project size 4. compatibility of the system with existing technology

Requirements Analysis Strategies - Root Cause Analysis

focuses on problems first rather than solutions - challenges assumptions about why problem exists - trace symptoms to their causes to discover the "real" problem

Requirements Analysis Strategies - Outcome Analysis

focuses on understanding fundamental outcomes that provide value to customers - considers what the organization could enable the customer to do

Project Methodology Options: Iterative Development

form of rapid application development, incorporates special techniques to speed up analysis, design and implementation with the goal of getting some portion of the system in the hands of users, breaks overall project into a series of versions

Process Model

formal way of representing how a business operates - illustrates activities performed and how data moves among them

Data Model

formal way of representing the data that are used and created by a business system - logical data model: shows the organization of data without indicating how it is stored, created, or manipulated - physical data model: shows how the data will actually be stored in databases or files

Factors in Hardware and Software Specifications

functions and features, performance, legacy databases and systems, hardware and OS strategy, cost of ownership, political preferences, vendor performance

Error Discovery Rates for Different Testing Stages

highest for integration test, lowest for acceptance test (beta)

Data Storage Design

how data is stored and handled by programs that run the system - goals: efficient data retrieval (response time), optimize storage efficiency (space used)

Estimating Business Values

identify sources such as: increased sales, decreased costs, reduced headcount, lower turnover - assign values as initial estimates

Indexing

index- minitable containing values from one or more columns in a table and the location of the values within the table - indexes require overhead: take up storage space

User Interface Design Process - Interface Standards Design

interface standards: basic elements that are common across individual screens, forms, and reports within the application - interface metaphor: concept from real world - interface objects: fundamental building blocks of system - interface actions: common commands employed by users - interface icons: simple pictures representing status or actions - interface templates: layout guide for all screens

Making the Transition to the New System

involves managing change from pre-existing norms and habits - change management involves: -- unfreezing: loosening up peoples' habits and norms -- moving: transition from old to new systems -- refreezing: institutionalize and make efficient the new way of doing things

Principles for User Interface Design

layout, content awareness, aesthetics, user experience, consistency, minimize user effort

Project Work Plan

list of all tasks plus: duration of task, current task status, task dependencies, + key milestone dates

Elements of Architecture Design

major architecture components of any system are the software and the hardware - all software systems can be divided into 4 basic functions: -- data storage -- data access logic: the processing required to access stored data -- application logic: logic documented in the DFDs, use cases, and functional requirements -- presentation logic: display of information to user and the acceptance of the user's commands

Requirements Analysis Strategies - Technology Analysis

many major changes in business in recent times have been enables by new technologies - begins by having the analysts and managers develop a list of important and interesting technologies - group then systematically identifies how each and every technology could be applied to the business process and identifies how the business would benefit

Timeboxing

method for managing scope creep - set delivery date: deadline should not be impossible, should be set by development group - prioritize features by importance - build the system once - postpone unfinished functionality - deliver system with core functionality

User Interface Design Process - Interface Design Prototyping

mock-up or simulation of screen, form, or report - common methods include: paper sketches, wireframe diagrams, storyboards, wireflow diagrams, HTML prototype, language prototype

Project Methodology Options: V-Model

pays more explicit attention to testing, as elements + components are defined, testing is also defined, can take longer with goal of having a high quality system - used for systems that are critical like medical or airplane systems

Entity Relationship Diagram (ERD)

picture showing the information created, stored, and used - entities: represent "things" that the system needs to store information about - attribute: property of an entity, should be used by at least one business process, broken down to most useful level of detail - relationships: associations between entities

Architecture Design

plans for how the system will be distributed across computers and what hardware and software will be used for each computer - key factors: nonfunctional requirements developed early in the analysis phase play a key role in architecture design

Data Flow Diagramming (DFD) + Elements

popular technique for creating process models - process: activity or function performed for a specific business reason, may be manual or computerized, transforms inputs into outputs (needs at least 1 of each) - data flow: single piece of data or a logical collection of data, always starts or ends at a process - data store: collection of data that is stored in some way, data flowing out is retrieved from the data store, data flowing in updates or is added to the data store - external entity: person, organization, or system that is external to the system but interacts with it

Factoring

process of dealing with "low" cohesion, separates tasks into different modules and reduces use of control flags

Interface Design

process of defining how the system will interact with external entities

Functional Requirements

processes the system should perform and information the system must contain - process-oriented functional requirement: process the system must perform or do - information-oriented functional requirement: information the system must contain

Project Methodology Options: Throwaway Prototyping

prototypes are used to explore design alternatives, each issue is examined by building a prototype, focuses on design of the system, there's an understanding of what needs to be done, but not how it will be done

Clustering

reduce the number of times storage must be accessed by physically placing like records close together - intrafile clustering: similar records in the table are stored together - interfile clustering: combining records from more than one table that typically are retrieved together

Cardinality

refers to the number of times instances in one entity can be related to instances in another entity - ie. 1:1, 1:N, M:N

Modality

refers to whether of not an instance of a child entity can exist without a related instance in the parent entity - not null: an instance in the related entity must exist for an instance in another entity to be valid - null: an instance in the related entity is necessary for an instance in another entity to be valid

Requirements Determination

requirement: statement of what the system must do or what characteristics it needs to have - requirements describe: what the business needs, what the users need to do, what the software should do, characteristics the system should have, how the system should be built

Requirements Analysis Strategies - Duration Analysis

requires a detailed examination of the amount of time it takes to perform each process in the as-is system - compare the total time to complete basic steps and the total time for the overall process - significant differences indicates process is badly fragmented - potential solutions: process integration, parallelization

Server-Based Architecture

server computer handles presentation logic, application logic, data access logic, and data storage

Requirements Elicitation Technique - Questionnaires

set of written questions for obtaining information from individuals - selecting participants: using a sample of people who are representative of the entire group - designing the questionnaire: following good practice guidelines - administering the questionnaire: improve the response rates - follow-up: developing a report - strengths: most can be answered quickly, relatively inexpensive, allow individuals to maintain anonymity, can be tabulated and analyzed quickly - weaknesses; response is often low, incomplete questionnaires returns, body language cannot be observed, cannot clarify a vague or incomplete answer to any question

Physical Process Models + Data Models

show the implementation details and explain how the system will work, including: actual, specific technology; format of information; human interaction with system

Requirements Elicitation Technique - Document Analysis

study of existing material describing the current system - formal system: described in forms, policy manuals and organization charts - informal system: user additions and unused elements in forms and reports

Requirements Analysis Strategies - Informal Benchmarking

studying how other organizations perform a business process - common for "customer-facing" process - analyst visits other organizations as a customer to watch how the business process is performed

Conversion Strategies

style, locations, and modules

Volumetrics

technique of estimating the amount of data that the hardware must support - calculate amount of raw data - all the data stored within the database - calculate the overhead requirements based on the DBMS vendor's recommendations - record the number of initial records loaded into the tables, as well as the expected growth per month

Normalization

technique used to validate data models - process to ensure data integrity and eliminate redundancy in database design - process to ensure flexibility of a database, making it easy to add, change or delete entities and attributes - three normalization rules are common: -- do any attributes have multiple values for a single instance of an entity? -- is the identifier composed of more than one attribute? if so, are any attribute values dependent on just parts of the identifier? -- do any attribute values depend on an attribute that is not the entity's identifier?

Use Cases

text based method of describing and documenting complex processes - add detail to requirements outlined in the requirements definition - systems analysts work with users to develop use cases - systems analysts develop process and data models later based on the use cases

Creating the Project Plan

upon project approval, project manager must: - select the best project methodology - develop a project work plan - establish a staffing plan - create ways to coordinate and control the project

The Programmer Paradox

why does adding more programmers to a late project make it later? - to address this issue, projects requiring a large team should be broken into a series of independent, smaller parts