Introduction to Information Systems Analysis Systems Construction - PowerPoint PPT Presentation

1 / 55
About This Presentation
Title:

Introduction to Information Systems Analysis Systems Construction

Description:

The network designer and administrator. are heavily involved in this phase ... the system - generally done in a top-down fashion (general to specific functions) ... – PowerPoint PPT presentation

Number of Views:78
Avg rating:3.0/5.0
Slides: 56
Provided by: gle9
Category:

less

Transcript and Presenter's Notes

Title: Introduction to Information Systems Analysis Systems Construction


1
Introduction to InformationSystems
AnalysisSystems Construction Implementation
Interpersonal Skills Communication
  • INFO 503
  • Glenn Booker

2
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 ?

3
FAST Model
  • The FAST model breaks Construction and
    Implementation into two phases
  • Construction Testing phase
  • Installation Delivery phase

4
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

5
Construction Phase
Information systems are built layer upon layer
6
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

7
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

8
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
    dont skimp on the hardware!
  • Long lead time needed for some installations,
    which may include installing air conditioning,
    running network cables,

9
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)

10
Build 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!

11
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

12
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 cant be checked by hand (or
    other methods)
  • Many use sampling to get typical legacy data

13
Build and Test Databases
  • Results in the empty (unpopulated) database
    structure
  • Need to update the database schema to reflect the
    actual structure used

14
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

15
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

16
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

17
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)

18
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

19
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?

20
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
21
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

22
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

23
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

24
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

25
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)

26
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

27
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

28
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!
29
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

30
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

31
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
    doesnt load easily
  • Make sure to test data conversion and loading
    programs before their final usage

32
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

33
Train 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

34
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

35
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

36
Convert 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

37
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!

38
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)

39
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

40
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

41
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)

42
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
43
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

44
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!

45
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

46
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

47
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

48
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

49
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

50
Preparing 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

51
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

52
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

53
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 subjects 1) approval,
    2) approval with minor corrections, or 3)
    rejection

54
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 reports purpose and results, so they should
    stand alone

55
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 Whites Elements of Style is the
    preferred guide for grammar and style
Write a Comment
User Comments (0)
About PowerShow.com