Systems Analysis Flashcards
1
Q
Describe the Waterfall methodology.
A
=> Initially designed for use in manufacturing and engineering environments where the products being created were based around hardware rather than software.
=> Has a linear nature, with deliverables produced at the end of each stage.
=> Stages are arranged in order and it is impossible to begin a stage of development without the previous being completed.
=> Deliverable document produced at the end of each developmental stage, to inform the next stage.
2
Q
Describe the purpose of design documents produced at the end of each developmental stage in teams using the Waterfall methodology. How is it ensured that each team is handed the necessary information to continue development?
A
=> Can be shown to clients or used internally. These must be detailed and accurate as it is likely that all teams working on developmental stages work completely separately from each other.
=> Testing of deliverables occurs at the end of each stage of development to ensure that the document provided meets requirements.
3
Q
What are the advantages of using the Waterfall approach to software development?
A
=> It’s linear approach (sometimes).
=> Deliverables can be used to provide milestones (concrete deadlines), which helps to improve client confidence.
=> Deadlines mean that teams are more disciplined to a large project.
=> Simple to understand and is suitable for large projects where the requirements are clearly understood.
4
Q
What are the disadvantages of using the Waterfall approach to software development?
A
=> Its linear approach (sometimes).
=> Much less flexible than other alternatives (such as the Agile approach).
=> Difficult for systems developers to react to changes or problems that crop up during any later stages (E.g. if a problem is discovered during implementation, it may be necessary to back to the top of the waterfall to revise the requirements).
=> Difficult for software engineers or their clients to completely understand the requirements of a system at the start of development. A projects requirements will commonly change over a projects life cycle (this is because programmers come to understand the area in which they are working and the client better understands what the software might be capable of).
=> Problems are amplified by how long the approach can take to implement, it is perfectly feasible for the process to take so long that, by the time the project is completed, requirements have changed dramatically.
5
Q
Describe the Agile methodology.
A
=> Created in the 1990s.
=> Provide a flexible alternative to more structured development models.
=> Many variations which are all based on the same founding principles.
6
Q
What do Agile methodologies value?
A
=> Collaboration and people over processes and tools.
=> Strong focus on providing programmers with the tools and resources they need, then trusting them to develop a solution to the
posed problem as efficiently as possible.
=> Teams trusted to organise and manage themselves, with a focus on regular meetings and interactions, rather than heavy documentation.
7
Q
How do Agile methodologies’ focus on collaboration to customers?
A
Programmers spend much more time meeting regularly with clients to discuss the system’s development.
8
Q
How do programmers using Agile methodologies differ from those using Waterfall methodology?
A
Agile programmers:
=> Favour using their time to produce software rather than detailed documentation.
=> Prefer their projects to be judged on how well their software works, rather than how development has been documented.
9
Q
What are the advantages of using Agile methodologies?
A
=> Programmers able to deliver well-written software much faster than programmers working with more rigid developmental approaches.
=> Avoidance of lengthy documentation, along with high levels of client contact.
=> Able to quickly adapt to changes.
10
Q
What are the disadvantages of using Agile methodologies?
A
=> Some agile techniques (e.g. pair programming), are not popular among developers or managers.
=> A lack of documentation and specific deadlines lead to problems with customers unfamiliar with the Agile approach.
11
Q
What is the difference between application systems and systems software?
A
=> Application systems allow users to achieve some purpose.
=> Systems software is the system that runs in the background on the computer, providing a base platform on which apps are run.
12
Q
What are legacy systems?
A
=> Systems that were around many years ago.
=> Use old technology and may be archaic by modern-day standards.
=> Could be upgraded, but the cost of replacing legacy systems can run into the millions meaning that not all of them get replaced.
13
Q
Why might some companies build a new front-end for legacy systems that they retain?
A
To allow for a new way of interacting with the system, using modern technology such as the WWW.
14
Q
What reasons could there be to commission a system?
A
=> Company Expansion.
=> Old systems being too slow compared to modern alternatives.
=> Lack of support for old software.
=> Desire to capitalise on new technologies.
=> A new business venture has been identified.
15
Q
What does building new ICT systems require (on top of requiring programming skills)?
A
=> Business expertise. => Analysts. => Project managers. => Testers. => Technical authors. => Marketers. => People with good awareness of business methods, people skills and creative problem solving.
16
Q
What is they system analysis cycle?
A
A series of steps that are followed when producing/upgrading a new ICT system.
17
Q
What are the phases of a systems analysis cycle?
A
- Problem Definition;
- Feasibility;
- Analysis;
- Design;
- Build;
- Testing;
- Documentation;
- Maintenance;
- Evaluation.
18
Q
What aspects of systems analysis cycles do not have to remain consistent across different projects?
A
The stages that are used since not all of them have to be used in every project.
19
Q
What/who is a stakeholder?
A
An individual, or a group of people, with a vested interest in the new system being built.
20
Q
How do passive and active stakeholders differ from each other?
A
=> Passive stakeholders: not involved in the production of the system.
=> Active stakeholders: have a part to play in the system to be built.
21
Q
Which two companies are involved in creating a new system under normal circumstances?
A
The company that requires a system to be built and the company that will produce it.
22
Q
What is the single biggest cost in the development process?
A
Staffing.
23
Q
What is the difference between the user and the customer?
A
The customer is the person who requires a new system, the user is the person who will use the system.
24
Q
Why is it important to consider the users when developing software?
A
They are the people who will be interacting with the system on a daily basis; the system will fail if it doesn’t meet their needs.
25
What role do programmers take when it comes to software development?
=> Develop and build the system using information passed to them by the system analysts.
=> Rarely have any direct involvement in the analysis or design of a system.
=> Usually the people who spot the more subtle problems with the system and their input is invaluable to the system's analysts.
=> Lead programmer commonly spoken to by systems analysts during the systems analysis cycle, to get the programming teams thoughts and ideas.
26
What role do systems analysts take when it comes to software development?
=> Find out exactly what the customer wants.
=> Use their experience and expertise to fill in the blanks that occur along the way (since most customers are not sure exactly what they want at the start of the project, although they usually have a vague idea).
=> Responsible for conducting fact finding and producing the requirements specification.
=> Suggest possible implementation methods for the proposed project.
=> Monitor the project and offer expert knowledge on the system being built.
=> First port of call for programmers if they have a problem with/query on the requirements specification.
27
Describe the problem definition stage of systems development.
=> It is the process of identifying existing problems in a user's current system, or defining what problems a new system could solve.
=> User will have problems with their existing system identified (by themselves or by an outside source), or will have a software idea that could improve their company.
=> Very little will be known about the project at this point, other than a perceived need for the system.
=> An initial meeting will be called where it is critical for both the customer and the dev company to fully discuss an agree upon
requirements for the system; this allows the user to decide whether they are comfortable with the dev company, and the dev company can decide whether they want the company to take on the project.
=> Customer and dev company agree upon the scope of the project.
28
Why is it important for the customer and development company to agree upon a scope at the start of any project?
It is common for customers to have an unrealistic view on what is required for the new system.
29
Why are unbound projects guaranteed to fail?
If a project is unbound, there is no way to differentiate between what the customer required at the start and what they want 6 months down the line.
30
When are development companies likely to choose a methodology that allows them to change requirements quickly, such as Agile?
When requirements are fluid.
31
Why is it important for analysts and customers to work together to ensure that problems are solved in the correct way?
=> Analysts are computer experts, but are not necessarily experts in the customers business.
=> Customers are experts in their own business but are not necessarily computer experts.
32
What is the purpose of a feasibility study?
=> Establishes whether or not the project is feasible, given the scope laid out during the definition stage.
=> Considers whether it is desirable for the developing company to proceed with the project.
33
What must there be when embarking on a software project?
Confidence on both sides that the project can be delivered on time and within budget.
34
What is likely to happen if the project is not delivered on time or outside of the agreed upon budget?
The customer:
=> The customer may decide to choose a different supplier.
=> The customer may become dissatisfied with the work.
The development company:
=> Could receive a poor reputation.
35
When would a project be considered a failed project?
If it fails to meet time and/or financial restrictions.
36
When might a development company decide to not proceed with a project?
=> If a project is unlikely to bring in much profit.
| => If a project might bring negative attention to the company.
37
What factors must be considered when deciding if a system is feasible?
```
=> Economic Feasibility.
=> Time Feasibility.
=> Technical Feasibility.
=> Political Feasibility.
=> Legal Feasibility.
```
38
Describe economic feasibility.
=> Projects have specific budgets which must cover all costs, including: software licences, hardware, human resources/wages, and the development company's running costs.
39
What is important to consider when deciding whether a project is economically feasible?
It is important to consider whether the proposed system will turn a profit.
40
Why do hardware and software costs tend to be straightforward?
They are unlikely to change over the course of a project.
41
What variables are important to how much staffing will cost?
=> The number of people working on the project.
=> The rate of pay for employees.
=> The length of time of the project.
42
What important measures should be taken to get an accurate estimation of a projects cost?
It's important to:
=> Know up front which staff will be needed.
=> Have a good idea of the project's length.
=> Build in some flexibility, based on a risk assessment.
=> Consider whether the expected profit justifies funding the project; if the project would break-even or would result in a loss, the development company may decide that undertaking the project wouldn't be worthwhile.
43
What might some development companies do if work is scarce?
Take on a project at a cost or at a slight loss.
44
Describe time feasibility.
=> It is critical that projects are delivered on time. This is because late projects result in going over budget due to the cost of developers' wages, and the developing company will make a negative impression if they cannot deliver what they said they could.
=> May be even more time critical if the customer has very pressing business reasons for a project to be delivered for a certain date.
=> Failure to meet an agreed upon date could lead to litigation.
45
How is a projects length decided?
=> The project manager has to estimate how long their developers will take to complete the project.
=> This requires a balancing act based on the cost, skill level, and number of staff to bring onto the project.
46
Describe technical feasibility.
=> Can the project be done with the technical resources available?
=> Is the required project possible with current technology?
=> More likely to be a problem if the development team doesn't have the skills required to satisfy the projects requirements (E.g. if you need an expert in SQL for the project but one isn't available, the project either cost more due to the need to outsource or it won't be technically feasible).
47
What is a skills audit?
=> Developers are required to fill out a skills audit whenever they join a company, to show what technologies they can work with.
=> This is updated as developers squire new skills.
48
How does a project manager decide who should undertake a project?
=> They check the audit list to check who is capable with the required technologies.
=> If no one is capable, the project is unable to go ahead.
49
Describe political feasibility.
=> Some projects may have aspects that are politically sensitive or that go against the beliefs of certain groups.
=> Systems such as NHS, tax credits, Olympic computer systems and and animal testing all come under strict scrutiny of the general public and media.
=> Any projects such as these that go wrong will be reported and shown in a bad light by the media, painting the development company in a bad light.
=> The development company has to decide whether the potential positives of undertaking the project outweigh the possible negative publicity.
50
Describe legal feasibility.
=> Helps decide whether the project will be able to comply with all laws that may affect it in the countries where it will be released.
=> Fines into the millions can be imposed if the software does not comply with the law.
=> Some countries might even ban use of the project and could even pursue criminal action.
=> Must be taken very seriously as the effects can be very damaging for both the customer and the development company if legal
action is taken.
51
What type of software has come into conflict with the law, even though it isn't illegal in essence?
File sharing software; companies producing or facilitating it have been sued.
52
What is a real-world example of when a company has been affected by legal action?
Napster was shut down for a long time as courts decided that the company could do more to protect copyright. It then released
a paid service, but it didn't do very well as the company had already lost most of its customers to competitors.
53
What is involved in the analysis stage of systems development?
=> Analysis is the process of finding out exactly what the system will entail by employing various fact finding methods.
=> Critically important that the result of the analysis is as complete as possible, to avoid incorrectly defined requirements; these could lead to big delays and escalated development costs.
=> Specification for the project is produced at the end of analysis.
54
What is the project specification?
The document that contains the exact requirements of the new system.
55
Which four main fact-finding methods are used during analysis?
=> Observation.
=> Questionnaires.
=> Document Collecting.
=> Interviews.
56
Why are the four main fact-finding methods meant to be used collectively, rather than on their own?
It is impossible to gather a complete picture of the system by using only one method, or by talking to only one person.
57
What is considered the 'key to success' when conducting systems analysis?
Trying to understand the business problem from the point of view of the company as a whole, rather than from an individual perspective.
58
Describe the 'observation' fact-finding method.
=> Analyst shadows employees of the customer and takes notes on how they do their job.
=> Employees observed in their natural environments to see exactly how the business works.
59
What is one of the biggest advantages of the 'observation' fact-finding method?
The analyst sees parts of the system that employees may not realise are important, or that they might not consider important enough to discuss.
60
What are the advantages of the 'observation' fact-finding method?
=> Pick up parts of the system that are not immediately obvious to the customer.
=> Confirm information gathered through different fact-finding methods.
61
What are the disadvantages of the 'observation' fact-finding method?
=> Some people may feel threatened while being watched/observed.
=> There is no guarantee that some of the more subtle parts of the system will show up during the observation period.
62
Describe the 'questionnaire' fact-finding method.
=> Quite a common method of fact-finding, but can be one of the most difficult.
=> Allow the analyst to get a lot of responses on a specific subset of requirements.
=> Likely to return a range of responses since they can be given to a range of people.
63
What makes designing a questionnaire so difficult?
Requires knowledge of both the system to be built and the range of people to whom the questionnaire will be sent.
64
Why can questionnaires only give limited information about very specific parts of the system to be built?
The number of choices available for each question must be restricted, as some people may give unexpected responses.
65
What are the advantages of the 'questionnaire' fact-finding method?
=> Can be given to a large number of people all at the same time.
=> Can get a large number of different opinions.
66
What are the disadvantages of the 'questionnaire' fact-finding method?
=> Hard to design and create.
| => Not all questionnaires that are sent out will be completed.
67
Describe the 'document collection' fact-finding method.
=> Analysts gather any business documents that relate to the new system to be constructed (includes orders, invoices, financial records, and any other document that is used on a daily basis).
=> Documents in use in the current system are a good guide as to what to implement into the new system.
68
What key elements could be inferred from analysis of existing documents when conducting document collection?
=> The data they use and what will need to be stored in the new system.
=> Analyst is able to get a good understanding of how the business runs by following the trail of documents and seeing the flow of data from start to finish.
69
What are the advantages of the 'document collection' fact-finding method?
=> Documents are reliable and show most of the data stored in a system; they cannot be doctored unless someone has purposely gone out of their way to alter the data.
=> Document trails help support the analyst's picture of business processes.
70
What are the disadvantages of the 'document collection' fact-finding method?
=> Documents give a limited view of systems and do not say how they were created.
=> Documents may contain sensitive information and there may be restrictions on seeing them.
71
Describe the 'interview' fact-finding method.
=> Usually where most analysis starts.
| => Some key stake holders of the project are selected and are asked targeted questions about the current and new system.
72
What are the advantages of the 'interview' fact-finding method?
=> Large amounts of information can be gathered and the analyst can respond to the person to query their responses.
=> Produce detailed responses about key parts of the system.
73
What are the disadvantages of the 'interview' fact-finding method?
=> Time consuming; only a limited number of people can be interviewed.
=> May not be fully truthful meaning that responses must be verified.
=> Human nature plays a major role, as not everyone is good at being interviewed and some people may be nervous or even mildly hostile towards the analyst.
=> Interviewees may exaggerate what they do to try to impress the analyst or their superiors.
74
What is meant when talking about a system's requirements?
=> A specific feature of the new system.
=> Recorded in a document called a requirements specification.
=> Can be broken down into three sub-categories.
=> Must be measurable; important contractually so that the development company can be paid, but also helps the scope of the project.
=> Ambiguous requirements could be interpreted by different stakeholders in different ways; leading to problems, and potentially to conflict.
75
How can the 'requirements' phase of systems analysis be broken down?
=> Interface requirements.
=> Functional requirements.
=> Performance requirements.
76
Describe the 'interface requirements' sub-category of system requirements.
Systems mainly driven by software, however some newer systems also include a hardware interface (E.g. Guitar Hero).
77
Why is it important that detailed analysis has already been carried out on what the user may require when setting interface requirements?
Interface requirements depend on the end user and also on the complexity of the new system.
78
What is a common mistake when setting a systems interface requirements?
=> Confusing interface requirements with interface design.
=> The development company is not worried about the interfaces appearance, or how the user will interact with the system, at this stage.
79
What are the most important aspects of setting interface requirements?
The standard to which the interface must conform to be considered suitable by the end user.
80
Describe the 'functional requirements' sub-category of system requirements.
=> The functional requirements of a system are simply requirements the development company need to achieve for the project to be considered successful.
=> Detail what the system will do and what key features it will have.
=> Dictate what the software's features should do - not what they should look like.
=> Very common for a described feature to have no possible UI.
81
Describe the 'performance requirements' sub-category of system requirements.
=> Cover aspects such as response times and throughput.
=> Must be specific.
=> Requirements set out must be realistic and measurable.
=> Requirements should not all be 'everything should run very fast' since a majority of what the system does is very mathematically
complex.
82
What is meant by 'throughput'?
A measure of how much data is transferred from source to destination.
83
Give an example of a specific requirement that could be user within the 'performance requirements' sub-category of system requirements.
'The user interface must respond to a request from the user in a bounded time of x seconds'; where bounded is a reasonable maximum time that has been agreed by both the customer and the development company.
84
Why is it unrealistic for a system requirement to be that the system always runs at the same speed?
A user could be running the software on a slower pc.
85
Why is it important for performance requirements to be realistic and measurable?
Failure to implement this could lead to differing opinions between the customer and the development company.
86
What is meant by a systems 'requirement specification'?
Document that provides a basis for design, as well as a fundamental reference for all of the other phases of the software development cycle, most notably the evaluation phase.
87
Why is it important to follow a template when creating a requirements speification?
To ensure that it is correct.
88
Give an example template that could be used when creating a requirements specification.
1. Introduction
2. Purpose
3. Scope
4. Definitions and abbreviations
5. References
6. Overview
7. Overall description
8. Product perspective
9. Product functions
10. User characteristics
11. Constraints
12. Assumptions and dependencies
13. Specific requirements
14. Interface Requirements
15. Functional Requirements
16. Performance requirements
89
What key elements to a requirements specification template are necessary for understanding its purpose?
=> Purpose and scope.
=> Product functions and product perspective.
=> User characteristics.
=> Constraints.
90
What is meant by purpose and scope when discussing a requirements specification template?
=> Every project needs a scope, otherwise if the project is unbounded, the development company will not know when they have finished.
=> Stating the exact expected outcomes and limitations of the system means misunderstandings over what the project is capable over can be prevented.
=> The system's purpose is also crucial; if it is misunderstood by any of the stakeholders, problems will arise when it comes to signing-off the system.
91
What is meant by product functions and product perspective when discussing a requirements specification template?
Describes where the system fits into the larger picture, or its role in the business.
92
What is meant by user characteristics when discussing a requirements specification template?
=> Where the user's end experience of the system is documented.
=> This is key when writing the UI requirements.
93
What will happen if the end system is not accessible by the end user?
The system may not be used correctly and will ultimately fail.
94
What is meant by constraints when discussing a requirements specification template?
=> The key boundaries and limitations to which the new system must adhere.
=> Related to the scope of the project, and to the feasibility study.
95
Describe the design process when developing a new system.
=> Can only begin once the requirements specification has been completed.
=> Requirements of the system are taken and are used to decide; how the system will look, how it will store data, and how it will process said data.
=> Each requirement must be included within the design.
96
What four areas make up the design stage?
=> Hardware and software choices.
=> Data structure design.
=> Input design.
=> Output design.
97
What is the 'input' component of the design stage?
=> AKA interface design.
=> Shows how information will be input into the new system as well as how it will be displayed after it has been processed.
=> Does not describe how the information will be processed, and does not look at the functional requirements other than to show interaction.
98
What is the 'output' component of the design stage?
=> Considers what triggers the output to occur (normally triggered by something that the user has done through use of the UI).
=> There are no hard or fast rules on what designates an output trigger, but there must always be one for every output designed.
=> If a trigger cannot be identified for an output, that output will never be seen.
99
What different methods can be used to trigger an output in a system?
=> Entering new data into a system.
=> Clicking on specific buttons.
=> The completion of a scheduled batch process.
100
What is the 'data structure design' component of the design stage?
=> Fundamental to how a system will work.
=> Dictates what needs to be stored on how the data will be organised.
=> Has a direct impact on how the rest of the system will work.
=> Impossible to produce an input or output design without knowing exactly what data will be stored.
=> Data structure design process tends to start with listing all data that is required (this information will already have been gathered during analysis and placed into a data dictionary).
101
What is a data dictionary?
```
Stores:
=> Every item of data.
=> The type of data.
=> The size of the data.
=> A comment to explain what the data means.
```
102
What happens once a projects data dictionary has been completed?
Decisions are made on how the data will be saved.
103
What are a few ways in which data could be saved?
=> In a file.
| => In an SQL database if the system is of a larger scale.
104
What must occur if database is used to save/store data?
Normalisation must be carried out.
105
What is abstraction?
=> Removing any unnecessary details from complex problems, in order to create a much simpler problem.
=> Generalising the idea of how t solve a problem away from any specific implementation detail.
106
What two parts can abstraction be split up into?
=> Control Abstraction - hiding the details of machine code from the developer; this is the basic premise of high-level programming
languages.
=> Data Abstraction - hides how bits are organised for primitive data types such as floating points or dates.
107
What is the difference between 'abstract' and 'primitive' data types?
=> Abstract - Created by users and used in libraries (E.g. classes in OOP).
=> Primitive - Supported by the language directly and are not composed of any other data types.
108
Why are abstract data types (e.g. stacks and queues) an example o abstraction?
Only the operations performed on them and any constraints on the data type are defined (E.g. a stack would define what push and pop do while an ordered set would define the items that must be held in a logical order).
109
What is considered one of the most important skills for a developer to cultivate?
The ability to think on abstract terms; allows you to consider the ideas behind an algorithm or system without getting bogged down with the implementation details.
110
What is it possible to do when abstracting a problem?
=> Generalise in layers, with each layer hiding more of the key implementation details than the last.
=> Combine multiple layers, enabling more and more concrete implementation to be generalised.
111
What is it important to do after the component parts of a problem have been identified?
Identify how the solution will be structured.
112
How would a large scale system be broken down?
1. The system would be broken down into modules comprising of smaller classes and functions.
2. These classes and functions would then be further brown until the modules are small enough that they can be easily designed and implemented (This would usually mean breaking down a problem to the point of single classes in an OO system).
113
What can you use when representing a system in diagrammatic form?
=> Flowcharts.
=> Data flow diagrams.
=> Entity relationship diagrams.
114
Why are different types of diagrammatic forms commonly used in conjunction?
Each can be used for different purposes, so they are commonly combined to give a full overview of a system.
115
How are entities represented in an ERD?
=> Each entity is represented by a rectangle.
| => The text inside the box if the name of the entity.
116
How are relationships represented in ERDs?
=> A relationship is shown as a line.
=> The crows feet represent the cardinality of many.
=> It is read one-to-many from the single point to the crows feet.
=> The text describes the relationship.
117
Describe an entity relationship diagram.
=> Used to show entities relate to one another.
=> Three kinds of relationships that can relate entities to each other.
=> Provide a quick point of reference for creation of a database.
=> Provide an excellent way of working out which entities will be involved in query.
118
What are the three types of relationships that entities can have with each other?
=> One-to-one.
=> One-to-many.
=> Many-to-many.
119
What must be removed during normalisation?
Any many-to-many relationships between tables.
120
Why should queries be given considerable thought?
Most queries will span across multiple entities.
121
Describe a flow chart.
Can be used in two ways:
=> To show the overall flow of the system (system flowchart)
=> For representing an algorithm.
122
What are systems flowcharts used for?
=> Show the relationship between components and how data flows between them.
=> End goal of gaining an overview of how data will pass through the system, rather than looking at specific individual algorithms.
123
Describe a data flow diagram.
Show how a system will process information.
124
What are two advantages of using DFDs over flowcharts?
=> FDs can be broken down into multiple levels.
| => Show the distinction between internal and external parts of the system.
125
What are the three main symbols used in DFDs?
Symbols for:
=> External entities (Rounded rectangle).
=> Internal processes (Tall Rectangle).
=> Data stores (Short rectangle).
126
What do external entities represent in a FD?
=> Anything from outside the system to be modelled.
=> Tend to be some form of human input but could also come from other sources such as sensors or a separate system.
=> Other external entities sometimes need to be involved in a data flow, and should be represented on the diagram (E.g. letting the warehouse staff know that a new order has been made).
127
Describe an internal process in terms of FD.
=> Where something is done with the input that has been given.
=> All processing that happens will take place within an internal process.
128
What does a data store represent?
=> A database
| => Anything else that can store data
129
When is it common for DFDs to make use of return arrows?
=> If data needs to be returned.
| => As confirmation that a transaction was successful.
130
What are arrows used for in DFDs?
=> To show the flow of data.
=> Can be labelled to express something such as the type/nature of the data to flow.
=> Better to leave unlabelled if an arrows purpose is clear, in order to avoid clutter.
131
Why is the numbering system important?
Allows:
=> Different levels of DFDs to be used.
=> Reference to the diagram if notes are going to be made.
132
What can be done to internal processes to allow for me detail?
They can be broken down into multiple levels.
133
What is development in terms of building a new system?
=> The planning, writing and testing of the software.
=> The creation and testing of any required hardware.
=> Writing of the user documentation.
=> The longest part of the process for creating new applications.
134
Why is testing an important part of systems developmet?
Untested or poorly tested code tends to result in unstable applications and wrong output, lead to dissatisfied customers and users.
135
Why do most developers find it difficult to find bugs in their own programs?
=> They make subconscious assumptions and use their software in the way they assume other users will.
=> Other users may use the software very differently to how the developer intended the software to be used, making passing the software onto outside sources can be beneficial when testing.
136
Why is it common for more than one type of testing strategy to be used?
The better tested a software is, the more robust it will be.
137
How is bug fixing affected as the project progresses?
The later a project is into development, the harder and more expensive it will be to fix them.
138
What is 'white box testing' (AKA 'glass box testing')?
=> Where the structure of the code is being tested (requires knowledge of how the code was developed).
=> Each path through the program must be tested to ensure that code will run as expected/intended.
=> Tend to be carried out by the developer since they understand the code and know which values should trigger which paths through the code.
139
What happens every time a control statement (E.g. an IF statement) appears in a program?
A new path is created through the system.
140
What are unit tests?
=> Programmers usually create some unit tests to ensure that the code they've written runs as expected.
=> Run the code to be tested with various sets of input, usually using an automated script that can be run regularly.
=> Defined differently depending on the language chosen, but normally make use of OOP.
=> Most of the framework for UTs is based on inheriting the testing features of a base class ('TestCase' class is used in Python's case
141
What do unit tests allow developers to do? Why is this necessary?
=> Allow fast regression testing (picking up bugs downstream) of existing code.
=> Necessary because most large products have many developers working on different sections of code and changes that one one developer makes could affect another developers code.
142
What criteria must unit tests meet?
=> Written by developers under the guidance of the methodology being used for the project.
=> Should use valid, invalid and extreme values to ensure that the system can cope.
143
What are the advantages of using unit tests?
They are a great way for the developer to:
=> Do alpha testing in a systematic.
=> Continue to test their code throughout the lifetime of the project.
144
How are unit tests utilised by developers?
=> As part of an automated quality assurance for the code, ensuring that by changing one part of the system, other parts will not break.
=> Ideally run as often as possible; dependant on the complexity of the system, the number of tests to perform, and the speed of the tests.
145
What is 'black box testing'?
=> Tester has no knowledge of the code.
| => Program tested based on the requirements of the specification.
146
What happens during 'black box testing'?
=> Valid, invalid and extreme input data is taken and compared to the expected output, based on the design and requirements specification.
=> The test is passed if the outcome is what was expected.
147
What is the purpose of 'black box testing'?
=> The purpose is to find out whether the code does what it is supposed to do.
=> The purpose isn't to find out which paths we're following to get the result.
148
How is 'black box testing' conducted?
=> Commonly conducted by people who were not directly involved in development.
=> Carried out in a very systematic manner.
149
What is a test script?
=> Used by testers and enables them to test every element of a system.
=> Allows tests to be reproduced.
=> If a test fails, the developer will need to be able to reproduce the bug in order to fix it.
150
What occurs during alpha testing?
=> Alpha build of the software.
=> Alpha builds tend to be unstable, may lack functionality, and may not even work in all circumstances.
=> Carried out by the developer or by an in-house testing team.
151
Why is it important that an alpha build of a software is not given to the customer or users?
They may feel that this is the level of quality they will get once the system is complete.
152
What are beta builds of a software?
=> More completed versions of the software than the alpha version.
=> More stable than alpha builds since all of the main functionality has already been tested, but may contain bugs and problems.
=> Stable enough versions to be sent out to the customer for beta-testing.
=> Created later on in the development cycle.
153
How does a customer carry out beta testing?
=> As if they were using the code in a live situation.
| => Any faults that they find are fed back to the development team.
154
What is 'end user testing'?
=> The last testing phase.
=> Occurs before the customer agrees to pay for the final system.
=> System is tested by the end user, using real data.
155
What is the goal of 'end user testing'?
=> To ensure that what the developer has produced meets the requirements specification.
=> For the developer to prove that they have met the requirements so that they can be paid.
156
What documents are produced during a software's development cycle?
Documents are produced during development including: design documents, diagrams and the requirements specification (these are all internal documents that are mainly of interest to the company).
157
What is the purpose of the design phase?
Focuses on documentation for the customer and end user.
158
What is the role of technical authors?
Write user documents, working alongside the developers and utilising the same documents, particularly the requirements specification.
159
What concerns exist when writing documentation?
=> Writing documentation isn't easy.
=> Documentation needs to occur in parallel with software development to ensure that both are completed at the same time.
=> Needs to be planned, designed and tested.
=> Normally at least two rounds of commenting before final versions are ready.
160
What is the purpose of user documentation?
=> To train users to use a system and an accompanying manual.
=> To fully document the system for use after the training is completed.
=> Used by users who start using the system some time after its launch.
161
How should user documentation be created?
=> Should be carefully targeted towards readers and their needs.
=> Should be suitable for a novice user; straight forward and avoids technical terms.
=> User should be able to find out how to perform any task by consulting the document.
162
What should the user document include (all or most of)?
=> Step-by-step 'getting started' guides/tutorials for the main features of the system.
=> Installation guide.
=> User guide focusing on user tasks.
=> Reference manual.
=> Online help, at the level of both individual controls (such as input fields), and at the task level.
=> Error messages and troubleshooting guide.
=> FAQs details common questions and problems.
=> Glossary.
