INFO 503Lecture #91 Introduction to Information Systems Analysis Systems Construction &...

INFO 503 Lecture #9 1

Introduction to InformationSystems Analysis

Systems Construction & Implementation Interpersonal Skills & Communication

INFO 503

Glenn Booker


Systems Construction & Implementation

• Construction is the creation of the system– Often referred to as “development,” though that

could include the entire life cycle, or “coding”

• Implementation is delivery of the system into production (everyday use)

• These parts are the least discussed in this course; see programming and database development courses for a lot more detail


FAST Model

• The FAST model breaks Construction and Implementation into two phases:– Construction & Testing phase– Installation & Delivery phase


Construction Phase

• The Construction phase covers building and testing the actual system, and has four tasks:– Build and Test Networks (if needed)– Build and Test Databases– Install and Test New Software

Packages (if needed)– Write and Test New Programs


Construction Phase

Information systems are built layer upon layer

Network Infrastructure (hardware and operating systems)

Database (DBMS)

Commercial Software

Custom Software

Bui

ld in

this

ord

er


Build and Test Networks

• Skip this task if you are only using existing network structures

• Covers creating new networks and/or making modifications to existing networks

• Comes first in the phase since many later activities assume the network is in place, like the foundation of a building



• The network designer and administrator are heavily involved in this phase

• Based on the data and process models from the design activities, implement the necessary network structure and software – Includes servers and their connections to

each other, sometimes called the backbone of the system



• This may introduce expensive hardware components, which presumably are chosen using a cost-benefit analysis

• Most systems far exceed their original intent, so don’t skimp on the hardware!

• Long lead time needed for some installations, which may include installing air conditioning, running network cables, …



• Must agree on protocols (languages) spoken on the network, and determine what to do if a server leaves (drops off) the network

• Networks prove they exist by running an operating system on each server, and proving that they can communicate with each other (e.g. ‘ping’)



• Don’t forget the documentation!

• Record the physical layout of the network, and how everything is connected (‘as-built’)

• Make sure cables are clearly labeled

• After all, this will be updated some day, so please make that person’s life easier!


Build and Test Databases

• When the network foundation is secure, the databases can be built next

• These are the framework for the system, since detailed programming needs to work with the database structures

• Performed by database programmers and administrators



• Based on database design documents

• Should have sample data to work with– Should cover extreme and near-extreme cases,

and wrong cases, not just typical cases– Need enough data to have meaningful

calculations, but not so much it can’t be checked by hand (or other methods)

– Many use sampling to get typical legacy data



• Results in the empty (unpopulated) database structure

• Need to update the database schema to reflect the actual structure used


Install and Test New Software Packages

• Optional but likely – this task applies only if commercial or other off-the-shelf software is used in this system

• Performed by application programmers

• Inputs are the software to be installed and their documentation


Install and Test New Software Packages

• Follow integration requirements developed earlier (in what order do we install stuff?)

• Install software, and test it to make sure it is behaving properly

• Record relevant configuration information: software version and patch information, license codes, tech support phone numbers


Write and Test New Programs

• Now, guided by prototypes (if any), we can write and test the new programs needed to implement this system

• Done by applications programmers and testers; led by chief programmer or architect

• Inputs are the software design, programming plan, and test data from the design phases



• Other inputs may include software libraries (for reuse), and relevant programming standards (for quality control)

• Outputs are the new software and (possibly) reusable components, test results, review results, and software documentation

• At the end, software is installed on the real system (not that used for development)



• The programming plan should identify the sequence of development of each part of the system - generally done in a top-down fashion (general to specific functions)

• Changes to the design specifications and requirements should be carefully controlled

• Some form of source code control or revision control must be used



• Quality control during programming should include:– Checking code for conformity to language and

syntax standards, and naming conventions– Conducting peer review to ensure each module

passes before integrating it into the system– Review of test results before accepting

components; are workarounds for known problems clearly documented?



• Levels of testing during programming may include– Stub, then Unit testing of each module before

peer review– Integration testing of related modules to

demonstrate their higher level functions and interactions

– Finally, system-level testing to demonstrate meeting each system requirement

See INFO627, lecture 9 for more details on testing types


Implementation Phase

