SYSTEM LIFE CYCLE

• System


  A dependent collection, or group, of functional elements, items or processes that interact together to form a complex unit or structure
• Information system


  A system that is able to gather (or collect) information, and process, store and distribute the information
• Computer system


  The collection of hardware that forms a desktop computer or a laptop, or the software that runs on a computer, or a combination of both hardware and software
• Stages in the system life cycle

  • Planning
  • Analysis
  • Design
  • Development and testing
  • Implementation
  • Evaluation
  • Maintenance
• System documentation is produced during each stage to record and support the creation of the new system
• The results and findings of the maintenance of the new system are used to add to the knowledge and understanding of the planning stage so that designs and development of other new systems can be improved or amended
• Feasibility study


  A study carried out to assess whether the system can actually be created
• A feasibility study analyses the technical ability of the company or business that intends to develop the new system, checks the legality, and checks whether the company can afford it and will make a profit
• Only when management is satisfied that the feasibility study has completely evaluated the potential for a successful development will the development of a new system be allowed to proceed and be fully planned
• Analysis


  1. Gathering information by carrying out fact-finding investigations
• Systems analyst


  • Responsible for gathering facts and information about the existing system and its problems
  • Collecting the views and opinions of the users
  • Defining and understanding the requirements of the users
  • Suggesting alternative solutions to problems and choosing the best solution
  • Calculating the benefits and the costs of the solution
  • Producing the specifications
• Skills of a systems analyst


  • Interpersonal skills
  • Analytical and technical skills
  • Good management skills
• Methods of research


  1. Questionnaires

  2. Interviews

  3. Observation

  4. Document analysis
• Questionnaires


  Enable the gathering of information from many people in a shorter time than interviewing
• Advantages of questionnaires

  • Less expensive than other methods
  • Results can be collected and entered quickly
  • Can be targeted at specific groups
  • Lack of facial expression or body language to interpret.
• Disadvantages of questionnaires


  • No follow-up research on individual responses if anonymous
  • Responses may be dishonest or biased
  • Incomplete data if not fully completed or returned
  • Lack of ability to customise or clarify questions
  • Difficult for people with disabilities to complete
• Interviews


  Can collect qualitative information, deal with complex topics, and allow follow-up questions
• Advantages of interviews

  • Can collect information from people who can't communicate effectively in writing
  • Can minimise misunderstandings through follow-up questions
• Disadvantages of interviews


  • Time-consuming for both interviewer and interviewee
  • Potential for bias and untruthful information
  • Quality of data depends on interviewer skills
  • Transcription of information into computer format is required
• Observation


  Watching the workings and requirements of the current system
• Advantages of observation


  • Can reveal problems not obvious from documents
  • Observer can see first-hand how tasks are carried out
  • Observer can make accurate measurements of task times
• Disadvantages of observation


  • Employees may not perform tasks normally when being watched
  • Observation takes up a lot of the observer's time
  • Remote video observation requires many hours of watching recordings
• Document analysis


  Discovering how data moves through a system
• When being watched, the employees may not carry out the tasks in the way that they normally do but may stick rigidly to the set procedures. This makes the observations unreliable as a record of the employees at work.
• Observations take up much of the observer's time, and the observer may even hinder the employees by being in the way or asking questions.
• The use of indirect observation, with remote video cameras, may involve many hours, or days, of watching multiple recordings of tasks and processes and can take a great deal of time to do.
• Document analysis


  Used by systems analysts to discover how data moves through a system
• In a DBMS, data is entered, processed and output.
• For a whole organisation, there is documentary evidence of how data arrives and gets into the organisation and how it leaves, for example letters, money and resources come in, and reports, profits and products leave.
• It is not usually possible to gather all the details of this type of information by questionnaires or interviews, but document analysis shows how data is collected, entered, processed and reported as it passes through.
• Documents studied by an analyst

  • Input screens and reports
  • Calendars
  • Purchase orders and receipts
  • Records or transactions
  • Queries on data to create reports
  • Spreadsheets
  • Employee work records
  • Project scopes and schedules
  • Error reports and maintenance reports
• For a specific system, for example a database management system, only those documents that relate to the operation of the DBMS will be analysed.
• Advantage of analysing documents

  It reveals the flow of data through a system
• Document analysis may not reveal small details about the data.
• A user requirements specification sets out the details of an agreement between the user and the development team about what the new system will do.
• The user requirements specification becomes part of the final contract between the client and the developers and is made available to other stakeholders.
• The user requirements specification is a definition of what will be produced and it is used at the testing stages to check whether the new system is doing what it is meant to do and what the client wants it to do.
• Contents of a user requirements specification


  • Overview of what the client wants
  • Specifying what the new system should do and how it should do it
  • Description of the current system and its problems
  • Defined purpose of the new system
  • How the users would be affected and how they would benefit from the new system
• The location of the new system would be specified if it were a large, whole new system for a company that had a number of offices.
• The details of what exactly the system has to do are stated (the functional objectives).