250 likes | 270 Views
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
E N D
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 System Development Life cycles
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
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
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
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
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
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
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
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
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
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
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
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
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
Programming and Implementation • Program design • diagrams • code • tests • documentation • data conversion • procedure development • user training - Program specifications - Code
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
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
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
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
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
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
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