System Life cycle Flashcards
System Life cycle
System Analysts will review an existing system which is currently not meeting expectations of the client. An a new system which is fit for the purpose will be developed
Stages in system life cycle
1-Analysis: Collecting information about the present system and identifying problems.
2-Design: Designing a new system to correct the problems identified in the analysis.
3-Development & Testing: Developing and testing new system.
4-Implementation: Replacing the old system with the new system.
5-Documentation: Creating technical and user documentation for new system.
6-Evaluation: Evaluating whether the new system meets the requirements of the design requirements
Analysis
Finding out how the current system works and what the requirements of the client are for the new system
Methods of research (Analysis):
-Questionaries
-Interviews
-Observations
-Document Analysis
Questionaries:
-Used when information is required from a large number of users when it would be impractical to interview them all.
-A mixture of multiple-choice questions, opinion ratings and open-ended questions should be used. This will provide a balance of quantitative analysis of closed-ended questions and a qualitative analysis of open-ended questions where users are able to suggest alternative ideas to those presented by the questionnaire.
-If Questionaries are completed online, results are immediately stored and readily available for detailed analysis in the form of graphs and tables
Advantages and Disadvantages of Questionnaires:
Advantages
-Large audience can be reached
-Questions can be answered quickly such as multiple choice
Disadvantages
-Questions may not be completely accurate
-May not all be returned, if questionnaire takes too long to complete
Interviews
-Interviews involve a direct conversation between the analyst and the client.
-When there is a single end user or small group of end users then interviews are the perfect solution, because questions can be asked of the users and a conversation can take place which can expand upon answers that are given with follow-up questions searching for further detail.
Advantages & Disadvantages of Interviews:
Advantages
-It allows to probe more into the problem
-It allows the analyst to get honest opinions of the employees
Disadvantages
-It can be time consuming
-The analyst cannot remain anonymous with this method
Observation
-Observation involves the analyst watching the processes that take place within an organization to find out how everyday tasks are completed.
-This can involve sitting with users to understand the tasks they have to complete, with an opportunity to ask questions, to elicit further information that could be needed for a requirement specification
Advantages & Disadvantages of Observations
Advantages:
-It obtains reliable data
-It is an inexpensive method
Disadvantages
-People are generally uncomfortable being watched
-People may perform differently when being watched.
Document analysis
-Existing documents within an organization can tell an analyst a lot about the information that is currently being used.
-The analyst will need to see examples of any documents that show output information or give an indication of what data is being collected for input to a system
Advantages & Disadvantages of document analysis
Advantages
-Analyst can view how the current paperwork operates
-This method can give critical information of the system
Disadvantages
-Time consuming method
-Can be a costly method
Types of Specifications
-Requirement specifications
-System specifications
-Design Specification
Requirement specifications
-A requirements specification is a contract between the developer and the client. Created by the analyst.
-It will specify exactly what the client needs the system to do thus developer can produce a system that meets the client’s needs.
What should requirements specification include
1.The purpose of the system.
2.The main objectives of the system.
3.Data that must be output from the system (for example, invoices, sales reports).
4.Data that needs to be input to the system to generate the outputs, including any screens or data collection forms.
5.Validation and verification that is needed for input data.
6.Processes that need to take place to convert inputs into outputs or to store data.
7.Data that need to be stored.
8.Functional requirements such as performance measures.
9.Deadlines for each milestone within the project.
System specifications
The hardware and software needed to run the system
-The software needs to be identified first as the hardware will depend upon what software is needed.
-There may be different software identified for different types of users and for servers. Thus software required to run the system must be specified
-Once the software is known, the minimum hardware required to run that software can be identified. The analyst needs to consider how much storage space is going to be required for the data being used by the system, May also recommend higher than minimum specifications so that the system functions at a reasonable speed.
Design Specification
Illustration of how the system will look, what the data structures will be and how the system will work
- It is intended to give the user an idea of what the system will look like before it is developed so that the user’s feedback can be incorporated into the final designs.
The developer will then follow the designs (Design specifications).
-flowcharts
-data flow diagrams
-data collection forms
-screen layouts
-validation routines
-data dictionary.
In addition to this, a design specification will include: * house style (logos, colors, fonts, styles, sizes) * screen sizes * connectivity diagram to show links between screens * purpose of calculations.
Design
-Design: The stage in the life cycle when the design specification is produced
-During the design stage, the overall structure of the system and details of the system components are designed without being developed.
Data flow diagram (DFD)
Shows how data flows throughout a system. It is not about the order of processes, purely about data flow.
Level 0 DFD
Should identify the external entities and the data flows between the external entities and the system.
Level 1 DFD
-First identify any external entities and any other parts of the system that will be classed as external entities.
-Identify the data flows to and from those external entities. Each data flow must have a process attached to it.
-A data flow cannot move directly from one external entity to another or from one data. store to another.
System Flowchart:
An overview of how the system works in a diagrammatic format
-A system flowchart shows the flow of data and processes within a complete system.
-A system flowchart will show how various elements of an information system are related.
Data Store
-Data Dictionaries
-Files
Data Dictionaries
-Created to describe how data will be stored in tables within a database. The field names should be identified along with their data type,field size and format.
-Primary keys and foreign keys be identified, including the names of tables to which the foreign keys link to.
-Any input masks, validation rules or default values should be identified for each field along with an example of what typical data might look like.
Files
Any files that will be used to import data should be designed, including the intended layout of data. Similarly, any files generated by the system should be designed, including the format in which the data will be exported.
Input Forms
-Data collection forms
-Screen layouts
-Validation Routines
Data Collection forms
Data collection forms are documents that are used to collect data without the use of a computer. These could include membership application forms, questionnaires, job applications or reply to slips.
Principles to follow when designing data collection forms:
1.Avoid color as the document may not be printed in color.
2.Include instructions about how to complete the form.
3.Give clear instructions about where the form should be returned.
4.Identify which questions must be answered and which are optional.
5.Provide enough space for each answer.
6.Use tick boxes for multiple choice lists.
7.Make it clear how many options are allowed to be chosen from a multiple-choice list.
8.Ensure all fonts are consistently used.
9.Avoid cluttering the form with too much information or too many questions.
10.Ensure the font style and size are legible.
11.If the respondent needs to complete a scale (e.g., 1–10), then explain what the scale represents (e.g., 1 = very dissatisfied, 5 = neither satisfied nor dissatisfied, 10 = very satisfied).
Screen layouts:
-A screen can be used to ask the user for data to be input or to display information to the user or a mixture of both.
Principles to follow when designing a screen:
1.Use color sparingly and appropriately; (colors that are usually seen as a positive color and red as a negative color.
2.Ensure all fonts are used with consistency.
3.Avoid cluttering the screen with too much Information.
4.Ensure the font style and size are legible.
5.Complete the form identify which questions must be answered and which are optional.
6.Provide enough space for each answer.
7.Use tick boxes for multiple choice lists that can have more than one response.
8.Use drop-down boxes (combo boxes) or option buttons (radio buttons) for multiple choice lists that can only have one response.
Validation Routines
Validation rules should be used wherever possible and be appropriate to reduce the number of possible input errors. They only need to be used for input data so any calculations or output data do not require validating.
Output reports
-Printed copy layouts
-Paper-based forms
Printed copy layouts
When designing a printed copy layout, consideration needs to be made to the size of paper that will be used, the size of margins and the intended audience. Printed copies can often include tabular data
Paper-based forms must include
1-Proper heading.
2-Text boxes to limit the amount of information.
3-Tick boxes to make choice easier.
4-Sufficient space to write answers.
5-Use clear fonts and clear text colors.
Development
The stage in the system life cycle when the software is produced.
Test data
data that will be used for testing a system
Types of test data
-Valid (normal data): Data that will be accepted by the validation rule
-Invalid (Abnormal or erroneous data): Data that will not be accepted by the validation rule
-Extreme: Data that will only be accepted by the validation rule because it is at the limit of acceptability.
Alpha testing
Initial testing of the software by a limited group of people
-Carried out by the developers or a specialized team of testers before a system is delivered to the user.
-Takes place towards the end of the development stage when the application is nearly ready for the user.
-Alpha testing is planned and structured using test data to follow all pathways through the software
Beta testing
A sample of users test the pre-release version of the software
-Used when software is being made available to a large number of customers.
-Beta testing only takes place after alpha testing has been completed.
-Beta testing involves customers using the software in a real-world environment using real data.
-As bugs are found within a beta version, new beta versions will be released for further testing before a final version is released for sale
White box testing
Testing the whole system in terms of structure and logic covering all paths throughout the system
-A testing method in which the internal structure/design/implementation is known to the tester
-Skilled tester’s are required to carry out white box testing
-Test plans can be created for each calculation
-Needs access to detailed design specifications
-Each module can be tested in depth
Black Box testing
Testing of inputs and outputs to a system or parts of a system with no consideration for the workings of the system
-A testing method in which the internal structure/design/implementation is not known to the tester
-Does not require programmer knowledge
-Limited amount of test scenarios are performed due to not knowing how each module works
-Test plans are difficult to design because of so many different input options
-Tests can be carried out by moderately skilled testers.
Test Plan
A detailed and structured plan of how tests should be carried out
Implementation
The stage in the system life cycle when the software is installed for the user
Four methods of implementing (Installing)
-Parallel running
-Plunge (direct) changeover
-Phased implementation
-Pilot implementation
Direct changeover:
The existing system in stopped and replaced by the new system immediately
Direct changeover Advantages:
-Cost is reduced as only one system is being used
-Data being used will be consistent as it is only being used in 1 system at a time
-There is no need for the new system to be compatible with the old
-Quicker method of implementing a system
Direct Changeover Disadvantages
-If the new system fails, old system is not available to fall back to
-Employees are not trained yet
Parallel running
The existing system works together with the new system for a period until the new system fully takes over
Parallel running advantages
-If the new system fails, old system is still available
-Accuracy of new system can be tested against the old system and errors can be fixed
Parallel running disadvantages
-Tasks will duplicate as data is being inputted in both systems thus additional staffing costs and data is not accurate in both
-May require additional hardware installed at the same time as the old hardware is still being used, will require physical space
Phased implementation:
The new system is gradually introduced (e.g when parts of the new system are working according to the requirement then new parts are introduced)
Phased implementation advantages
-If any errors, will only affect part of the system that has changed rather than the whole system
-End users can be trained how to use each phase of the new system and spend time using that phase before being trained in the next phase
Phased implementation Disadvantages
-Delays can occur waiting for each phase to run successfully before the next phase can start
-Confusion of which system to use for which part of the users work may cause data being updated in the wrong system
-Both old and new system needs to be compatible with each other in order for the data to be used across both systems
Pilot running
The new system is trialed in one part of the department, if successful then it is implemented across all the departments
Pilot running Advantages
-Any errors will only affect the pilot group that are using the system
-Errors found by the pilot group can be fixed before the system is installed for all users
-The pilot group can train other users on how to use the system because they will have experienced it for real
Pilot running Disadvantages
-It is time consuming as it will take a while to fully implement the new system
-If the system fails, modifications is required which will lead to further delay
-Both old system and new system needs to be compatible with each other in order for data to be shared between the pilot group and the user still using the old system
Technical documentation:
An overview of the structure of the system, how it was put together and how it works
What technical documentation will include:
-It will include a data dictionary to show how data has been structured within the system.
-Any programming code or macros will be annotated to explain their purpose.
-All validation rules will be listed with the criteria used for successful input and the error messages that they generate.
-The purpose of calculations within the system will be identified and an explanation given of how each calculation works.
-All buttons and links will be listed, including where they are located and what their function is. All files used by the system will be listed and their purpose identified.
-The technical documentation will also include flowcharts, entity relationship diagrams and screen connectivity diagrams.
Installation guide (technical documentation)
-There will be an installation guide for the installation team. All the results of testing will be recorded, including any known errors and bugs.
-Backup routines will be detailed to show where files are stored.
-All security settings will be documented to show which groups have access to each part of the system and the permissions they have been granted. The software and hardware requirements will also be listed
User documentation:
A user guide giving instructions to the user on how to use the software
What a User documentation will include:
-All the software and hardware requirements will be listed within the guide.
-The main part of the user guide will be the instructions on how to use the system. This should include written instructions together with screenshots of the system or photographs of hardware.
-Arrows can be used to point to parts of screenshots or photographs. Bullets or numbering should be used to break instructions down into manageable tasks.
-A glossary will show an alphabetical list of any technical terms that have been used within the user guide and a definition of each of those terms.
-There should be a troubleshooting section that includes a table of common problems (for example, error messages) together with a description of what might have caused the problem and possible solutions for overcoming the problem.
-An index will be included at the end of the user guide with page numbers for each popular term.
Why Technical Documentation is Required?
-Technical documentation is required so that anybody carrying out future maintenance on the system will be able to understand how the system was developed and how it is configured.
- It is unlikely that the person carrying out future maintenance is part of the original development team and so will not be familiar with the system without the technical documentation.
Why User Documentation is Required?
-User documentation is needed so that the user can learn how to use the new system or look up how certain features are supposed to work.
-The troubleshooting section will be important for the user to understand what has caused an error to occur and what they need to do to stop the error from occurring.
Evaluation
-It is a formal review of a project
-When a system has been developed and installed, the whole process will be evaluated. This is sometimes referred to as a review.
-The evaluation will consider how the project team and end users worked together so that lessons can be learned for future projects
-Users will be given questionnaires to find out what they think of the new system and how they feel it is improving their workflow (or not). Some users will also be interviewed about their interaction with the new system.
Whether system meet the user requirements
-Users will have been given an opportunity to feedback on how well, the new system is working for them and if there are any problems.
-It is expected that the new system will work more efficiently than the old system. However, if there are problems that need addressing, then actions will be taken.
-Feedback will have been gained from users as to how well, they have adapted to the new system and how easy or not they find it to use
- If there are issues regarding ease of use, then plans can be made to simplify any processes by adding additional features to the software if necessary. There will also be an opportunity for users to make suggestions for future improvements or additions to the system.
Maintenance
-Changes made to a system after its implementation
Types of maintenance
Perfective
Adaptive
Preventive
Corrective
Perfective maintenance:
-Always looking to improve a system.
-May be ideas to make the system perform better or to do additional tasks.
-If a system remains in place for several years without any improvements, then it may become outdated and inefficient compared with other systems that are available.
-Users will also have new ideas and if they are likely to improve efficiency then they should be embrace.
Adaptive maintenance:
-There could be changes to internal procedures within an organization or changes the organization has no control over.
-It’s necessary to adapt to changes so that the system continues to work effectively and doesn’t produce incorrect outputs.
-There is also a need to adapt to new technology such as a new operating system, new web browser and new hardware
Preventive maintenance:
-Required to prevent problems arising within a system. This can apply to both hardware and software.
-Hardware should be regularly cleaned to stop dust from blocking any fans and regular scans of storage media should be carried out to ensure they are working properly.
-Heat should be monitored within systems for any abnormalities to prevent hardware failures. Data should be regularly checked for consistency and integrity.
-Performance of the system should be monitored to ensure that the processor, memory and storage are all working efficiently. By carrying out regular preventative maintenance, system downtime can be avoided.
Corrective maintenance:
-when errors and bugs are found within a system they needed to be corrected
-Errors needed to be corrected so the system can run efficiently and accurately and produce the results required by the organisation
Prototyping:
A ‘mock-up’ of a software solution in a primitive form. Used to demonstrate how a system will look and work. It is usually focused on the user interface, rather than any data structures.
Types of prototyping:
-Incremental
-Evolutionary
-Throwaway/rapid
Incremental prototyping:
-Takes an iterative approach in which requirements are specified, an initial prototype is developed, the prototype is reviewed and then requirements are clarified, and the prototype is improved based on feedback.
-Each prototype will build upon the previous one and include more functionality until a final product is built. At each stage, only clearly understood requirements are developed
Evolutionary prototyping:
-There is no requirements specification at the start of the project, but instead there might be a goal or an aim.
-Both the analyst and developer begin the project by brainstorming ideas.
-The developer will start working on some of the best ideas
-While the analyst will discuss with the customer what the problem is and what is needed to solve the problem.
Throwaway/rapid prototyping:
-The prototype will never be apart of the final delivered software but will be discarded.
-A loosely working model is created following a short investigation
-with the aim of trying to get something tangible to the client as soon as possible for feedback as to how well the requirements are being met.
Advantages of prototyping:
-Problems can be identified early on and modifications can be made before it becomes very costly to make changes
-Requirements can be clarified and refined following feedback on the prototypes
-End users will be more involved in the process, giving them more ownership of the solution and providing valuable feedback
-If prototype is evolutionary, users can get used to using parts of the system before having to use the whole system, reduces the need for bulk training. Thus cheaper to make changes earlier in the process than after real development has taken place
-using feedback from end users, developers will have much better understanding of what the users are expecting and so a better quality solution will be provided.
Disadvantages of prototyping:
-Requirement analysis can be rushed, thus prototypes dont reflect much of what the end users are expecting
-With rapid prototyping, the prototype can become rushed and when trying to develop into a working system, it may hav significant design flaws or structural errors that carry through to the end solution.
-Disappointment of users can arise if features in the prototype model is not available in the final software, as the features cant be funded, known as “feature creep”
-Iterative process of feedback may last too long if the user is regularly wanting changes to be made to the latest prototype
-The initial cost of developing a prototype are high compared with traditional designs.
Methods of software development:
-Incremental development
-Iterative development
Incremental development:
-Creating a system or adding new functionality in small parts.
-Part of the software is developed fully, including improvements from feedback, before moving on to the next part of the software.
Iterative development:
-Creating a system or adding new functionality in a repetitive cycle
-Iterative development is about planned rework throughout a project. It allows for feedback to be given by the customer and improvements to be made based on that feedback.
Development methodologies:
-Waterfall method
-Agile
-Rapid application development (RAD)
Waterfall method:
-Involves gathering all the user requirements at the beginning of the project.
-When the requirements are defined, the process runs ‘downhill’ like a waterfall.
-As each stage starts, changes may need to be made to the previous stage because of user feedback or lessons that have been learned during that stage.
-The waterfall method relies upon the requirements being clearly defined, which is an unrealistic expectation, so it is fundamentally flawed.
Advantages of waterfall method:
-Each stage is completed before moving onto the next one, making management of the project more structured and controllable
-Its a simple model to understand and use because each stage is distinctly separate from the other stages
-It works well for projects where the requirements are clearly understood and are unlikely to change
-The process followed and the resulting software are well documented, thus new team members can get up to speed very quickly
-The client and the project team work to a set timescale and a set budget, which removes a lot of uncertainty from projects
-The requirements are clearly set from the beginning of the project and are used to measure the projects success when its completed
Disadvantages of waterfall method:
-The customer only sees the product at the end of the project
-Its hard to measure progress within each stage as the milestones are just the beginning and end of each stage
-It doesn’t work well for complex projects where the requirements cover a large variety of aspects and aren’t clearly understood by everyone involved
-Projects can take longer to deliver than other methods because of the emphasis on planning and documentation
-Client involvement is limited to set times within the project which can lead to requirements not being met to the clients expectation
-The model doesn’t accomodate changes to requirements
Agile:
-Being able to respond to a customer’s changing requirements, even late in the development life cycle.
-The agile approach uses iterations with each iteration including the planning, design, development, and testing of part of the software.
-At the end of an iteration, a working solution for that part of the software is ready for demonstration.
-Agile is both iterative and incremental. It’s incremental because each iteration can be planned to be improved upon in future iterations. It’s important not to get the words iteration and iterative confused. Each iteration increments the existing functionality, and each iteration is iterative in nature.
Advantages of Agile:
-Customer gets to see completed parts of the software quickly, enables them to adapt their requirements for other parts of the software
-Customer, designers, developers and testers are constantly interacting with each other which reduces delays
-There is unlimited access to the customer which means their needs are more likely to be met
-There is no complicated bureaucracy that delays decision making
-The customer doesn’t have fixed budget or timescale so customer needs can be met above timescales and budget
-Bugs and problems can be fixed quickly because the designers, developers and testers for each iteration are working closely together
Disadvantages of Agile:
-As requirements change, its difficult to know how much a project is going to cost and how long it will take and projects may seem to never have an end in sight
-The project can easily go off track if requirements change too much
-Experienced senior programmers are needed to be able to make quick decisions during each iteration
-There will be minimal documentation produced, thus new team members can take longer to get up to speed with the project and there can be a large learning curve when maintaining the software
-The software, especially user interface, can become disjoined because iteration is worked on separately
Rapid application development (RAD):
-Uses prototyping to develop a system in a very short time frame, usually less than six months.
-Users are key in the prototyping stage and provide feedback for refinements. This type of user involvement is known as joint application development (JAD) because the user is jointly involved with the developer in the development of the system.
-Less time is spent on planning and design and more emphasis is put on the development phase.
-Strict deadlines are allocated throughout the development of the system. User needs to understand that, if requirements are too complex, then they must be simplified or removed from the project.
-RAD is based on an incremental model in that each timebox will deliver specific functionality.
Advantages of RAD:
-The high level of user involvement, means solution is more likely to be suitable for end users, who will also have ownership of the solution
-Users are often not sure what the requirements of a system should be from the outset and so evolutionary approach of RAD enables the requirements to evolve
-The strict deadlines ensure that the project will be complete on time and prevents “feature creep”
-Prototyping of the interface with user involvmnmet means less time spent on design and more on development, leading to a shorter overall project
-Software application frameworks mean that a user interface can be developed quickly and users can even be involved in configuring the layouts of screens and reports
Disadvantages of RAD:
-Requirements are not clearly specified from the outset and so the final solution may not meet the entire needs of the organisation
-Users are required throughout the whole process and they also have their normal day jobs to do. This can lead to work overload or the need for temporary staff
-The structure of the system may be compromised, leading to instability, as the focus is on the user interface and getting a system developed rapidly
-The strict deadlines means that some parts of the project could be rushed and not complete to a high enough quality
-Software application frameworks dont produce efficient code thus end solution will not run as quickly as if it had been developed from scratch
-Users who are not involved in the JAD approach may be disappointed that they didn’t have a say in the process and they system may not meet their specific needs.
