systems development infsy 570 dr. ocker. what we mean by software quality software quality...

Download Systems Development Infsy 570 Dr. Ocker. What we Mean by Software Quality Software Quality Effective- ness UsabilityEfficiencyReliability Maintain- ability

Post on 17-Dec-2015

213 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • Slide 1
  • Systems Development Infsy 570 Dr. Ocker
  • Slide 2
  • What we Mean by Software Quality Software Quality Effective- ness UsabilityEfficiencyReliability Maintain- ability Understand ability ModifiabilityTestability
  • Slide 3
  • Techniques for Information Gathering in Systems Analysis Information Gathering Techniques Interviewing Questionnaires Group Decision- Making Processes Data Analysis Document Analysis Observation Participation Business Systems Planning Critical Success Factors Decision Analysis Throwaway Prototyping Evolutionary Development Deriving from the Analysis of the Business Area Asking the Users Deriving from an Existing System Experimenting with the System under Dev.
  • Slide 4
  • Systems Development Methods n Systems development - refers to all the activities that go into producing an information systems solution to an organizational problem or opportunity
  • Slide 5
  • Various methods for building information systems n I.traditional - systems development lifecycle n II.prototyping n III.application software packages n IV.outsourcing
  • Slide 6
  • I.systems development life cycle (SDLC) n oldest method for building systems n assumes that system has a life cycle with a beginning, middle, and end n structured type of problem solving with distinct stages, activities, and deliverables n each stage consists of activities which must be completed before next stage begins
  • Slide 7
  • Systems Development Life Cycle Feasibility Study Tasks Systems Analysis Systems Design Programming (Construction) Installation (System Operation and Maintenance) Requirements Analysis Logical Design Physical Design Coding and Testing Conversion Postimplemen- tation Review Recommendation to Proceed and System Proposal or Recommendation to Abandon Development Stages Deliverables Requirements Specifications Conceptual Design or Programs and Databases Detailed Design of System Modules and Databases Specification of System Hardware and Software Accepted System with Complete Documentation Installed Operational System Recom. for Enhancement of the System and of the Dev. Method Recom. for Org. Adjustment
  • Slide 8
  • Systems Analysis n Determine what the system will do (as opposed to how ) n 2 stages n 1.Feasibility study (preliminary investigation) n 2.Requirements Analysis
  • Slide 9
  • Feasibility Study n Objective is to establish whether the proposed system is feasible/desirable before resources are committed n systems analyst perform a preliminary investigation of the business problem/opportunity n takes about 5-10% of projects resources (time & money)
  • Slide 10
  • Feasibility Study Tasks n Define problem/opportunity n establish overall objectives of system n identify users of system n establish scope of system
  • Slide 11
  • Outcome of Feasibility Study n Recommendation to proceed or to abandon the project
  • Slide 12
  • Requirements Analysis n Objective is to produce the requirements specifications for the system n details about what the system will do
  • Slide 13
  • Requirements Analysis establishes n Outputs of system n inputs to system n processing steps needed to transform inputs into outputs n files and databases needed to store data
  • Slide 14
  • Requirements Analysis establishes n The volumes of data to be handled n numbers of users n file and database capacities
  • Slide 15
  • Information gathering techniques n 1.Ask users n 2.Derive from existing system n 3.Derive from analysis of business area n 4.Experimenting (i.e., prototype)
  • Slide 16
  • Systems Design n details how the system will meet the requirements as determined by the systems analysis n like a blueprint for a house - details all the specifications that give the system its form and structure
  • Slide 17
  • Systems Design n Must look at: Hardware & Software Program & Modules Specifications of the modules Design the Data base Design the USER interface Develop the system procedures
  • Slide 18
  • Systems Design n 2 types of design n logical n physical
  • Slide 19
  • Logical Design n A more macro level design n conceptual n activities include devising alternative solutions to problem and choosing an alternative user interface design logical/conceptual design of database
  • Slide 20
  • Physical Design n Objective is to produce a complete specification of all system modules and of interfaces between them to perform the physical design of the database
  • Slide 21
  • Physical Design n When the physical design is complete, the following aspects will be specified: system outputs (e.g., report layouts, screen designs) system inputs user interface platforms (HW, SW) program design detailed test plan database conversion plan
  • Slide 22
  • Programming n programming and documenting code
  • Slide 23
  • Testing n System pieces and later, the entire system, are run for purpose of finding errors
  • Slide 24
  • Conversion n Plan to move from old system to new system parallel - old and new systems run together direct - turn off old, turn on new phased - convert new system in increments by function pilot - introduce system to one organizational area before proceeding to the remainder of the org.
  • Slide 25
  • Post-implementation Review n evaluating system after it is in production (i.e. after installed and in use for awhile) n post-implementation audit Did we do what we said we would do?
  • Slide 26
  • Cyclical nature of SDLC n when an analyst finishes one phase and proceeds to the next, the discovery of a problem may force the analyst to go back to the previous phase
  • Slide 27
  • Limitations of SDLC n appropriate for building large transaction processing and management information systems where requirements are highly structured and well-defined n also used for complex technical systems (e.g. air traffic control) where formal and rigorous requirements are needed, along with tight controls
  • Slide 28
  • Drawbacks n 1.resource intensive - takes lots of time to gather detailed information and prepare volumes of specifications
  • Slide 29
  • Drawbacks n 2.approach is inflexible and inhibits change - to make changes/ correct errors - repeat appropriate life cycle activities, but must generate more documents - substantially increase development time and costs encouraged to freeze system specifications early in development process - so changes not encouraged
  • Slide 30
  • Drawbacks n 3.approach not suited for decision making applications n decision making tends to be unstructured; n requirements change/uncertain so difficult to specify requirements
  • Slide 31
  • II. Prototyping n building an experimental system rapidly and inexpensively for users to evaluate n working version of an IS or part of the system n preliminary model
  • Slide 32
  • Prototyping n iterative process of development n build preliminary design n try it out n refine it n try it out etc.
  • Slide 33
  • Prototyping n prototyping much more iterative than SDLC n promotes design changes n less formal approach than SDLC n quickly generate working model of system n no detailed specifications
  • Slide 34
  • Steps in prototyping n 1.identify users basic requirements n designer works with user only long enough to capture n basic needs n 2.develop working prototype n designer creates prototype quickly
  • Slide 35
  • Steps in prototyping n 3.use prototype n user works with prototype to determine how well it n meets his/her needs n user suggests improvements
  • Slide 36
  • Steps in prototyping n 4.revise and enhance prototype n designer refines prototype based on users input n repeat steps 3-4 until user satisfied
  • Slide 37
  • Prototyping n Approved prototype becomes basis for final specifications of the system n more rapid, iterative and informal than SDLC
  • Slide 38
  • Advantages of prototyping n useful when uncertainty about information requirements or design solutions n e.g. requirements for decision-oriented systems can be vague -- difficult to specify
  • Slide 39
  • Advantages of prototyping n good for design of user interface (part of system that end-users interact with) n encourages user involvement throughout systems development
  • Slide 40
  • Disadvantages of Prototyping n should not substitute for careful requirements analysis n better suited for smaller applications
  • Slide 41
  • III.Application software packages n develop a system by purchasing an application software package n application software package - set of prewritten, precoded application software programs that are commercially available n packages available for common functions such as payroll, accounts receivable, inventory control, etc.
  • Slide 42
  • Choose packages when n 1.functions common to many companies n 2.information systems resources for in- house development in short supply n 3.developing desktop ap