• The implementation and delivery phase consists of five not-very-sequential tasks:– Conduct System Test– Prepare Conversion Plan– Install Databases– Train System Users– Convert to New System


Conduct System Test

• Now that the system has been assembled, prove everything works together– Includes demonstrating working happily

with the existing system (if any)

• Inputs are the new system and its test data

• Outputs are test results, bugs found, and possibly software changes to fix the bugs


Conduct System Test

• This activity repeats until no bugs are found (rare!), or the quantity and/or severity of bugs found are acceptably low

• Record problems found, the solutions implemented, and what known problems are being accepted– Change control system manages fixing bugs


Prepare Conversion Plan

• Now we can plan converting to using the new system

• Project manager coordinates this task

• Goal is to develop a plan for transitioning from the old system (whether manual or not) to the new system

• Uses design specifications for the system



• Plan needs to identify– Existing databases to be installed– Conversion and loading of existing data– User training needs, & manager training needs– Schedule for the conversion effort– Strategy used for conversion (see next page)– Types of testing to be performed (see

later pages)



• Conversion strategies include:– Abrupt cutover; on one day, shut off old system

and start using new system (very risky)– Parallel conversion; use both old and new

systems in parallel (at the same time) for a while, then phase out use of the old system

– Location conversion; when many locations involved, a waterfall approach may be used to introduce each location in turn



– Staged conversion; introduce new system features in stages, and shut off the old system as its functions are replaced

• Testing needs to cover acceptance of the new system by all affected parties

• Systems Acceptance Test often includes three levels of testing: verification, validation, and audit testing


Systems Acceptance Test

• Verification testing tests against the specification to prove the system does what it should, possibly using simulated data

• Validation testing tests whether the system meets user needs w/ live data (next slide)

• Audit testing is an independent system test to prove that the system is bug-free enough to use operationally

These are not “alpha” and “beta” tests!


Validation Testing

• Validation testing may include:– System performance checks, like speed and

response time– Peak workload testing - stress test the system– Human engineering, check usability– Check out methods and procedures, to see if

they work as stated– Backup & recovery testing, to prove they work


Install Databases

• Now the databases are installed, with the real existing data (if any)

• Inputs are existing data and the new empty database structures

• Outputs are the filled database structures– And documented methods and programs

used to convert the data


Install Databases

• Programs may need to be written to convert or reformat the data into its new form (often called “data conversion and loading”)– May need to perform manual data entry for

legacy data not available electronically, or that which doesn’t load easily

– Make sure to test data conversion and loading programs before their final usage


Train System Users

• Learning a new system is often challenging, especially for end users

• Training could be done – One-on-one (mentoring)– In groups (instructor-led or synchronous)– Independently (self-paced or asynchronous)

• System analyst often involved here, in conjunction with users


Train System Users

• Based on system documentation, develop training manuals for users– Consider user expertise, knowledge, and needs– May range from just a user’s manual to

extensive installation procedures, maintenance manuals, and problem solving tomes

– Consider options for written versus electronic media (e.g. CBT) for training materials


Train System Users

• Make sure to write manuals at the right level of detail for your users’ understanding

• Consider legacy terminology familiar to users, and cross reference where possible

• After materials have been developed, try them on an initial group of users

• Refine materials if needed, then train the rest of the users


Convert to New System

• This is where the new system finds its home

• The project manager is in charge here

• The conversion plan is the guiding document

• Before this task can begin, system testing and training of initial users have been completed successfully



• Meet with all project personnel to ensure everyone’s role in the conversion and its timetable are clear

• Be sure contingency plans are prepared to handle foreseeable complications (risks)

• Install the new system, and migrate from the old system per the conversion plan



• Document and fix problems which occur along the way as needed– Severe problems may require cancellation of

the installation, or postponing it

• Test the system thoroughly after installation• Implement the new processes for using

the new system when ready to do so • When everything works okay, celebrate!


End of Implementation

• By the end of the Implementation phase, the new system has been delivered and installed, and its users are ready to use it for normal day-to-day operations

• This leads to the Systems Operation and Support phase (next week)


Interpersonal Skills

• Hiding technical people in air conditioned vaults is less common now, so interpersonal skills are increasingly valuable & necessary

