1.5 Systems Analysis

• Systems Analysis


  • Team of analysts is used instead of an individual because: Job should get done quicker, More minds = More ideas, More people have a more varied experience of businesses and systems
• Waterfall (1/2)


  1. The different stages are arranged in order, with each stage feeding into the next

  2. No stage of the development can be begun until the preceding one has been completed

  3. Each stage ends with a deliverable or handover document produced to inform the next stage
• Waterfall (2/2)


  • It is simple to understand and suitable for large projects where the requirements are clearly understood
  • It is very bad at reacting to changing requirements and is not suitable for projects where the requirements may not be fully understood at the start
• Waterfall - definition


  The Waterfall approach has different discrete stages arranged linearly, with each stage cascading down to the next. It is impossible to begin one stage of the development until the preceding stage has been completed.
• Agile


  • Agile techniques value collaboration and people over processes and tools
  • Teams are trusted to organise and manage themselves, with a focus on regular meetings and interactions rather than the documentation heavy approach in the Waterfall method
  • Agile programmers favour using their time to produce software rather than detailed, comprehensive documentation
  • The reluctance to produce lengthy documentation, combined with the high level of client contact allows Agile programmers to focus on responding to change rather than simply following a plan
  • Agile projects are able to quickly adapt to changes, for example, a competitor releasing a new product or a new operating system becoming available
  • The process is iterative. Lessons learned from one stage, e.g. implementation, are used in other stages, such as design, with the overall aim of customer satisfaction placed above adherence to strict requirements as set out in the analysis stage
• Agile - definition


  The Agile approach is an incremental approach to development, in which developers start off with a simple project design, instead of a huge document, and work on small modules at a time in an iterative way. This approach does not fully dismiss the Waterfall approach, but rather aims to improve the process of systems analysis.
• A feasibility study is essential to determine whether a project is technically and economically feasible.
• Feasibility study


  • It is very important that any proposed new system is: Cost Effective – the new system should generate more money than is spent on installing and operating it, Completed on time, Completed within a budget agreed with the management of the company.
• Feasibility Study – Activities & Outcomes

  1. Observing / using the current system in operation

  2. Consulting current documentation

  3. Carry out a questionnaire of staff / customers

  4. Interview staff / customers / employees

  5. A description of the problem / detailed system requirements / a requirements specification is produced

  6. Different possible methods of solution identified

  7. Storage requirements are considered

  8. Different types of HCI considered

  9. Hardware requirements will be considered

  10. Legal, social and environmental issues are considered

  11. Whether the project is technically feasible – does the technology / skills exist to complete the project

  12. Whether the project can be completed in the time scale - acceptable or projected time scale for the solution produced

  13. Whether the project can be completed on budget - the projected cost of the solution

  14. Involves a cost-benefit analysis to decide if a solution is affordable

  15. Training requirements for staff on the new system are considered
• Analysis


  1. Studying the existing system / consulting current documentation (in addition to the studying carried out in the Feasibility Study) by using: Questionnaires, Interviews, Observation, Study of Documents

  2. Exploring data requirements

  3. Consider types of Human-Computer Interface (HCI)

  4. Consider whether an 'off the shelf package' could be used or will a bespoke solution be required
• Design


  A detailed design of input, output, files and test plan: Design of Data Structures, Design and write algorithms, Design HCI, Produce Data Flow Diagrams, Recommend suitable hardware
• Implementation


  Installing and testing the overall system, Staff Training probably needed, Changeover of systems required (see later)
• Maintenance


  All systems need to be maintained – making sure the system continues to function correctly, modifications made, errors corrected, documentation kept up to date.
• Alpha Testing


  • Alpha testing is conducted in-house by developers and occurs before the customer agrees to accept the final program
  • Alpha builds are not shared with either the end user or with the customer
  • Alpha builds are not final piece of software and often include limited functionality and many bugs
• Beta Testing


  • Beta testing is conducted after alpha testing and later on in the software development life cycle
  • Beta builds are shared with a limited number of end users to beta test the system with live data
  • Beta builds contain all the main functionality but will still include some bugs
  • Bugs reported by the beta testers are corrected by the development team
• Acceptance Testing


  • Acceptance testing occurs in the final phase of testing during the software development life cycle
  • Acceptance testing is undertaken by the actual end users of the system with real data
  • The purpose of acceptance testing is to ensure the system has met the original requirements and specifications of the customer
• Direct Changeover ("Big Bang" Approach)


  • The old system is completely replaced by the new system in one go
  • This has the advantage of being very fast but could be disastrous if anything goes wrong
  • There is no backup!
  • Direct "big bang" - sudden change to new system
  • Could be used where a failure would not be catastrophic
  • Not used where a failure would cost lives or a lot of money
  • Cheap to implement as no extra staffing costs
  • If new system fails organisation have no system which could be costly or dangerous
• Parallel Changeover


  • The new and old systems are run together for a period of time. The old system is only removed when it is certain that the new system is functioning correctly
  • The advantage is safety of data, but it causes a lot of duplication of work and so increases costs
  • Parallel running - both systems running together for a time
  • Safest option as if new system fails they still have existing system
  • Expensive as require temporary staff or overtime for current staff to operate both systems
  • Could cause confusion for staff and customers having two systems
• Phased Changeover - part-by-part (by functionality)


  • Suitable for different departments
  • If new system fails the rest of the organisation can still function – not catastrophic
  • All staff can focus on one area to resolve any problems
  • Problems can be fixed quicker as more experts to resolve problem
  • Difficulties identified in one area can be resolved and managed in next area
  • Might cause problems in the changeover period when they need to communicate with each other.
• Pilot Changeover - part-by-part (by part of the organisation)


  • The new system is tried out in just one part of the whole company. If all goes well the new system can then be rolled out to the whole organisation
  • For this to work correctly the part changed must be completely isolated from the rest of the system
  • Suitable for different offices
  • If new system fails the rest of the organisation can still function – not catastrophic
  • All staff can focus on one area to resolve any problems
  • Problems can be fixed quicker as more experts to resolve problem
  • Difficulties identified in one area can be resolved and managed in next area
  • Might cause problems in the changeover period when they need to communicate with each other and have different systems
• Perfective Maintenance


  All systems can be improved. Programs may be improved to run faster or use less resources. There is nothing wrong with the way the system works - Perfective Maintenance just makes it better. Perfective Maintenance is when the performance/functionality of the program has to be enhanced.
• Adaptive Maintenance


  There may be changes to the specification of the system due to, for example, business expanding, or the need to run on a different OS. Adaptive Maintenance is updating a system to meet the new requirements from the end user. Adaptive maintenance is when the program has to be altered from it's original specification
• Corrective Maintenance


  Problems may arise which have been hidden for a while - sometimes this can take years. Corrective Maintenance is the process of fixing these 'bugs' in the system. Corrective Maintenance is fixing an error if discovered while the program is being used.
• Technical Manual


  • System Specifications, Description of Systems, Data Flow Diagrams (or similar), Algorithm Specifications, Algorithm flowcharts (or pseudocode), Annotated Program Listing, Lists of Variables Used (see data dictionary)
• Annotated listing


  The program with comments or description of code
• Data dictionary


  A file / table containing a description of the structure of the data (held in a database) / variables used in the system
• User Manual


  • Software Installation Procedures, Details for starting the program, Details for setting security, Details of Discs/Tapes required, Backup & Recovery procedures