1 / 25

Developing Information Systems

Developing Information Systems. Chapter 11. Methodology - CASE. Methodology - way of working decided on within a company - method + techniques - follow-up by project leader CASE computer assisted software engineering - software package based on repository - upper-case + lower case

kwasham
Download Presentation

Developing Information Systems

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. Developing Information Systems Chapter 11

  2. Methodology - CASE • Methodology - way of working decided on within a company - method + techniques - follow-up by project leader • CASE computer assisted software engineering - software package based on repository - upper-case + lower case System Development Life cycles

  3. Waterfall model Project proposal report System proposal report design specifications program specifications code system performance tests audit , feed-back project definition system study design Waterfall model Spiral model Whirlpool model Rugby model programming Installation Post Imple- mentation - intermediate reports - go/nogo intervals

  4. Boehm’s Spiral Model progress through steps determine objectives, alternatives constraints evaluate alternatives identify , resolve risks Risk Analysis Risk Analysis Risk Analysis operational prototype prototype 2 prototype 1 simulation requirements plan life cycle plan models Benchmarks concept of operation Software design integration tests and plan Design validation and verification detailed design coding Plan next phases integration tests Prototype based implementation

  5. Whirlpool model Project proposal report Functional specifications Feasibility report design specifications program specifications code system performance tests audit , feed-back project definition system study design programming Installation Post Imple- mentation After each phase a quick review of the previous phases is made

  6. OO-life cycle • With the increasing complexity of the systems, • the waterfall model suffers from two illusions: • The analyst knows everything and understands the problem completely before implementation starts • The users read the system analysis report and approve it

  7. OMG-model (Object Management Group ) • Facts: • System requirements are not fully known at the start • knowledge of the system grows during development • better develop a system incrementally • start with some core functions analysis object modelling full system definition design construction coordination and reuse

  8. OMG Project Management • Iterative style • develop a series of solutions to a problem , • each of them closer to satisfying the requirements • ( also called : evolutionary development ) • Incremental style • Builds system functionality a little at a time. • The results are not entire solutions. • Matthew Pittman proposes iterative analysis and design combined with incremental development • Problem is managing the reuse (by design , not by accident) • How can such a project be estimated , tracked , controlled

  9. The waterfall model

  10. Waterfall model Project proposal report System proposal report design specifications program specifications code system performance tests audit , feed-back project definition system study design Waterfall model Spiral model Whirlpool model Rugby model programming Installation Post Imple- mentation - intermediate reports - go/nogo intervals

  11. Project definition What do we want to accomplish ? - solve a new problem - incorporate new requirements - improve existing system Is a new system the best solution ? Who will be involved ? Organizational problem

  12. System study : functional specs Objective: What is the problem ? Responsibility: The user Execution: Top-down technique 1. Activities: just a few sentences 2. Logical operations ( processes): for each activity 3. Details and definitions: rules, actions, controls , forms 4. Detail information: object, units, begin and end, classes, names

  13. System study : functional specs 2 The problem definition report includes: For the input: For the output: Furthermore: . form . point of time and frequency . origin . responsibility . type and layout . point of time and frequency . destination . usage . reasons for realization . financial advantages . constraints and borders of the system

  14. System study : The feasibility study Responsibility from this phase on in the ICT-department . study of the existing system . borders of the new system . links with other systems . study of different solutions . division in subsystems . applicability of packages . estimation of personnel requirements . cost-benefit analysis The report allows the steering committee to: - fix timings - final decision

  15. Design : general • What must be done to solve the problem? • data flow diagrams / use cases • inventory of the data elements • data dictionary • logical model of the system ( data analysis , UML) • major algorithms • compose the working groups • planning per department

  16. Design : Detailed - interfaces with other systems - controls and checking - privacy and security aspects - hardware specifications - job flow diagrams - Physical database design - high-level program design Detailed system and design specification

  17. Programming and Implementation • Program design • diagrams • code • tests • documentation • data conversion • procedure development • user training - Program specifications - Code

  18. Installation • Installation of the hardware • Install security procedures • Tests in operational environment • Training operations department • Take-over in user department and IT-department • Operational - User documentation - Operations documentation

  19. Post-implementation AUDIT - compare actual system with projected budget and timing - evaluate actual operation cost - evaluate user satisfaction - evaluate security MAINTENANCE - establish hardware maintenance procedures - test security plan - establish change management procedures

  20. Prototyping Alternative system analysis and building technique Advantages • better interaction with user and higher involvement • the technique invokes more requirements • additional system life cycle Disadvantages • expensive tools ( 4GL ) • user must well understand the aim of the prototype • more skills required from analysts and programmers • documentation often neglected

  21. Software packages . Where functions are common to many companies . Where in-house data processing resources are in short Advantages: > development bottleneck can be avoided > experience and knowledge are bought with the programs > vendors supply tools and assistance > mostly better documented Disadvantages: > company reorganization needed , other working methods >conversion and customization effort needed

  22. DFD - Example Books Publisher Client Valid orders Create publisher orders control orders Order publisher orders assembled orders Publisher publisher orders clients Pending orders delivery Consignment note payment Assemble Client orders Deliveries against pending orders individual orders titels quantities control deliveries invoice copy delivery Client invoicer control copy Payment against invoice Create invoice Create Publisher order control invoice AC payable AC receivable Publisher payments

  23. Use Case Diagrams Set Limits Example : Update Accounts Analyze Risk “uses” Accounting system Valuation “uses” Price Deal Trading Mgr Capture Deal Trader Actor “extends” Capture deal Limits Exceeded Salesperson Use Case

  24. Class Diagram:Typical example Multiplicity: many-valued Order Customer Multiplicity mandatory Class dateReceived Is prepaid number:string price: Money Name Address * 1 Dispatch( ) Close( ) CreditRating : string Association Generalization 1 Constraint (If Order.customer.creditRating is “poor” then Order.isPrepaid must be true) Corporate Customer Personal Customer Role Name Sales rep. Line items Employee contactName creditRating creditLimit CreditCard# 0..1 * * Order Line Multiplicity: optional Quantity:int Price:Money IsSatisfied Remind ( ) billForMonth {creditRating() ==“poor”} Product * 1

More Related