Introduction to Information Systems Analysis Systems Construction & Implementation Interpersonal Skills & Communication INFO 503 Glenn Booker INFO 503 Lecture #9
Download ReportTranscript Introduction to Information Systems Analysis Systems Construction & Implementation Interpersonal Skills & Communication INFO 503 Glenn Booker INFO 503 Lecture #9
Introduction to Information Systems Analysis Systems Construction & Implementation Interpersonal Skills & Communication
INFO 503 Glenn Booker INFO 503 Lecture #9 1
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 INFO 503 Lecture #9 2
FAST Model
• The FAST model breaks Construction and Implementation into two phases: – Construction & Testing phase – Installation & Delivery phase INFO 503 Lecture #9 3
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 INFO 503 Lecture #9 4
Construction Phase
Information systems are built layer upon layer Custom Software Commercial Software Database (DBMS) Network Infrastructure (hardware and operating systems) INFO 503 Lecture #9 5
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 INFO 503 Lecture #9 6
Build and Test Networks
• 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 INFO 503 Lecture #9 7
Build and Test Networks
• 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, … INFO 503 Lecture #9 8
Build and Test Networks
• 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’) INFO 503 Lecture #9 9
Build and Test Networks
• 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!
INFO 503 Lecture #9 10
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 INFO 503 Lecture #9 11
Build and Test Databases
• 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 INFO 503 Lecture #9 12
Build and Test Databases
• Results in the empty (unpopulated) database structure • Need to update the database schema to reflect the actual structure used INFO 503 Lecture #9 13
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 INFO 503 Lecture #9 14
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 INFO 503 Lecture #9 15
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 INFO 503 Lecture #9 16
Write and Test New Programs
• 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) INFO 503 Lecture #9 17
Write and Test New Programs
• 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 INFO 503 Lecture #9 18
Write and Test New Programs
• 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?
INFO 503 Lecture #9 19
Write and Test New Programs
• 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
INFO 503 Lecture #9 20
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 INFO 503 Lecture #9 21
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 INFO 503 Lecture #9 22
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 INFO 503 Lecture #9 23
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 INFO 503 Lecture #9 24
Prepare Conversion Plan
• 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) INFO 503 Lecture #9 25
Prepare Conversion Plan
• 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 INFO 503 Lecture #9 26
Prepare Conversion Plan
• –
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 INFO 503 Lecture #9 27
Systems Acceptance Test
•
Verification specification
testing tests against the 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!
INFO 503 Lecture #9 28
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 INFO 503 Lecture #9 29
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 INFO 503 Lecture #9 30
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 INFO 503 Lecture #9 31
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 INFO 503 Lecture #9 32
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 INFO 503 Lecture #9 33
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 INFO 503 Lecture #9 34
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 INFO 503 Lecture #9 35
Convert to New System
• 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 INFO 503 Lecture #9 36
Convert to New System
• 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!
INFO 503 Lecture #9 37
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) INFO 503 Lecture #9 38
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 INFO 503 Lecture #9 39
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 INFO 503 Lecture #9 40
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) INFO 503 Lecture #9 41
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…
INFO 503 Lecture #9 42
• 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 INFO 503 Lecture #9 43
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!
INFO 503 Lecture #9 44
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 INFO 503 Lecture #9 45
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 INFO 503 Lecture #9 46
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 INFO 503 Lecture #9 47
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 INFO 503 Lecture #9 48
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 INFO 503 Lecture #9 49
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 INFO 503 Lecture #9 50
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 INFO 503 Lecture #9 51
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 INFO 503 Lecture #9 52
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 INFO 503 Lecture #9 53
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 INFO 503 Lecture #9 54
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 INFO 503 Lecture #9 55