1 / 64

Systems Development

Systems Development . Revision 2012. Revision Guide – Lecture 17. User perspectives – Their needs specify the inputs and outputs Data Protection Act The 3 roles, Data Subject, Data Controller and Information Commissioner 8 principles. Computer Misuse Act. User perspectives.

drucilla
Download Presentation

Systems Development

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. Systems Development Revision 2012

  2. Revision Guide – Lecture 17 • User perspectives – Their needs specify the inputs and outputs • Data Protection Act • The 3 roles, Data Subject, Data Controller and Information Commissioner • 8 principles. • Computer Misuse Act

  3. User perspectives • There are several kinds of user for most computer systems • Clerical users from business area • Managers from business area • Developers • Technical support team • Each type has a different perspective on the system • Clerical: tool to do the day-to-day job • Manager: tool to see trends and manage the business area • Developer: system to be developed and implemented • Technical support: system and users to be supported IMAT 1906 Lecture Week 17 (c) De Montfort University 2010-11

  4. Data Protection - eight principles • Data protection framed within 8 principles • Obtained and processed fairly and lawfully • Processed for specific purposes • Adequate, relevant and not excessive to processing purpose • Accurate and up to date • Not kept for longer than necessary • Processed in accordance with data subject rights • Secure • Not transferred outside EEA without assurance of protection • Look at each in turn… 4 IMAT 1906 Lecture Week 17 (c) De Montfort University 2010-11

  5. Revision Guide – Lecture 19 • Implementation overview • Business procedures slides 6-16 • User training – slides 18-22 – Think about what you covered in your presentations

  6. Installation - overview • Installing the system sounds simple • But there are several things to consider • Live environment as opposed to test environment • Distribution of software and database • Program-code independence • Communication networks • Data migration • Look at each briefly… 6 IMAT 1906 Lecture Week 19 (c) De Montfort University 2010-11

  7. Deployment strategies - overview • Three major options for putting the system into operation - also called deploying the system • Direct changeover • Parallel running • Pilot followed by roll-out • Look at each briefly… 7 IMAT 1906 Lecture Week 19 (c) De Montfort University 2010-11

  8. Direct changeover - what it is • Direct changeover is also called Big Bang • In this strategy, system is ‘turned on’ on day one • Old system is ‘turned off’ if there was one • All data has been migrated • All users start using new system at once • Usually scheduled during a business quiet time • Least expensive strategy but riskiest • What if system fails in some way? • Support team on hand • Developers and testers usually on hand as well 8 IMAT 1906 Lecture Week 19 (c) De Montfort University 2010-11

  9. Direct changeover - when to use • When to use • No existing system to replace • All users have been trained and ready • System has been completely tested and found acceptable • All system functionality needed at same time • Phased implementation not a viable business option 9 IMAT 1906 Lecture Week 19 (c) De Montfort University 2010-11

  10. Direct changeover - example • For example… • A small company is automating its order processing • All users in the order department have been trained • User guide and documentation are ready • System has been completely tested and is acceptable • Product data and customer data has been input • Implementation taking place over bank holiday weekend after all existing orders filled and sent out • Old paper-based orders filed in archive boxes • From day one, new orders are entered and processed on the new system • New reports required – to users who require them 10 IMAT 1906 Lecture Week 19 (c) De Montfort University 2010-11

  11. Revision Guide – Lecture 15 • Types of Systems inc Commercial, Internet and Real time • Components of a System – software, hardware, people, data,

  12. Components of systems • Systems contain many things • System components • Hardware – the machine(s) the system runs on • Software – the operating system and application systems • Data – the information used by the system • Processes – steps taken to transform input into output • People – the users supported by the system • Components work together to carry out the required functions • No single component can work on its own IMAT 1906 Lecture Week 15 (c) De Montfort University 2010-11

  13. Types of system • Common types of system: • Commercial systems • For business activities • Not just companies but other organisations as well • Real time systems • Results acted on immediately • Internet systems • Web-based business or communication channel IMAT 1906 Lecture Week 15 (c) De Montfort University 2010-11

  14. Internet systems • Tend to be commercial systems supporting organisations • Provide communication between suppliers and customers • Three main types: • Business to Consumer (B2C) • Business to Business (B2B) • Consumer to Consumer (C2C) • Think of the inputs and outputs required IMAT 1906 Lecture Week 15 (c) De Montfort University 2010-11

  15. Commercial systems • Support business activities • Transaction processing • Management information • Business support • Resource planning • User productivity • Think of the inputs and outputs required IMAT 1906 Lecture Week 15 (c) De Montfort University 2010-11

  16. Real time systems • Not all systems support commercial business activities • Commercial systems are time-critical • Must use up-to-date data • Must give prompt response • Some activities are time-critical in a different way • Must use up-to-date data • Must issue prompt and correct instructions • Results acted on immediately • Real time systems tend to control processes rather than information flow • Examples: manufacturing control, traffic control • Think of the inputs and outputs required IMAT 1906 Lecture Week 15 (c) De Montfort University 2010-11

  17. Manufacturing control systems • Systems that control arrival of parts and raw materials in a just-in-time fashion • Parts arrive just as the assembly line requires them • No need to store large quantities of parts not yet needed • Systems that control assembly activities • Moving the products being assembled along from one part of the assembly process to the next • Controlling the machines that do the assembly eg robots, drills • Input data taken from monitoring state of progress • Output data is instructions to machines or other systems • Interface largely automated ie no screens or keyboards IMAT 1906 Lecture Week 15 (c) De Montfort University 2010-11

  18. Summary • There are many types of computer system • Commercial – transaction processing, business support • Real time – process control • Internet – B2C, B2B, C2C • Systems have several components • Hardware • Software • Data • Processes • People IMAT 1906 Lecture Week 15 (c) De Montfort University 2010-11

  19. Revision Guide – Lecture 16 • Methodologies – inc traditional (SDLC, waterfall, SSADM), Agile (extreme, pair programming, joint), Rapid (iterative, joint, incremental) • SDLC stages– inc feasibility, implementation, design, evaluation. • Prototype – Throwaway and Evolutionary

  20. System development activities • Developing a system involves several kinds of activity • Feasibility study • Requirements definition • Analysis • Logical system design • Process design, specification, development (coding) • Data model, database design, implementation • Interface design, confirm with users, screen building • Testing and deployment • How many of these activities have you seen or done? IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  21. Methodologies - overview • Common methodologies include…. • Traditional life cycle methodologies • Rapid development methodologies • Agile methodologies • Prototyping • Look at each in turn…. 21 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  22. Traditional life cycle methodologies • Also known by other names • System Development Life Cycle (SDLC) • Waterfall development • V model - links testing to development stages • Each stage is completed and signed off before next one starts • Teams of experts only needed during ‘their’ stage • For example, programmers only needed during build phase • Working system is final deliverable, no interim system available • Easy to plan but not very flexible 22 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  23. Waterfall diagram feasibility inception requirements design build testing implementation 23 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  24. Traditional life cycle - stages • Typical pattern of activity • Feasibility study • Project inception • Requirements analysis and definition • System design - logical design • Construction - coding, unit testing • System testing including user testing and end-to-end testing • Implementation • Some variation but not much 24 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  25. Traditional life cycle - feasibility stage • As we have seen, feasibility studies the overall concept of a proposed system • Develops an overview-level understanding of requirements • Examines proposed system in several contexts: • Operational alongside other existing systems • Business within existing business processes • Financial in terms of costs of system balanced by benefits • Technical performance predictions and constraints • Deliverable is feasibility report • Milestone is decision to go ahead with project 25 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  26. Traditional life cycle - inception stage • Means starting the development project going • Includes for example • Identifying the project team • Identifying and estimating development activities • Making the project plan • Setting out risks and issues • typically these are things that are not yet well-understood or decided but might have a big impact on the project • For example new untried technology • Setting out project budget • Agreeing how progress will be monitored • Deliverable is set of project plans, risk and issue logs 26 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  27. Traditional life cycle - requirement stage • As we have seen, requirements stage finds out the detailed requirements • Fact-finding techniques • Analysis of findings • Documented in summary level and detailed level • Test strategy and test cases also defined • Deliverables • Requirements specification document • Test strategy and test plans • Milestone is requirements sign-off • User management agrees that requirements are complete 27 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  28. Traditional life cycle - design stage • Design stage covers the logical design of the new system • Processes • Interface - input and output • Data • Perhaps outline business procedures around the system • Deliverable: set of logical models • Milestone: design sign-off • User management agrees that designed system will meet their needs 28 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  29. Traditional life cycle - build stage • Construction stage also called build stage • Specification of processing details • Coding of processes into programs or routines • Implementation of database • Turns interface design into screens and reports • Includes unit testing of programs, screens, reports • Includes quality reviews of programs, screens, reports • Deliverable: components of physical system • Milestone: construction sign-off • Project management agrees that all components are built and fit for purpose • System testing can begin 29 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  30. Traditional life cycle - system test stage • Test strategy designed at end of requirements stage • System testing ensures that components link together • End-to-end testing ensures that input is correctly transformed into outputs and is delivered to right places • User acceptance testing ensures that realistic test cases are correctly processed and give required results • Tests processes, interface, reports, configuration • Deliverable: test logs at relevant levels • Milestone: testing sign-off • System performs as expected and required • Users accept developed system 30 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  31. Traditional life cycle - implementation • Several activities to implement system • Install system as appropriate • Populate relevant databases - migrate or input • User guide and other documentation • User training • Include new system functions in business procedures • Deliverable: working system now operational • Milestone: system development completed • System up and running • Users trained • System functions integrated into business processes 31 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  32. Agile methodologies • Also known by other names • Adaptive development • Extreme programming - pair programming • Joint development - joint with users • Principle is to be able to move very quickly and be very flexible 32 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  33. Agile development principles Iterative, incremental development as with rapid methods Constant feedback on how development progressing Team knowledge base maintained and shared Each phase incorporates what was learned in earlier phases Intense teamwork involved to achieve each phase 33 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  34. Agile development stages • Development team includes business people and system developers • System phases identified and prioritised by business users • Each phase is a self-contained iteration • Delivers a set of functions • Builds on previous iterations • Designed by users and developed by developers in tandem • Time-boxing often critical • Follows spiral model 34 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  35. Agile development diagram - spiral Ref: Boehm, B (1986) A Spiral Model of Software Development and Enhancement Can also be found in Shelly & Rosenblatt p 23 35 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  36. Rapid development methodologies • Also known by other names • Iterative development • Incremental development • Dynamic systems development • Development proceeds in phases according to priorities 36 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  37. Rapid development principles • It is possible to streamline system development • Some things can be done in parallel • Development and implementation can be done bit by bit • Must still maintain quality product • Must get and confirm user requirements • Must get design right • Must build and test each bit • Often time-boxed ie limited amount of time allowed 37 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  38. Rapid development stages • First stage is high level requirements definition • With user agreement, divide requirements into development phases • Business managers set priorities for delivering the phases • Often done in workshops to allow discussion and debate • Discussion can get heated; diplomacy needed • Agreement easier if project sponsor takes part • System development then becomes series of iterations 38 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  39. Rapid development - iteration tasks • Within each iteration, the usual development tasks are carried out • Design • Build • Test • Integration testing alongside previously-delivered phases • Implement • Next phase is next iteration 39 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  40. Rapid development diagram prioritised requirements each phase detailed requirements design build and test implement 40 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  41. Rapid development - example • When would rapid development be needed? • When there is a strong business need to have the system up and running quickly • For example, to support a new product being launched quickly to beat the competition • Cannot develop in time using traditional methods • Business priorities are marketing then production then sales • System functionality developed in that order • Marketing functions developed and implemented • Production and distribution functions • Sales and order processing functions 41 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  42. Prototyping methodologies • Two main types • Throw-away prototyping • Evolutionary prototyping • Principle is to develop cut-down versions of system but working system at all stages 42 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  43. Throw-away prototyping • Used to aid users in understanding their requirements • Similar to a film set • Screens may look real • Little or no processing behind screens • Can be developed very quickly • Can be amended very quickly to allow users to work out what they need • Useful when users unfamiliar with concept of new system 43 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  44. Throw-away prototyping diagram Analysis Design Build Test Implement 44 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  45. Evolutionary prototyping • Used to build up system incrementally • Initial prototype eventually becomes final system • Particularly useful when using CASE tools that generate working prototypes • As each iteration adds more functions, previous functions should be tested again • Tests that integration has been successful at each phase • System evolves through iterations • Changes in requirements can be accommodated • Can be combined with throw-away prototypes used for requirements gathering 45 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  46. Evolutionary prototyping diagram Analysis Design Build Test Release 1 Implement Release 2 Release 3 46 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  47. When are different methods suitable? • Methods suitable under different circumstances • Traditional • Requirements can be well-defined and stable • Rapid • Insufficient time for traditional approach • Requirements not fully known at outset • Agile • Business users available for development team • Partial system functionality acceptable and/or necessary • Prototyping • When robust CASE tools available 47 IMAT 1906 Lecture Week 16 (c) De Montfort University 2010-11

  48. Revision Guide – Lecture 7 • Fact finding techniques inc workshops/interviews/Questions/ • Information gathering – analysing documentation

  49. Factfinding for overall understanding • Factfinding is done at two major stages of system development • Overall understanding, for feasibility study • Detailed understanding, for requirements specification • For overall understanding, need to talk to people • Main techniques are • Interviews • Workshops IMAT 1906 Lecture Week 6 (c) De Montfort University 2010-11

  50. Factfinding for detailed understanding • Useful techniques • Interviews • Workshops • Questionnaires • Document analysis • Observation • Plus – analysing the results; question format has a bearing on analysing the results IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

More Related