Title: Introduction to Information Systems Analysis Systems Construction
1Introduction to InformationSystems
AnalysisSystems Construction Implementation
Interpersonal Skills Communication
2Systems 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 ?
3FAST Model
- The FAST model breaks Construction and
Implementation into two phases - Construction Testing phase
- Installation Delivery phase
4Construction 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
5Construction Phase
Information systems are built layer upon layer
6Build 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
7Build 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
8Build 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
dont skimp on the hardware! - Long lead time needed for some installations,
which may include installing air conditioning,
running network cables,
9Build 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)
10Build and Test Networks
- Dont 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 persons life easier!
11Build 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
12Build 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 cant be checked by hand (or
other methods) - Many use sampling to get typical legacy data
13Build and Test Databases
- Results in the empty (unpopulated) database
structure - Need to update the database schema to reflect the
actual structure used
14Install 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
15Install 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
16Write 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
17Write 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)
18Write 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
19Write 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?
20Write 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
21Implementation 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
22Conduct 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
23Conduct 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
24Prepare 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
25Prepare 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)
26Prepare 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
27Prepare 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
28Systems 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!
29Validation 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
30Install 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
31Install 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
doesnt load easily - Make sure to test data conversion and loading
programs before their final usage
32Train 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
33Train System Users
- Based on system documentation, develop training
manuals for users - Consider user expertise, knowledge, and needs
- May range from just a users manual to extensive
installation procedures, maintenance manuals, and
problem solving tomes - Consider options for written versus electronic
media (e.g. CBT) for training materials
34Train 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
35Convert 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
36Convert to New System
- Meet with all project personnel to ensure
everyones 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
37Convert 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!
38End 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)
39Interpersonal 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
40Listening
- 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
41Speaking
- 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)
42Choices 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
43E-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
44Body 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!
45Body 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
46Meetings
- 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
47Meetings
- 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
48Meetings
- 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
49Formal 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
50Preparing Formal Presentations
- Must start preparation with clear understanding
of the presentations 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
51Conducting 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
52Sustaining 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
53Peer 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 subjects 1) approval,
2) approval with minor corrections, or 3)
rejection
54Reports
- 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 reports purpose and results, so they should
stand alone
55Reports
- 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 Whites Elements of Style is the
preferred guide for grammar and style