• Focus on the intended audience of your communication, such as system designers, builders, end users, or owners (sponsors)

• Consider the responsibilities, attitude, information needs, & time span for each


Listening

• Demonstrate good listening skills by:– Starting with a positive attitude – Setting the audience at ease– Listen well in return– Echo their input to ensure you understand it– Avoid making assumptions about their input– Take notes where possible


Speaking

• Speaking in a business environment can take several forms– Expressive style, which is casual & sociable– Directive style, which is like a drill sergeant– Problem-solving style, which is focused

and logical– Meta style, which discusses the type of

communication (recursive)


Choices of Words

• The type of language chosen affects how a message is heard– Positive, beneficial terms are well received

(increased profit margin, customer satisfaction, sales, quality, market share, etc.)

– Negative or loss terms indicate motivation for change (errors, costs, risk, loss, waste, taxes, delays, etc.)

Consider whether you hear positive or negative terms in speeches…


E-mail

• E-mail messages should be concise and clear, using proper punctuation & grammar

• Keep e-mail communications professional

• Avoid overloading recipients with too many messages

• Be aware of security, company policies, privacy and confidentiality issues


Body Language

• In-person communication is: 7% verbal content

38% tone and inflection

55% physical

• Keep this limitation in mind for written communication (E-mail and reports), when you only have the 7% available!


Body Language

• Facial expression, eye contact, and posture are important physical aspects

• Physical proximity is important – Too close is often seen as invasive– Too far may be respectful or rude,

depending on context!

• Be aware of cultural differences in verbal and non-verbal communication


Meetings

• Meetings should be deliberate events• Preparation includes:

– Determine need and purpose of the meeting– Schedule the meeting, determine location

and participants– Prepare an agenda (outline of topics)

• Meeting conduct needs to balance staying focused vs. discussing related topics


Meetings

• Encourage digressions to be discussed off-line (outside of the meeting)

• Need to control overactive people and encourage quiet ones

• Pay attention to nonverbal cues

• Avoid criticism of new ideas– Allow brainstorming when appropriate


Meetings

• Write down what was discussed, decisions made, and what follow-up action items are needed - identify who should complete each and by when (establish a due date)

• After each meeting, distribute minutes from the meeting to everyone affected (which may include people not present), and save the minutes for future reference


Formal Presentations

• Formal presentations may be used to present status (project reviews), sell something, or address concerns

• Audience may not be receptive to the material, especially if it requires a change or expenditure by the audience


Preparing Formal Presentations

• Must start preparation with clear understanding of the presentation’s purpose

• Determine the amount of time available for the presentation, and the story to be told

• Select the visual aids which will be used

• Make copies of the presentation available to the audience


Conducting Formal Presentations

• To “sell” the presentation effectively– Dress professionally– Avoid first person (I) to share ownership– Maintain eye contact and confidence– Be aware of mannerisms

• Answer questions honestly, clearly and concisely


Sustaining Formal Presentations

• Keep audience involved using:– Intentional silence– Question and answer– A little humor– Props, such as writing or models– Changing voice volume– Doing something unexpected


Peer Reviews

• Peer reviews (walkthroughs) are once way to ensure system code and/or documentation are being created correctly and consistently

• Problems found should be recorded and tracked until resolved

• Review may result in the subject’s 1) approval, 2) approval with minor corrections, or 3) rejection


Reports

• Reports may be generated to convey the results of any system life cycle activity

• Reports should be sized to suit the attention span of their audience

• The primary elements of the report (introduction and conclusion) present the briefest summary of the report’s purpose and results, so they should stand alone


Reports

• Secondary elements provide the details of the report, and should be logically arranged

• Contents of a report should avoid excessive jargon, fancy words, and meaningless phrases

• Strunk and White’s Elements of Style is the preferred guide for grammar and style

http://btobsearch.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=35U4247BD8&sourceid=0039357320&btob=Y&isbn=020530902X&itm=1

http://btobsearch.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=35U4247BD8&sourceid=0039357320&btob=Y&isbn=020530902X&itm=1

INFO 503Lecture #91 Introduction to Information Systems Analysis Systems Construction &...

Documents

Transcript of INFO 503Lecture #91 Introduction to Information Systems Analysis Systems Construction &...