1 / 37

Lecture 7

Lecture 7. 18/11/13. Systems analysis Analysis of problem that will be solved by system Defining the problem and identifying causes Specifying solutions Systems proposal report identifies and examines alternative solutions Identifying information requirements Includes feasibility study

ban
Télécharger la présentation

Lecture 7

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lecture 7 18/11/13

  2. Systems analysis • Analysis of problem that will be solved by system • Defining the problem and identifying causes • Specifying solutions • Systems proposal report identifies and examines alternative solutions • Identifying information requirements • Includes feasibility study • Is solution feasible from financial, technical, organizational standpoint • Is solution a good investment? • Is required technology, skill available?

  3. System analysis (cont.) • Establishing information requirements • Who needs what information, where, when, and how • Define objectives of new/modified system • Detail the functions new system must perform • Faulty requirements analysis is leading cause of systems failure and high systems development cost

  4. Systems design • Describe system specifications that will deliver functions identified during systems analysis • Should address all managerial, organizational, and technological components of system solution • Role of end users • User information requirements drive system building • Users must have sufficient control over design process to ensure that system reflects their business priorities and information needs • Insufficient user involvement in design effort is major cause of system failure

  5. Systems Analyst • Or business analyst is a systems analyst that specializes in business problem analysis and technology-independent requirements analysis. • A programmer/analyst (or analyst/programmer) includes the responsibilities of both the computer programmer and the systems analyst. • Other synonyms for systems analyst include: • Systems consultant • Systems architect • Systems engineer • Information engineer • Systems integrator

  6. Variations on the Systems Analysts Title • Other synonyms for systems analyst include: • Systems consultant • Systems architect • Systems engineer • Information engineer • Systems integrator

  7. Role of the Systems Analyst • Study problems and needs of an organization • Determine best approach to improving organization through use of: • People • Methods • Information technology • Help system users and managers define their requirements for new or enhanced systems

  8. Skills of a Successful Systems Analyst • Analytical • Understanding of organizations. • Problem solving skills • System thinking • Ability to see organizations and information systems as systems • Technical • Understanding of potential and limitations of technology.

  9. Skills of a Successful Systems Analyst • Managerial • Ability to manage projects, resources, risk and change • Interpersonal • Effective written and oral communication skills

  10. Requirements Discovery • Requirements discovery includes those techniques to be used by systems analysts to identify or extract system problems and solution requirements from the user community • Problem analysis is the activity of identifying the problem, understanding the problem (including causes and effects), and understanding any constraints that may limit the solution

  11. The Process of Requirements Discovery • Problem discovery and analysis • Requirements discovery • Documenting and analysing requirements • Requirements management

  12. Seven Fact-Finding Methods • Sampling of existing documentation, forms, and databases. • Research and site visits. • Observation of the work environment. • Questionnaires. • Interviews. • Prototyping. • Joint requirements planning (JRP)

  13. Requirements Gathering • It is estimated that 85 percent of the defects in developed software originate in the requirements • Once defects are embedded in the requirements, they tend to resist removal • They are especially difficult to find via testing. • It is crucial that training be required for requirements analysts and engineers that explains how to reduce the common types of requirements errors, including • incorrect assumptions • omitted requirements • inconsistent requirements • ambiguities

  14. System Owners System owners are the information system’s sponsors and chief advocates. They are usually responsible for funding the project to develop, operate, and maintain the information system.

  15. System Users System users are the people who use or are affected by the information system on a regular basis—capturing, validating, entering, responding to, storing, and exchanging data and information. A common synonym is client. Types include: • Internal users • Clerical and service workers • Technical and professional staff • Supervisors, middle managers, and executive managers • Remote and mobile users (internal but disconnected) • External users

  16. Stakeholders: Players in the Systems Game • A stakeholder is any person who has an interest in an existing or new information system. Stakeholders can be technical or nontechnical workers. • For information systems, the stakeholders can be classified as: • System owners • System users • Systems analysts • System designers • System builders • IT vendors and consultants

  17. Business Problem.. • You are a systems analyst for a consulting company and have been asked to assist the CEO of a bank • The bank recently implemented a plan to reduce the number of staff, including loan officers, as a strategy to manage profitability. • Subsequently the bank has experienced chronic problems with backlogged loan requests because the limited number of loan officers who are able to review, approve and disapprove loans. • The CEO is interested in solutions that would allow the approval process to move faster without increasing the number of loan officers and has engaged your company to come up with suggestions. • What systems would you recommend?

  18. Traditional systems lifecycle: • Oldest method for building information systems • Phased approach - divides development into formal stages • Maintains formal division of labor between end users and information systems specialists • Emphasizes formal specifications and paperwork • Still used for building large complex systems • Can be costly, time-consuming, and inflexible

  19. Systems Development Lifecycle(SDLC) • An approach to developing an information system or software product that is characterised by a linear sequence of steps that progress from start to finish without revisiting any previous step. • The SDLC model is one of the oldest systems development models and is still probably the most commonly used. • Traditional systems development lifecycle (Waterfall Model) • Very similar to a product life cycle in the consumer market because both a new product and information system develop through a number of stages.

  20. The typical SDLC has the following steps: • Initiation • Feasibility study • System Investigation • System Analysis • Systems Design • Implementation • Review and Maintenance • These stages are frequently referred to as “conventional systems analysis”, “traditional systems analysis”, “the systems development life-cycle” or the Waterfall Model

  21. SDLC or The Waterfall Model • The waterfall model describes a development method that is linear and sequential. • Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. • The advantage of waterfall development is that it allows for departmentalisation and managerial control.

  22. The Waterfall Model Continued.. • A schedule can be set with deadlines for each stage of development and a product can proceed through the development process and theoretically, be delivered on time. • Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance.

  23. Initiation Traditional SDLC Investigation Analysis Design Implementation NO FEEDBACK!!!! Maintenance

  24. SDLC • This is now regarded as the “hard” systems approach because of its rigid demarcation between phases. • It has shortfalls which lead to a number of difficulties • One major criticism of the model is that it doesn’t cater for revisiting previous phases to correct defects. • Feedback Loop– refinement of Waterfall Model

  25. Potential Strengths of the Traditional SDLC • It has been well tried and tested • Use of documentation standards • Following the methodology should aid (At least to some extent) that roll out dates, budgets and expected benefits are met. • At the end of each phase, all parties involved in the project can review progress. • Much greater control on the development of computer applications and make possible the use of project management tools and techniques

  26. Potential Weaknesses of the Traditional SDLC • Criticisms of the methodology or perhaps of the way it was used include: • Failure to meet the needs of management • Unambitious systems design • Instability • Inflexibility • User dissatisfaction • Problems with documentation • Lack of control

  27. To Do… Which of the following are not essential skills for a systems analyst? Communication skills Technical skills Testing skills Project management skills SAD stands for ____________ Systems and design Start and design Systems analysis and design Software analysis and design For any SAD methodology, the key phases are _________ and _________ Planning, implementation Analysis, design Implementation, support Planning, analysis

  28. Prototyping Building an experimental system rapidly and inexpensively for end users to evaluate It will be refined until it conforms to the users’ requirements This is achieved through iterative development

  29. The Prototyping Process Figure 13-8 The process of developing a prototype can be broken down into four steps. Because a prototype can be developed quickly and inexpensively, systems builders can go through several iterations, repeating steps 3 and 4, to refine and enhance the prototype before arriving at the final operational one.

  30. Advantages of Prototyping Disadvantages of Prototyping Better suited for smaller application development. Prototyping may mean glossing over essential steps in the system development. • Useful when there is uncertainty about system requirements or systems design • Valuable for End-user interface design • Encourages end-user involvement throughout the systems development lifecycle

  31. Application Software Packages • A set of prewritten, precoded application software programs that are commercially available for sale or lease • Packages have increased as many applications are common to many businesses: payroll, accounts and inventory control

  32. Advantages of Software Packages Disadvantages of Software Packages Disadvantages may be increased with a complex system Required customisation and additional programming may be expensive Hidden implementation costs • Most of the design work has been completed in advance • Little extensive testing required • Vendor support and maintenance

  33. End User Development • The development of information systems by end users with little or no formal assistance from technical specialist • It has been made possible by fourth generation software tools (4GL) • The variety of application development tools available make it easier for end user development • Guidelines for managers to encourage intranet website development by end users: • Look for what makes sense • Spur creativity • Set some limits • Give managers responsibility • Make users comfortable

  34. Advantages to End User Development Risks of End User Development It occurs outside the traditional mechanisms for information system management and control Problems in ensuring that end-user developed applications meet organisations objectives and standards Rapid systems development without a formal methodology may mean that testing and documentation is inadequate Loose control of organisational data • Improved requirements determination • Increased user involvement and satisfaction • Reduced application backlog

  35. Definition - Outsourcing • The practice of contracting computer centre operations, telecommunications networks, or application development to external vendors • Example: Bank of Ireland, Dell

  36. Outsourcing • Outsourcing has become increasingly popular as companies believe that it is more cost effective than maintaining their own IS staff • Many companies are outsourcing software procurement and support to application service providers (ASPs) who provide and support business application and other software via the Internet and intranets to all of a company’s employees workstations

  37. Benefits of Outsourcing Risks associated with Outsourcing May loose control over IS function Heavy reliance on the vendor Proprietary information may be leaked to the competition if sensitive data is available outside the organisation • To reduce work in the information systems department. • When the IS function within an organisation is limited. • To improve the contribution of IT to enhance business performance. • To create new sources of revenue.

More Related