Systems Analysis & Design Ii

Front 1

System Design

Back 1

The specification of a detailed computer-based solution

Front 2

Model-Driven Design

Back 2

a system design approach that emphasizes drawing system models to document technical and implementation aspects of a system

Front 3

Modern Structured Design

Back 3

A system design technique that decomposes the system's processes into manageable components.

Front 4

Information engineering (IE)

Back 4

a model-driven and data--centered, but process-sensitive, technique for planning, analyzing, and designing information systems. Primary Tool: data model diagram

Front 5

Prototyping

Back 5

a modern engineering based approach to design, an iterative process involving a close working relationship between the designer and the users
* encourages and requires active end-user participation
*Iteration & change are a natural consequence of systems development(prototype evolves through iteration into the required system;
*an active (not passive) model that end users can see, touch, feel and experience.
*a working equivalent to a paper design specification, with one exception - errors can be detected much earlier
*can increase creativity because it allows for quicker user feedback - can lead to better solutions.
* consolidates parts of phases that normally occur one after the other.
-encourages ill-advised shortcuts through the life-cycle
- encourages return to the "code, implement, and repair" life cycle.
- does not negate the need for the systems analysis phases
- cannot completely substitute any prototype for a paper specification
- does not address numerous design issues

Front 6

Object-Oriented Design

Back 6

*Newest Design Strategy
attempt to eliminate the separation of concerns about data and process. Used to refine the object requirements definitions identified earlier during analysis and to define design-specific objects.

Front 7

Rapid Application Development (RAD)

Back 7

a systems design approach that utilizes structured, prototyping and JAD techniques to quickly develop systems.

Front 8

Systems Design for In-House Development (Build Solution)

Back 8

1st: Analyst seeks to design a system that both fulfills requirements and will be friendly to its end users.
2nd: Still very important, the analyst seeks to present clear and complete specifications to the computer programmers and technicians.

Front 9

First Step - Design the Application Architecture

Back 9

defines the technologies to be used by (and used to build) one, more or all information systems in terms of their data, processes, interfaces and network components

accomplished by analyzing the data models and process models that were initially created during requirements analysis.

Front 10

Physical Data Flow Diagram

Back 10

a process model used to communicate the technical implementation characteristics of an information system.

Front 11

Input - Classified by 2 characteristics

Back 11

1. How the data is initially captured, entered and processed
2. the method and technology used to capture and enter the data

Front 12

Requirements for inputting data into the computer

Back 12

Source documents, input screens and methods and procedure for getting the data into the computer.

Front 13

Batch processing

Back 13

Old style - data about many transactions is collected as a single file (batch file (disk) ) for processing as at one time.
New style - data is processed as soon as it has been keyed

Front 14

Online processing

Back 14

a data processing method whereby data about a single transaction is processed immediately

Front 15

Point of Sale
Sound
Speech
Electromagnetic (radio freq)
Smart Card

Back 15

Data is almost always processed immediately as a transaction or inquiry.

Front 16

Optical Mark (oldest form of automatic data capture)
Magnetic Ink (bank checks)

Back 16

Data is almost always processed as a batch.

Front 17

Biometric

Back 17

Unique human characteristics become data. Read by biometric sensors. Primary applications are security and medical monitoring.
Data is Always processed immediately.

Front 18

Data Capture

Back 18

Identification and acquisition of new data

Front 19

Source Document

Back 19

a form used to record data about a transaction

Front 20

Data entry

Back 20

the process of translating data into a computer-readable format.

Front 21

Remote Batch Processing

Back 21

A data processing method whereby data is entered online - using online editing techniques - collected as a batch, and processed at a later time. (ie, handheld devices - ups)

Front 22

ADC - Automatic Data Capture

Back 22

Optical Mark - (primarily batch processing-oriented) Multiple Choice on exams. Useful when the number of possible data values is relatively limited and highly structured.
Optical Charater Rec (OCR) - Depends on the handwriting of the user. Bar Coding is the most prevalent form.
Magnetic Ink - credit cards, checks, building security access control and employee attendance tracking.
Electromagnetic Transmission - radio frequency to identify physical objects. Public transportation tracking and control, tracking manufactured products, tracking animals.
Smart Cards - ability to store a massive amount of info. they contain a microprocessor, memory circuits and a battery.
Biometric - based on unique human chars or traits. The most accurate and reliable means for identification - Security systems.

Front 23

Internal Controls

Back 23

requirement in all computer-based systems. Ensure that the data input to the computer is accurate and that the system is protected against accidental and intentional errors and abuse - including fraud.

Front 24

Internal Control guidelines

Back 24

1. number of inputs monitored

2. Ensure that the data is valid

Front 25

Validation of Data

Back 25

1. Existence Checks: determine that all required fields have actually been entered.
2. Data-type Checks - the correct type of data is input Alpha vs numeric
3. Domain checks - the input data for each field falls within the legitimate set or range of values defined for field. (Upper limit on pay range)
4. Combination checks - determine whether a known relationship between two fields is valid. ie, Pontiac - Firebird
5. Self-checking digits - determine data entry errors on primary keys -- calculated by applying a formula - modulus 11.
6. Format checks - compare data entered against the known formatting requirements for that data. IE, leading zeros.

Front 26

Input Controls are necessary (in addition to validity checks) because:

Back 26

most applications are networked. Erroneous data is both a network traffic bottleneck and a detractor for transaction throughput and response time.

Front 27

GUI - Graphical User Interface

Back 27

Provide a more user-friendly interface. Also present more complex design issues. Controls = widgets for building a user interface - included in most contemporary application development environments.

Front 28

Repository-based Programming

Back 28

programming approach that shares controls and code via the repository.

Front 29

Common GUI Controls for Input

Back 29

Text Box - most common
Radio Button
Check Box
List Box
Drop-Down List
Combination Box
Spin Box
Buttons`

Front 30

Text Box

Back 30

Most common control, consists of a rectangular-shape box that is usually accompanied by a caption. Guidelines:
Avoid using abbreviations for captions.
Only the 1st character of the captions text should be capitalized.l
Location of caption is significant - user should be able to clearly associate the caption with the text box - caption should be located to the left of the actual box, or left aligned immediately above the box.
the caption should be followed by a colon to help the user visually distinguish the caption from the box.

Front 31

Radio Button

Back 31

Provide the user with an easy way to quickly identify and select a particular value from a value set.
Circle is located to the left of the textual description of the value choice.
When a choice is selected, any default or previously selected choice's circle is deselected.
Most appropriate when a use may be expected to input data that has a limited predefined set of mutually exclusive values.
Should present the alternatives vertically aligned and left-justified to aid the user in browsing.
Adequate spacing should be used to help visually distinguish the choices.
Group of choices should be visually grouped to set them off from other input controls appearing on screen.
Grouping should also contain a appropriate meaningful caption.
Should not be used for yes/no or on/off.

Front 32

Check Box

Back 32

Consists of a square box followed by a textual description of the input field for which the user is to provide the yes/no value.
provide user flexibility - keyboard or mouse input.
Yes = checked box, No - blank box.
When grouping - arrange the group of check box controls so that they are aligned vertically and left-justified.
If necessary, align horizontally and be sure to leave adequate space to visually separate the controls from one another.
Provide appropriate sequencing for input fields according to their textual description - when number of check box controls is large - sequencing should be alphabetical.

Front 33

List Box

Back 33

Rectangular and contains one or more rows of possible data values.
Requires that the user select a data item's value from a list of possible choices.
Large number of possible values = scroll bars for navigating.
Guidelines:
Should have a descriptive caption - Avoid abbreviations, capitalize only the first word.
Should be followed by a colon to help user visually distinguish the caption from the box.
Caption should appear left justified immediately above the actual list box.
Should contain a highlighted default value.
Width of the box should be large enough for most characters of fixed-length input data to be entered and viewed by user.
Length should allow for at least three choices and be limited in size to containing about seven choices.

Front 34

Choosing between Radio Button and List Box

Back 34

Decision is normally driven by the number of possible values for the data item and the amount of screen space available for the control.

Front 35

Drop-Down List

Back 35

Should be used in cases where the data item has a large number of predefined values and screen space availability prohibits the use of a list box.
Guidelines:
Same as list boxes except - placement of the caption is generally either left-aligned immediately above the selection field portion of the control or located to the left of the control.

Front 36

Combination Box

Back 36

Combo Box - combines the capabilities of a text box and list box. Gives the user the flexibility of entering a data item's value or selecting its value from a list
Most appropriatey used where screen space is limited and it is desirable to provide the user with the option of selecting a value from a list or typing a value that may or may not appear as an option in the list.
Guidelines:
Same as drop-down lists

Front 37

Spin Box

Back 37

consists of a single-line text box followed immediately by two small buttons. Top button has an arrow pointin up, an an arrow pointing down. . Allows the user to enter data directly into the associated text box or to select a value by clickinhg on the buttons to scroll or "spin" through a list of values. the buttons have a unit of measure associated with them. increase by one, decrease by one...

Front 38

Buttons

Back 38

Serve several purposes - allow a user to commit all of the data to be processed, or cancel a transaction, or get help. Can be used to navigate between instances of the same form.

Front 39

Advanced Input Controls

Back 39

Drop-down Calendar
Slider edit calendar
Masked edit control
Ellipsis control
Alternate Numeric Spinner
Internet Hyperlink
Check List Box
Check tree list box - (hierarchically organized into a treelike structure)

Front 40

Input Design Process

Back 40

1. Identify system inputs and review logical requirements.
2. Select appropriate GUI controls.
3. Design, validate and test inputs using some combination of : a) Layout tolls (sketches, charts, case tools)
b) Prototyping tools
4. If necessary, design the source document.

Front 41

Expert User

Back 41

an experienced user who has spent considerable time using specific application programs. Want to be able toaccomplish their task in as few actions and keystokes as possible.

Front 42

Novice User

Back 42

Sometimes called a casual user.
Les experienced compuiter user who will generally use a computer on a less frequent, or eve occasional basis - may be viewed as discretionary. Novice users also usually graduate to expert users through practice & experience.

Front 43

Interface Elements Causing Difficulty:

Back 43

Excessive use of computer jargon and acronyms
Nonobvious or less-than-intuitive design
Inability to distinguish between alternative actions
Inconsistent problem-solving approaches
Design Inconsistency

Front 44

Commandments of User Interface Design

Back 44

1. Understand your users and their tasks.
2.Involve the user in interface design.
3. Test the system on actual users.
4. Practice iterative design.

Front 45

Human Engineering Guidelines

Back 45

* The system user shoud always be aware of what to do next - should always provide instructions on how to proceed, back up, exit, and the like.
1. Tell the user what the system expects right now. (A simple message - ready, type command...)
2. Tell the user that data has been entered correctly. (Can be as simple as moving the cursor to the next field)
3. Tell the user that data has not been entered correctly. (Short, simple messages about the correct format)
4. Explain to the user the reason for a delay in processing. (Simple messages - sorting, please stand by...)
5. Tell the user that a task was completed or was not completed. (A message - printing complete...)
* Screen should be formatted so that the various types of information, instructions, and messages always appear in the same general display area.
* Messages, instructions, or information should be displayed long enough to allow the system user to read them.
* Use display attribtes sparingly. (blinking, highlighting)
* Default values for fields and answers to be entered by the user should be specified.
* Anticipate the errors users might make.
* With respect to errors, a user should not be allowed to proceed withouth correcting an error.
* If the user does something that could be catastrophic, the keyboard should be locked to prevent any further input, and an instruction to call the analyst or technical support should be displayed.

Front 46

Dialogue

Back 46

The overall flow of screens and messages for a application.

The tone and terminology of a dialogue are very important human factors in user interface design.

Front 47

Guidelines for Tone of Dialogue:

Back 47

* Use simple, grammatically correct sentences
* Don't be funny or cute!
* Don't be condescending.

Front 48

Guidelines for Terminology used in Dialogue:

Back 48

* Don't use computer jargon.
* Avoid most abbreviations
* Use simple terms.
* Be consistent in your use of terminology.
* Carefully phrase instructions - use appropriate action verbs. Recommendations: Select or choose instead of pick; Type, not enter - (enter may be confused with the enter key); use press, not hit or depress to refer to keyboard actions.
* When referring to the on-sreen mouse cursor, use the term position the cursor, not point the cursor.

Front 49

Platform Independence

Back 49

Instead of writing a user interface for each anticipated computing platorm and OS, you write it for one or two browsers. Most browsers run in many operating systems making it possible to design a user interface that is less dependent on the computer itself.

Front 50

Paging

Back 50

Displaying a complete screen of characters at a time.

Front 51

Scrolling

Back 51

Displaying information up or down a screen - one line at a time.

Front 52

Function Keys

Back 52

A series of special keyboard keys used to program special operations.

Front 53

Mouse

Back 53

A device used to cause a pointer to move across a display screen - most common pointer.

The most common user interface is graphical.

Front 54

Menu driven

Back 54

a dialogue strategy that requires that the user select an action from a menu of choices
Oldest & most commonly employed dialogue strategy - predate GUIs.
Can be logically grouped into high-level options to simplify presentation.
No technical limit to how deeply hierarchical menus can be nested.
The deeper the nesting, the greater the need for direct paths to deeply rooted menu options for the expert user

Front 55

Screen Thrashing

Back 55

Navigating through multiple levels

Front 56

Mnemonic

Back 56

Alt-key plus the underlined letter of a menu

Front 57

Ellipses

Back 57

(three dots) indicates that a dialogue box will subsequently appear (pop up) to present additional options or collect additional instructions

Front 58

Cascading Menu

Back 58

a named submenu action will have a small arrow indicating yet another submenu

Front 59

Tear Off Menu

Back 59

user can select a drop-down menu or cascaded menu, drag it off the menu bar and relocate it elsewhere on the screen - useful if the menu must be continually used.

Front 60

Pop-up Menu

Back 60

context sensitive and dependent on a pointing device. Menu that pops up depends on the location of the cursor on the screen. The right-button click will bring up a menu displaying only those actions that apply to whatever is at that cursor location - context sensitive. No visual clue to their presence.

Front 61

Toolbars

Back 61

Consist of icons that represent menu shortcuts for actions and commands that tare normally embedded in the drop-down and cascading menus

Front 62

Docking

Back 62

applications allow toolbars to be relocated to the left, right, or bottom of the window at the convenience of the user.

Front 63

Float

Back 63

Movable menus - within any convenient location inside the window

Front 64

Hypertext / Hyperlink Menus

Back 64

Products of contemporary web-based user interfaces. Originally created to navigate within and between Web pages and sites. The word or phrase navigates the user to the associated page (or bookmark in a page.

Front 65

Instruction-Driven Interfaces

Back 65

Instead of menus, or in addition to menus, some applications are designed using a dialogue based on an instruction set also called a command language interface. User must learn the syntax of the instruction set.

Front 66

Three types of Syntax for instruction sets

Back 66

Language based syntax
Mnemonic syntax
Natural language syntax

Front 67

Language based syntax

Back 67

Built around a widely accepted command language that can be used by the user to invoke actions. i.e., Query by Example (QBE) and Structured Query Language (SQL) - DB languages that can be used by the end user to access data & create custom reports.

Front 68

Mnemonic syntax

Back 68

Built around commands defined for custom information system applications. Users are provided with a screen console in which they can enter commands that will invoke actions and responses from the computer user. Commands should be meaningful to the user.

Front 69

Natural language syntax

Back 69

allows users to enter questions and commands in their native language. The system interprets these commands against a known syntax and requests clarification if it doesn't understand what the user wants.

Front 70

Question-Answer Dialogue

Back 70

Primarily used to supplement either menu-driven or instruction-driven dialogues. i.e., Do you want to see all parts? [No]
A droip-down list of alternative answers may accompany each question. Together these questions and answers define a business transaction.

Front 71

Authentication & Authorization

Back 71

Guidelines:
- assign privileges to roles, not to individuals.
- For each role, the specific privileges that should be assigned to the role need to be defined. This is needed both to design an appropriate log=-in interface and to functionally specify the complete authentication and authorization security model for the system.
- different users views could actually be applied to customize the user interface or different categories of users.

Front 72

Ghost

Back 72

Change the font from black to gray

Front 73

Complete Help System

Back 73

Includes a table of contents, numerous instructions, examples, and a thorough index. A well-designed help system will implement a wide range of help elements.

F1 Function key is almost universally accepted as a help request command.
A standard Help menu bar option is commonly used to organize and present different types and levels of help.
Tool tip controls provide pop-up help associated with specific tools and object icons. They appear when the user momentarily positions the cursor over the ion or object on the screen.
Appropriate for all icons because the user interface designer can never be3 assured that the image or label appearing on an icon is going to be meaningful to the system user.
Two additional & common help features are help wizards and help agents(assistants)

Front 74

Help Wizard

Back 74

guides the users through complex processes by presenting a sequence of dialogue boxes that require user input and system feedback:
1. the dialogue usually includes a series of instructions or questions for the user to respond to.
2. contains explanations to aid in the user's understanding and decision making.
3. Wizard also provides a button for requesting more detailed help in completing the task.
4. The "Next" button suggest addtiional or subsequent steps to be supported by the wizard (usually changes to "Finish" once a sequence of dialogue boxes is complete.)

Front 75

Agent

Back 75

Reusable software object that can operate across different applications and networks. i.e., Microsoft's "Animated Paper Clip".

Front 76

Natural Language Processing Technology

Back 76

Natural language processing technology allows the user to write an inquiry in natural language phrases that are interpreted by the agent to present the most likely help responses.

Front 77

Over-riding theme for developing a good help system

Back 77

Designer should anticipate system user errors. The designer should always provide the system user with help to resolve the error.
After leaving any help session, users should always be returned to where they were in the application before requesting or receiving the help.

Front 78

Today's graphical environments create an emphasis on developing an overall system that blends well into the user's workplace environment.

Back 78

Most GUI-based application development environments can be easily used to construct nonfunctional prototypes of user interface screens.

Front 79

User Interface Design Process

Back 79

1. Chart the user interface dialogue.
2. Prototype the dialogue and user interface
3. Obtain user feedback.
4. If necessary, return to step 1 or 2.

Front 80

Chart the Dialogue

Back 80

Screens typically occur in a specific order, may be able to toggle among the screens. Some screens may appear only under certain conditions, Some screens may occur repetitively until some condition is fulfilled.

Front 81

State Transition Diagram (STD)

Back 81

A tool used to depict the sequence and variation of screens that can occur during a user session.(road map)
Note: Can become quite large. Common to partition the diagram into a set of separate simpler and easier to read diagrams.

Front 82

Obtain User Feedback

Back 82

Exercising (or testing) the user interface is a key advantage of all the prototyping environments - means that system users experiment with and test the interface design before extensive programming and actual implementation of the working system.

Front 83

Systems Construction

Back 83

The development, installation and testing of system components.

Front 84

Systems Implementation

Back 84

the delivery of the system into production - day-to-day operation

Front 85

Trigger for the Systems Construction phase

Back 85

the approval of the physical design specifications resulting from the design phase.

Front 86

Purpose of the Construction Phase

Back 86

To develop and test a functional system that fulfills business and design requirements and to implement the interfaces between the new system and existing production systems.

Front 87

Tasks in Construction Phase

Back 87

1. Build and test networks (if necessary)
2. Build and test Databases
3. Install and test new Software Packages (if necessary)
4. Write and Test New Programs.

Front 88

Build and Test Networks

Back 88

Network requirements - established during the analysis phase of systems analysis.
Developed distributed data and process modes - using these technical deign specs to implement the network architecture for an information system is a prerequisite for the remaining construction and implementation activities.

Front 89

Build and Test Databases

Back 89

Task must immediately precede other programming activities because databases are the resources shared by the computer programs to be written.
Primary input - Database schema
Final product of task is an unpopulated database structure for the new database.

Front 90

Install and Test new Software Packages

Back 90

The first task in the life cycle specifically related to the applications programmer.
Main input is the new software packages and documentation that are received from the system vendors.
System Analyst - clarifies requirements.
System Designer clarify integration requirements and program documentation to be used in the testing phase.
Principle deliverable - installed and tested software package that is made available in the software library.

Front 91

Write and Test New Programs

Back 91

Primary inputs - the technical design statement, plan for programming and test data developed during systems design.
Check for possible reusable software components that available in the library.
Principal deliverables are the new programs and reusable software components that are placed in the software library.
Also results in program documentation that may need to be approved by a quality assurance group.

Front 92

Stub Test

Back 92

a test performed on a subset of a program
performed on individual events or modules of a program - the testing of an isolated subset.

Front 93

Unit or Program testing

Back 93

testing in which all the events and modules that have been coded and stub tested for a program are tested as an integrated unit - the testing of an entire program.

Front 94

Systems Testing

Back 94

A test performed on an entire system - ensures that application programs written and tested in isolation work properly when they are integrated into the total system.
A system test plan should be developed and followed for testing the system.
One or more test scripts are developed for each functional and nonfunctional requirement.

Front 95

Implementation Phase

Back 95

1. Conduct System Test
2. Prepare Conversion Plan
3. Install Databases
4. Train Users
5. Convert to New System

Front 96

Implementation Phase

Back 96

Functional system from the construction phase is the key input to the implementation phase.
The deliverable of the implementation phase is the operational system that will enter the operation and support stage of the life cycle.

Front 97

1. Conduct System Test

Back 97

Conduct a final system test - facilitated by the systems analyst.
Primary inputs to this task include the software packages, custom-built programs and any existing programs comprising the new system.
May result in required modifications to programs prompting the return to a construction phase task.

Front 98

2. Prepare Conversion Plan

Back 98

System Analyst will develop a detailed conversion plan.
Plan will identify databases to be installed, end-user training and documentation that need to be developed, and a strategy for converting from the old system to the new system. (facilitated by Proj Mgr.)
Triggered by the completion of a successful system test.
Principal deliverable is the conversiuon plan that will identify databases to be installed, end-user training and documentation that need to be developed and a strategy for converting from the old system to the new system.

Front 99

3. Install Databases

Back 99

(System builders play primary role)
Special programs will have to be written to populate the new databases. Existing data from the production databases, coupled with the database schema models and database structures for the new databases, will be used to write computer programs to populate the new databases with restructured existing data.
Principal deliverable is the restructured existing data that has been populated in the databases for the new system.

Front 100

4. Train Users

Back 100

System users must be trained and provided with documentation(user manuals) that guide them through using the new system.
Group training is generally preferred - encourages group-learning possibilities
Principal deliverable is user training and documentation.

Front 101

5. Convert to New System

Back 101

Analyst completes this task by carefully carrying out the conversion plan. - Detailed installation strategies to follow for converting from the existing to the new production information system.
Also involves completing a system audit.

Front 102

Commonly Used Installation Strategies:

Back 102

1. Abrupt cut-over
2. Parallel conversion
3. Location Conversion
4. Staged conversion

Front 103

1. Abrupt cut-over

Back 103

the old system is terminated and the new system is placed into operation.
High Risk approach - may still be major problems that won't be uncovered until the system has been in operation for at least one business period.

Front 104

2. Parallel conversion

Back 104

both the old and the new systems are operated for some time period. Ensures that all major problems in the new system have been resolved before the old system is discarded.

Front 105

3. Location Conversion

Back 105

Same system will be used in numerous geographical locations, conversions are completed at one location first. As soon as that site has approved the system, it can be farmed to the other sites. (beta test site)

Front 106

4. Staged conversion

Back 106

Variation on the abrupt and parallel conversions. Staged conversion is based on the version concept introduced earlier. Each successive version of the new system is converted as it is developed.

Front 107

Systems Acceptance test

Back 107

Final system test performed by end users using real data over an extended time period.
An extensive test that addresses three levels of acceptance testing - verification testing, validation testing and audit testing.

Front 108

Verification testing

Back 108

runs the system in a simulated environment using simulated data. (Alpha Testing)
Primarily looking for errors and omissions re: end-user design specs

Front 109

Validation Testing

Back 109

Runs the system in a live environment using real data.
(Beta testing)

Front 110

Items tested in Validation Testing:

Back 110

a. Systems performance - throughput and response time for processing adequate to meet a normal processing workload.
b. Peak workload processing performance - handle the workload during peak processing periods
c. Human Engineering test - system as easy to learn and use as anticipated? adequate? Can enhancements be deferred until after the system has been placed into operation?
d. Methods and procedures test - during conversion, the methods and procedures for the new syustem will be put to their first real test. Methods and procedures may have to be modified if they prove to be awkward and inefficient from the end user's standpoint.
e3. Backup and recovery testing - all backup and recovery procedures should be tested.l - includes simulating a data loss disaster and testing the time required to recover from that disaster. also a before and after comparison.

Front 111

Audit testing

Back 111

Certifies that the system is free of errors and is ready to be placed into operation.

Front 112

Purpose of the implementation phase

Back 112

to smoothly convert from the old system to the new system

Front 113

Systems Support

Back 113

The ongoing technical support for users, as well as the maintenance required to fix any errors, omissions or new requirements that may arise.

Front 114

Systems Operation

Back 114

the day-to-day, week-to-week, month-to-month and year-to-year execution of an information system's businesses processes and application programs.
An operational system is frequently called a production system.

Front 115

Repository

Back 115

A data store of accumulated system knowledge - system modes, detailed specifications and any other documentation that has been accumulated during the system's development. The knowledge is reusable and critical to the production system's ongoing support

Front 116

Program Library

Back 116

A data store of all application programs. The source code for these programs must be maintained for the life of the system. Almost always, the software-based librarian will control access to the stored programs as well as track changes and maintain several previous versions of the programs in case a problem in a new version forces a temporary use of a prior version

Front 117

Business Data

Back 117

Includes all the actual business data created and maintained by the production application programs. Includes conventional files, relational databases, data warehouses and any object databases.

Front 118

Systems Support

Back 118

Cannot sensibly be decomposed into actual phases that a support project must perform. Consists of four ongoing activities:
1. Program Maintenance
2. System Recovery
3. Technical Support
4. System Enhancement

Front 119

1. Program Maintenance

Back 119

Fixing defects, or bugs - errors that slipped through the testing of software.

Front 120

2. System Recovery

Back 120

A system failure may result in a program "crash" and/or loss of data. Human error or a hardware or software failure may have caused this. Systems analyst or tech support may be called on to recover the system - restore the files and databases and to restart the system.

Front 121

3. Technical Support

Back 121

Users will eventually require additional assistance - unanticipated situations arise, new users are added

Front 122

4. System Enhancement

Back 122

New requirements may include new business problems, new business requirements, new technical problems, or new technology requirements.

Front 123

Causes of Bugs

Back 123

* Poorly validated requirements
* Poorly communicated requirements
* Misinterpreted requirements
* Incorrectly implemented requirements or designs.
* Simple misuse of the programs.

Front 124

Fundamental Objectives of System Maintenance

Back 124

* To make predictable changes to existing programs to correct errors that were made during systems design or implementation.
* To preserve those aspects of the programs that were correct and to avoid the possibility that "fixes" to programs cause other aspects of those programs to behave differently.
* to avoid, as much as possible, degradation of system performance
* To complete the task as quickly as possible without sacrificing quality and reliability. Few operational information systems can afford to be down for any extended period.

Front 125

Knowledge/Data

Back 125

System maintenance may improve input data editing or correct a structural problem in the database.

Front 126

Processes

Back 126

Most system maintenance is program maintenance.

Front 127

Communication

Back 127

System maintenance may involve correcting problems related to how the application interfaces with the users or another system.

Front 128

Validate the Problem

Back 128

First task!
Attempt to validate the problem by reproducing it.
Respect the possibility that the bug is real and that it will eventually be validated. - User should be coached to immediately document the exact sequence of events in detail or to call the analyst.

Front 129

Bug is Real

Back 129

1. The context of the bug should be examined by studying all relevant documentation (system knowledge) in the repository.(don't try to fix what you don't understand.)
2.All subsequent maintenance should be performed on a copy of the program. The original program remains in the program library and can be used in production systems until it is fixed.

Front 130

Benchmark the Program

Back 130

The programs should be executed and tested to establish a baseline against which the modified programs and applications can later be measured.

Front 131

Define Test Cases

Back 131

1. Past test data may exist in the repository as a form of system knowledge.It should be re-executed to establish or verify the benchmark.
2. Test data can be automatically captured using a software-testing tool (automatically stored - test script)

Front 132

Limitations slowing Program Understanding

Back 132

- Poor program structure
- Unstructured logic
- Prior maintenance
- Dead Code
- poor or inadequate documentation

Front 133

Essential/Recommended Testing

Back 133

Unit testing (essential) ensures that the stand-alone program fixes the bug without undesirable side effects to the program.
System Testing (essential) ensures that the entire application, of which the modified program was a part, still works.
Regression Testing (recommended) extrapolates the impact of the changes on program and application throughput and response time from the before-and-after results using the test data and current performance.
Failed candidates are returned for debugging.

Front 134

Version Control

Back 134

A process whereby a librarian (usually software-based) keeps track of changes made to programs. Allows recovery of prior versions of the programs if new versions cause unexpected problems.

Front 135

System Recovery Activities

Back 135

1. In many cases the analyst can sit at the user's terminal and recover the system.
2. the analyst must contact systems operations personnel to correct the problem.
3. May have to call data administration to recover lost of corrupted data files or databases.
4. the analyst may have to call network administration to fix a local, wide or internet working problem.
5, the analyst may have to call technicians or vendor service representatives to fix hardware problems.
6. In some cases the analyst will discover that a possible software bug caused the crash. the analyst attempts to quickly isolate the bug and trap it.

Front 136

Day-To-Day Assistance With:

Back 136

New business problems - or anticipated business problem
New business requirements
New technology requirements
New Design Requirements

Front 137

System Enhancements

Back 137

Reactive in nature.
Fix it when it breaks, or when users or managers request change. It extends the useful life of an existing system by adapting it to inevitable change.

Front 138

Software Metrics

Back 138

Mathematically proven measurements of software quality and productivity.

Front 139

Control Flow Knots

Back 139

The number of times logic paths cross one another. - A program should have ZERO control flow knots.

Front 140

Cycle complexity

Back 140

The number of unique paths through a program. The fewer the better!

Front 141

Three Distinct Types of Program Restructuring

Back 141

Code Reorganization
Code Conversion
Code Slicing

Front 142

Code Reorganization

Back 142

Restructures the modular organization and/or logic of the program. Logic may be restructured to eliminate control flow knots and reduce cycle complexity.

Front 143

Code Conversion

Back 143

Translates the code from one language to another. Typically this translation is from one language version to another.

Front 144

Code Slicing

Back 144

The most intriguing program-reengineering option. Many programs contain components that could be factored out as subprograms. If factored out, they would be easier to maintain. More importantly, they would be reusable.

Front 145

Adaptive Maintenance

Back 145

Maintenance in response to new business problems, new information requirements or new ideas for enhancements.