1 / 20

Hoofdstuk 11: Ontwikkeling van informatiesystemen

Hoofdstuk 11: Ontwikkeling van informatiesystemen. Overzicht. The Systems Development Lifecycle (SDLC) Preliminary investigation Systems Analysis Design Programming Testing Maintenance Legacy systems Prototyping. Methodologies and the SDLC.

Télécharger la présentation

Hoofdstuk 11: Ontwikkeling van informatiesystemen

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.


Presentation Transcript

  1. Hoofdstuk 11: Ontwikkeling van informatiesystemen

  2. Overzicht • The Systems Development Lifecycle (SDLC) • Preliminary investigation • Systems Analysis • Design • Programming • Testing • Maintenance • Legacy systems • Prototyping

  3. Methodologies and the SDLC • A methodology is a comprehensive set of steps, guidelines, activities and/or principles, prescribing the process by which the IS can be developed • Many methodologies distinguish a series of stages that the IS undergoes – the systems development life cycle (SDLC) • Various techniques may be prescribed during these stages

  4. SDLC: Waterfall Approach The classical SDLC is predominantly a ‘waterfall’ approach: • sequence of stages in which the output of each stage becomes the input for the next • facilitates project management: clear ‘milestones’ • but can be costly, time consuming and inflexible, especially for smaller projects • establishing user requirements can be very difficult

  5. Typical SDLC Stages • Preliminary investigation: establishing a high-level view of the intended project and its feasibility • Analysis: analysis of the information needs that the system should satisfy; describes what the system should do • Design: laying out how the system should be structured to meet the requirements determined by the systems analysis • Programming: writing executable code based on the design • Testing: process that determines whether the system produces desired results under known conditions • Deployment: putting the new system into operation • Maintenance: ongoing process of making further changes to it Note: many variations of divisions into (sub-)stages

  6. Preliminary Investigation • Usually includes conducting a feasibility study: determines whether the project is achievable, given the organisation’s resources and constraints • Technical feasibility: proposed solution can be implemented with available hardware, software, and technical resources? • Economic feasibility: benefits of proposed solution outweigh costs? • Operational feasibility: proposed solution is desirable within the existing managerial and organisational framework? (e.g., taking into account history of IT acceptance, IT skills of staff, organisational structure, …)

  7. System Analysis • Analyze the organisation’s processes, information needs and its existing systems • Data gathered from written documents, interviews, questionnaires, observation, measuring • Describe using various modelling techniques • Pinpoint problems/opportunities • Establish requirements that the new system must satisfy • Functional requirements: what tasks should the system perform? • Non-functional requirements: performance, security, …

  8. System Design • Further elaborate on the analysis; lay out the components of the IS and their relationship to each other • Some design choices include: • setting automation boundaries • centralized or distributed system • file-based or database system • batch or online system • … • Modular design: IS broken down into separate modules • more manageable: different teams of programmers/testers can be allocated to them in subsequent stages • often documented in structure charts & module specifications • User interface design

  9. Setting Automation Boundaries

  10. Programming • Process of writing actual program code for the system specifications prepared during the design stage • Procedural versus non-procedural programming languages • Most conventional programming languages are procedural: • Programmers must specify the sequence of processing steps to be performed in order to accomplish task • Three main constructs: • sequence: execute steps in order shown • iteration: repeat a series of steps while/until a condition is satisfied • selection: conditionally execute if a condition is satisfied • Example languages: C or C++, Java, Pascal, Basic, … • Non-procedural languages: • Specify not the exact sequence but what needs to be accomplished • Example: Structured Query Language (SQL)

  11. Example procedural programming languages • COBOL • Developed around 1960 • Has long been popular for business applications • Pascal • Intuitive for educational use • C, C++ • Powerful and efficient but lacks 100% portability across systems • Java • Designed to run on any system • Popular for web applications

  12. Testing • Static versus dynamic testing techniques • Static: not actually executing the program; e.g. code inspection • Dynamic: feeding test cases into the program and then seeing whether its execution meets certain requirements • Levels of testing • Unit testing: testing separate program modules • Integration testing: testing whether modules work together properly • System testing: testing the system as a whole • volume testing: can it handle the amount of data and transaction rate? • stress testing: does the system break down in extreme conditions? • Acceptance testing: done by the end-user (unlike the former three); provides final certification that the system is ready to be used in a production setting

  13. resources size Testing (contd.) • How to choose the test cases? • Exhaustive testing: try every combination (usually not an option…) Consider this simple scenario: • Suppose that the program needs values for n input items • Say every item has 2 possible values (e.g. yes or no) • Then, the number of test cases would have to be 2n • E.g., for n = 10, this equals 1024 • For n = 20, the number would already exceed1.000.000 • … “Exponential explosion”: • Test case selection strategies: • black box: select a suite of test cases without looking at the internal structure of the module (e.g. randomly generated) • white box: try to get a good test coverage by looking inside the module

  14. Deployment • Systems changeover: process of replacing the old system by the new system • Parallel running: conservative conversion approach where both the old system and the potential replacement are run together • Direct changeover: risky conversion approach whereby the new system replaces the old system on an appointed day • Pilot study: strategy to introduce the new system to a limited area of the organisation until it is proven to be fully functional • Phased approach: introduces new system replacement in stages; mixture of direct changeover and parallel running methods • Data entry/migration • Hardware/software installation • Training

  15. Systems Changeover Strategies Direct changeover: Parallel running:

  16. Systems Changeover Strategies (contd.) Pilot study:

  17. Systems Changeover Strategies (contd.) Phased approach:

  18. Maintenance • Three types of maintenance: • corrective: fixing bugs • perfective: enhancing the system without changing its functionality (e.g. optimizing its performance) • adaptive: changing the system’s functionality in order to meet evolving requirements • Preferably coupled to: • an ongoing formal review process • procedures for version control • systematic documentation of changes • Probably the most costly stage in the SDLC

  19. Maintenance Problems: Legacy Systems • Legacy systems: • old systems (e.g. 20-30 years old) • large, monolithic, and difficult (thus expensive) to modify • running on mainframes • written in (near-)obsolete languages “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.” (Dijkstra) • with very little or out-of-date documentation • whose original designers are retired or have left the organisation • still critical for the functioning of the organisation • often demanding high availability (e.g. customer account transaction processing in banks) • which continue to be used because the cost of replacing or redesigning (“re-engineering”) them is prohibitive

  20. Prototyping • Prototyping: building experimental system quickly for demonstration and evaluation purposes • Provides easier way for users to determine information requirements • Iterative instead of sequential process • Incremental or throwaway prototyping

More Related