F28sd2 software design
This presentation is the property of its rightful owner.
Sponsored Links
1 / 41

F28SD2 Software Design PowerPoint PPT Presentation


  • 55 Views
  • Uploaded on
  • Presentation posted in: General

Information Systems Lifecycle Introduction to Feasibility Studies Monica Farrow EM G30 [email protected] Material available on Vision. F28SD2 Software Design. Timetable. Thu Mar 5 G44 Tue Mar 10 NS136 Thu Mar 12 – No lecture – work independently

Download Presentation

F28SD2 Software Design

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


F28sd2 software design

Information Systems Lifecycle

Introduction to Feasibility Studies

Monica Farrow

EM G30 [email protected]

Material available on Vision

F28SD2 Software Design


Timetable

F28SD Software Design

Timetable

Thu Mar 5 G44

Tue Mar 10 NS136

Thu Mar 12 – No lecture – work independently

Tue Mar 17 – guest visitor starting at 11:15 (?)

Lyle Barbour from SOPRA group

Maybe lasting up to 1hr 30 mins

Location to be arranged

Thu Mar 19 G44

Tue Mar 24 NS136 back with CS


Process models

Process models

  • There are various types of software lifecycle models

    • Waterfall, spiral, agile...


Waterfall process model

F28SD Software Design

Waterfall process model

Requirements capture

System and

software design

Implementation and unit testing

Integration and system testing

You’ll find slightly different

versions elsewhere.

Operation and maintenance


Boehm s spiral model

F28SD Software Design

Boehm’s spiral model


Scrum an agile process

SCRUM – an agile process

Other diagrams show 2-4 weeks

Rather than 30 days


Information systems lifecycle

F28SD Software Design

Information Systems lifecycle

  • Software lifecycle models

    • concentrate on design and implementation of a software system

    • models lack an overall picture of the organisation and its business processes

  • A traditional structured design method extended in this manner is shown next

    (Based on Avison and Shah)

  • The similarities are clear

  • So are the new features


F28sd2 software design

F28SD Software Design

Problems with

existing system

New business

opportunities

Information Systems lifecycleAfter Avison and Shah p71

IS

planning

Managerial

directive

Feasibility

study

Feasibility

study report

Systems

investigation

User

requirements

Project

plans

Resource

requirements

Staff

assignment

Methods

and tools

Current

system

data flow

System

requirements

Systems

analysis

Systems

design

New system

data flow

System

specification

Training and

test plans

Implementation

Programs

Procedures

Documentation

New system

in operation

Review

and

maintenance

Evaluation

report

New problem

statement?


What s similar

F28SD Software Design

What’s similar?

Stages rather like waterfall

Repeats with review like spiral

Progress in terms of artefacts


What s added

F28SD Software Design

What’s added?

Feasibility study

Review during maintenance

System is an open one

Operation feeds back to design


Review during maintenance

F28SD Software Design

Review during maintenance

Learning from experience

Effectiveness of the solution

Correctness of function

Efficiency

Suitability for the business process

Effectiveness of the process

Kept to time?

Kept to budget?

Lessons learned for future developments


System is an open one

F28SD Software Design

System is an open one

Take account of influences from the organisation which change over time

Managerial directives

often arbitrary

but often dominate decision making

New opportunities

business process change requires system change

Longer term information systems planning

system change to maintain business process


Operation feeds back to design

F28SD Software Design

Operation feeds back to design

Operation reveals errors - “maintenance” in SE

Operation reveals bottlenecks for the business

Operation reveals new opportunities for business

Operation reveals difficulties for users

Summary : from the original ‘build a system then hand it over’ approach, we must be now more aware of the user and their environment.


Feasibility study

F28SD Software Design

Feasibility study

  • Propose and evaluate alternatives

  • Establish priorities

  • Gather information

  • Perform cost-benefit analysis

  • Form options for computerisation

  • Present conclusions

    The negative option is a valid option!


Objectives of feasibility study

Objectives of feasibility study

  • A feasibility study should provide management with enough information to decide:

    • whether the project can be done

    • whether the final product will benefit its intended users

    • what are the alternatives among which a solution will be chosen (during subsequent phases)

    • is there a preferred alternative

  • After a feasibility study, management makes a go/no go decision

  • The feasibility study is a management-oriented activity


