Acquiring software - PowerPoint PPT Presentation

1 / 25
About This Presentation
Title:

Acquiring software

Description:

A company or organisation has three basic ways of acquiring (getting) software ... When an organisation perceives a need for an IS ... – PowerPoint PPT presentation

Number of Views:84
Avg rating:3.0/5.0
Slides: 26
Provided by: sherr168
Category:

less

Transcript and Presenter's Notes

Title: Acquiring software


1
Acquiring software
  • A company or organisation has three basic ways of
    acquiring (getting) software
  • Buy it from some external source
  • Buy it and customise (modify) it
  • Develop it themselves (in-house or out)
  • Some of these three methods are more appropriate
    for different organisations and for different
    types of software

2
Systems Software
  • Systems Software includes software like
  • Operating Systems,
  • File Management Systems and Databases
  • Communications and Networking Software
  • These are usually
  • very complex systems
  • purchased from large software developers
  • Purchasing may include licensing arrangements

3
Information Systems and Applications
  • There are many generic IS applications for
    particular domains / industries
  • e.g. banking, insurance, airline reservations
    etc.
  • When an organisation perceives a need for an IS
  • e.g. starting a new company, migrating from a
    paper based system
  • or perceives a need for an improved IS
  • e.g. the current system is too slow, incompatible
  • the organisation may choose to buy a generic
    application or build a custom application

4
Buying Off The Shelf software
  • installed in a matter of weeks or months
  • possibly modified - further maintenance and
    development
  • tested several times, so it gives more
    refinements better de-bugging and documentation
  • a professional team of programmers, designers,
    technical writers
  • good documentation
  • known price of purchase or license
  • generally a better and more economical choice

5
Build (develop) your own software
  • The organisation may decide to develop their own
    custom-built IS because generic applications
  • are not available or
  • do not provide all of the required features
  • are not compatible with other existing systems
  • Cost saving is not usually a reason because
    building your own is hugely expensive
  • Building a custom IS can be done either
  • by external consultants or
  • in house, by your own IS/IT staff
  • end users

6
Knowing what you need
  • In either case, the company must know exactly
    what the IS is required to do
  • The company may carry out a feasibility study to
    determine if the proposed IS will provide
  • significant benefits
  • without unacceptable risks
  • at an acceptable cost
  • The feasibility study would indicate which
    approach - buy or build - is better

7
System Requirements
  • Whether the organisation decides to purchase or
    develop a system, the organisation now carries
    out a detailed analysis to find out
  • the functions that the IS must perform,
  • the speed at which it must perform,
  • the hardware it will run on and
  • the other systems with which it will be compatible

8
Functional and Non-functional Requirements
  • Individual IS have both functional and
    non-functional requirements
  • Non-functional requirements are NOT soft
  • A particular IS may need to be highly secure,
    very fast, highly reliable - these are not
    functions the IS performs, so they are
    non-functional requirements.
  • These requirements may affect the way searches
    are carried out, the way data is arranged in
    databases and so on. The way non-functional
    requirements are met are often highly technical

9
The interface and user centred IS
  • A special class of non-functional requirements
    may relate to the user interface
  • The interface may be required to be easy to
    learn, easy to use, provide adequate support for
    users.
  • These are NOT trivial nor universal requirements.
    They can have a significant impact on the way
    certain functions are implemented or on the
    overall cost and development time for the IS

10
Buying and the RFT
  • If the company decides to buy an IS they may send
    out a Request for Tenders (RFT or RFP)
  • An RFT provides software houses with all the
    requirements for the proposed IS
  • Software houses submit tenders which try to
    convince the buyer to choose their software
  • The buyer must evaluate these tenders impartially
    or there may be legal implications. If a suitable
    IS is found, the organisation signs contracts to
    buy.

11
Buying Commercial Off The Shelf software (COTS)
Initiation
Needs
Call for Tenders
Evaluation selection
Contract negotiation
12
Building and the SDLC
  • Building an IS is a huge job,
  • often involving dozens or hundreds of staff
  • lasting moths or years
  • costing hundreds of thousand or millions
  • Because of this, most organisations follow a
    pattern called the Software Development Lifecycle
    (SDLC) to try to streamline the process and
    ensure success.
  • There are a number of variations on the SDLC

13
Typical SDLC
  • Feasibility study - may already have been done
  • Plan - all the steps and
    gather resources
  • Analysis - find out exactly what is
    needed
  • Design - work out how to build it
  • Development - produce the computer code (4GLs)
  • Testing - make sure it works
  • Validation - make sure it does what is
    required
  • Implementation - get the IS into the
    organisation
  • Get ready to start again

14
SDLC and methodologies
  • SDLC is a framework - it tells us about broad
    steps and how to move from one to another
  • This may not be sufficient guidance for a large
    project, so some companies buy and use detailed
    sets of instructions, called methodologies
  • Methodologies are expensive and require both
    training and commitment e.g. SSADM

15
Feedback
  • Plan
  • Analysis
  • Design
  • Development
  • Testing
  • Implementation
  • Documentation

16
Step 1. Feasibility study
  • The goal of this phase is to determine the
    problem and is sometimes called the preliminary
    Investigation or system survey.

17
Tools of Feasibility study
Pres. C. Stenos
  • The systems analyst will develop an
    organizational chart to identify all relevant
    stakeholders.

VP A. Mapp
VP Z. Hewn
Purchase R. South
Marketing I. Simon
Sales O. Pine
Pay. J. Ria
IT. V. Gear
18
Defining the Problem involves
  • Nature of the problem
  • The systems analyst and the users/clients must
    agree on the nature of the problem.
  • Scope of the problem
  • Determining the scope of the problem sets
    limitations on how extensive the proposed system
    will be, the eventual budget and project
    schedules
  • Objectives of the project
  • Determining what the users/clients think the
    system should be able to do

19
Step 1b Authorisation Planning
Following the feasibility study, someone in
authority must authorise the project - the
project sponsor A project manager will be
appointed to oversee the planning, resourcing and
progress of the project
20
Planning
  • Project planning means identifying all the tasks
    (and sub-tasks) that need to be done. The amount
    of time for each of these tasks is estimated.
  • A Gantt chart is good for organising the tasks,
    their start/finish dates and the resources they
    need
  • Estimation of times is risky so PERT uses 3
    estimates to get the most accurate overall plan
  • Critical Path Method (CPM) identifies all the
    tasks which might delay the project so they can
    be watched more closely

21
Step 2 Systems Analysis
  • Systems analysis is the process of studying an
    existing system to determine how it works and how
    it meets client and user needs.
  • Clients contract to have the systems analysis
    done.
  • Users are people who will have contact with the
    system (employees and customers).

22
User Involvement
  • To overcome reluctance to change, involve the
    people in the client organization in the
    development process.

23
An analyst must be good at
  • coordinating schedules and system-related tasks
    with a number of people.
  • communicating -The analyst may need to make oral
    presentations and write reports for clients,
    users, and others involved with the system.
  • Other desirable qualities of a systems analyst
    are
  • an analytical mind
  • self-discipline
  • self-direction
  • The ability to work without tangible results

24
Flowcharts
  • A flowchart is a pictorial representation of a
    step-by-step solution to a problem.

25
Flowchart Basics
  • A flowchart consists of arrows to represent
    direction the program takes and boxes and symbols
    to represent actions.

26
Flowchart Symbols
Process
Start/Stop
Input/Output
27
Flowchart Symbols
Start Deposit
Show message
Get amount
No
Yes
Add balance amt
Show new balance
Write a Comment
User Comments (0)
About PowerShow.com