Inputs and outputs

Inputs and outputs

Organisation

Users

Management

Feasibility

study

report

Existing

Practice

Boundary

Constraints

Objectives

Responsibilities

New

Opportunities

Problems

Feasibility study

New

Requirements

Systems

analyst

Suppliers

Costs


Terms of reference

Terms of reference

  • Project objectives

  • System boundary

  • Responsibility

  • Constraints

  • Reporting mechanism


Terms of reference1

Terms of reference

  • Project objectives

    • Unambiguous statement of what the client expects

    • Must be agreed before further work is done

  • System boundary

    • The scope of the feasibility study

    • What should be considered

    • What should not be considered


Terms of reference continued

Terms of reference continued

  • Responsibility

    • Who will supervise the project?

    • Who can authorise changes during the study?

    • Is the scope fixed?

  • Constraints

    • Budget

    • Time scales

    • Resources

    • Etc

  • Reporting

    • How will the report be expected?

    • To whom will the report be presented?

    • Who else can see the report?


Tasks in conducting the study

Tasks in conducting the study

  • Study current situation

  • Analyse requirements

  • Consider alternatives

  • Analyse economic/financial situation


Current situation

Current situation

  • Study current situation

    • The present organizational system, including users, policies, functions, objectives,...

    • Problems with the present system (inconsistencies, inadequacies in functionality, performance,...,

    • Gain thorough understanding

    • Establish reality of problems

    • Look for opportunities

    • Establish cause and effect


Pieces framework

PIECES framework

  • The PIECES framework can help in identifying problems to be solved, and their urgency:

    • Performance -- Does current mode of operation provide adequate throughput and response time?

    • Information -- Does current mode provide end users and managers with timely, pertinent, accurate and usefully formatted information?

    • Economy -- Does current mode of operation provide cost-effective information services to the business? Could there be a reduction in costs and/or an increase in benefits?


Pieces framework1

PIECES framework

  • Control -- Does current mode of operation offer effective controls to protect against fraud and to guarantee accuracy and security of data and information?

  • Efficiency -- Does current mode of operation make maximum use of available resources, including people, time, flow of forms,...?

  • Services -- Does current mode of operation provide reliable service? Is it flexible and expandable?


Analyse requirements

Analyse requirements

  • Analyse requirements (What not how)

    • Objectives and other requirements for the new system

      • what needs to change?

      • What would the stakeholders like to achieve?

    • Constraints, including non-functional requirements on the system (preliminary pass)

    • What is the client’s intention?

    • What capabilities are needed?

    • Data input and stored

    • Information output


Tasks in conducting the study continued

Tasks in conducting the study continued

  • Consider alternative solutions

    • Possible alternatives (the current system is always one of those)

      • Different business processes for solving the problems

      • Different levels/types of computerization for the solutions

    • Advantages and disadvantages of the alternatives

  • Economic/financial analysis

    • Costs of alternatives

    • Opportunity costs of inaction

    • Benefits of changes

    • Impact on business as a whole


Four tests for feasibility

Four tests for feasibility

  • There are four categories of feasibility tests

    • Operational feasibility

      • How well will solution work in organisation? How do people feel about it?

    • Technical feasibility

      • Practical? Expertise?

    • Schedule feasibility

      • Reasonable timetable?

    • Economic feasibility

      • Cost-effective?


Operational feasibility acceptability

Operational Feasibility: Acceptability

  • How do end-users and managers feel about the problem (solution)?

  • It's not only important to evaluate whether a system can work but also evaluate whether a system will work.

  • A workable solution might fail because of end-user or management resistance.

    • Does management support the project?

    • How do the end-users feel about their role in the new system?

    • What end-users or managers may resist or not use the system? People tend to resist change. Can this problem be overcome? If so, how?

    • How will the working environment of the end-users change?


Operational feasibility acceptability1

Operational Feasibility: Acceptability

  • Can or will end-users and management adapt to the change?

    • Internal issues, such as manpower problems, labour objections, manager resistance, organizational conflicts and policies;

    • also external issues, including social acceptability, legal aspects and government regulations.

  • The PIECES framework can also be used for each alternative solution

    • Performance, Information, Economy, Control, Efficiency, Services


  • Technical feasibility

    Technical feasibility

    • Is the proposed technology or solution practical?

      • Do we currently possess the necessary technology?

      • Do we possess the necessary technical expertise, and

        • Is the schedule reasonable for the team?

      • Is relevant technology mature enough to be easily applied to our problem?

      • Is it compatible with our other systems?


    Technical feasibility1

    Technical feasibility

    • Some firms like to use state-of-the-art technology, but most firms prefer to use mature and proven technology.

      • A mature technology has a larger customer base for obtaining advice concerning problems and improvements.

    • Assuming that required technology is practical, is it available ‘in-house’?

      • If so, does it have the capacity to handle the solution.

      • If not, can it be acquired?

      • Is it available within given resource constraints (i.e., budget, schedule,...)?


    Schedule feasibility

    Schedule feasibility

    • Do we have the skills required to properly apply that technology;

      • True, all information systems professionals can learn new technologies;

      • However, that learning curve will impact the technical feasibility of the project;

      • Specifically, it will impact the schedule.

    • Given our technical expertise, are the project deadlines reasonable?

      • Some projects are initiated with specific deadlines;

      • You need to determine whether the deadlines are mandatory or desirable. What are the consequences of delay?

      • If the deadlines are desirable rather than mandatory, the analyst can propose alternative schedules.

      • Missed schedules are bad, but inadequate systems are worse!


    Economic feasibility

    Economic feasibility

    • The bottom line in many projects is economic feasibility.

    • During the early phases of the project, economic feasibility analysis amounts to little more than judging whether the possible benefits of solving the problem are worthwhile.

    • As soon as specific requirements and solutions have been identified, the analyst can weigh the costs and benefits of each alternative.

    • This is called a cost-benefit analysis.


    Cost benefit analysis

    Cost/benefit analysis

    • The purpose of a cost/benefit analysis is to answer questions such as:

      • Is the project justified (because benefits outweigh costs)?

      • Can the project be done, within given cost constraints?

      • What is the minimal cost to attain a certain system?

      • What is the preferred alternative, among candidate solutions?


    Cost benefit analysis1

    Cost/benefit analysis

    • Examples of things to consider:

      • Hardware/software selection

      • How to convince management to develop the new system

      • Selection among alternative financing arrangements (rent/lease/purchase)

    • Difficulties

      • Discovering and assessing benefits and costs. They can both be intangible, hidden and/or hard to estimate,

      • It's also hard to rank multi-criteria alternatives


    Types of benefit

    Types of benefit

    • Examples of particular benefits:

      • cost reductions,

      • error reductions,

      • increased throughput,

      • increased flexibility of operation,

      • Improved operation,

      • better (e.g., more accurate) and more timely information


    Types of benefit1

    Types of benefit

    • Benefits may be classified into one of the following categories:

      • Monetary -- when $-values can be calculated

      • Tangible (Quantified) -- when benefits can be quantified, but $-values can't be calculated

      • Intangible -- when neither of the above applies

    • How to identify benefits?

      • By organizational level (operational,lower/middle/higher management)

      • or by department (production,purchasing, sales,...)


    Types of cost

    Types of cost

    • Project-related costs

      • Development and purchasing costs:

        • who builds the system(internally or contracted out)?

        • software used (buy or build)?

        • hardware (what to buy, buy/lease)?

        • facilities (site, communications, power,...)

      • Installation and conversion cost

        • installing the system,

        • training of personnel,

        • file conversion,....


    Types of cost1

    Types of cost

    • Operational costs (on-going)

      • Maintenance

        • hardware (maintenance, lease, materials,...),

        • software (maintenance fees and contracts), facilities

      • Personnel: operation, maintenance


    Types of cost2

    Types of cost

    • For a small business that wants to introduce a PC-based information system, these cost categories translate to the following:

      • Project costs

        • purchasing (hardware, software, office furniture),

        • customizing software, training,

        • system installation

        • and file conversion

      • On-going costs:

        • operating the system (data entry, backups, helping users, vendors etc.),

        • maintenance (software) and user support,

        • hardware and software maintenance,

        • supplies


    Costing example

    Costing example?


    F28sd2 software design

    Next

    • More on costs next time

    • Most of these notes come from Ch9 of Systems Analysis and Design Methods b Whitten, Bentley and Dittman

    • You can read this chapter in full electronically, on Vision


  • Login