Analysis Guidelines
Expectations and mark scheme, expectations.
You are expected to:
Clearly identify and describe the problem or investigation that is being used for your NEA project
U se a range of appropriate methods and sources to research and investigate the problem, including websites, existing software, books, interviews, questionnaires, prototyping. Relevant and genuine evidence should be presented in the report (most likely in an appendix, but referenced in the main report)
Identifying a third party: It will be useful if a third party (that is someone other than the student) is involved in the analysis process. The third party might be a potential end-user of the software, such as a friend, relative, employee or teacher or somebody with knowledge, interest or expertise in the problem area. Their role is to support the student in investigating the problem, deciding upon the objectives and to give feedback, particularly at the end of the project. Y ou will need to initialise communications with your third party and as a minimum you should have a conversation with them about your project and use a questionnaire to get their input before writing your objectives.
Create a set of objectives or aims for the system that contain the following features:
Cover all functionality of the solution or areas of investigation
Include requirements based on the dialogue with the intended users of the system or supervisor for investigative projects
Further research and prototyping to refine the set of objectives
Prototyping the critical path at the analysis stage, early in the project development period, is encouraged so that changing objectives later on occurs only in exceptional circumstances, and with the agreement of the teacher. The achievement of the objectives will have an effect on determining the mark awarded for the coding of the project. This refining/adjusting objectives will be cut off by the end of first term.
Include modelling, diagrams or formulae that will inform the Design section.
A fully scoped analysis is one that has:
researched the problem thoroughly
has clearly defined the problem being solved/investigated
omitted nothing that is relevant to subsequent stages
statements of objectives which clearly and unambiguously identify the scope of the project
modeled the problem for the Design stage where this is possible and necessary.
Mark Scheme
Analysis (9 marks)
The Problem
You need to clearly state the problem you are looking to solve. Defining the problem at the start is key to a good project. If you are not sure what you are trying to solve, then issues will be encountered later. For instance, it will be very difficult to create objectives that are specific and measurable if you are not clear about the problem.
You will need to create a clear statement of the problem, the challenges that may be faced and a broad idea of what the system will do. You will need to think about whether the problem will be too big or too small. Will it offer enough scope to meet the marking criteria for the project? In particular, will the problem allow enough technical skills to be used to be of an A Level standard and access the Group A technical skills?
A smaller well completed project will often score as well as a larger project that may have encountered problems along the way, leaving it not fully functional.
Third Parties
You will need to identify one or more third parties to be involved with the analysis of your problem. It is likely that this will be an end-user of the system.
Some projects may have a named end-user who has been part of the project decision process, but some projects that are created are more general like the creation of a chess game AI which could use friends, family or people that plays chess regularly as the end-users involved in the Analysis section.
If you are carrying out an investigation you would probably use your supervisor as the third party for the Analysis.
It is important to research the problem you aim to solve thoroughly. All projects should use research to help guide and support the requirements of the solution which will be listed in the set of objectives created.
Discussions with your end-user(s) or supervisor will need to be undertaken to show the needs of the intended users of the system.
You do not need to undertake all of the following types of research, but you should focus on those which are most appropriate to the project that you are completing.
Qualitative and Quantitative Research
Qualitative Research is primarily exploratory research. It is used to gain an understanding of underlying reasons, opinions, and motivations. It provides insights into the problem or helps to develop ideas or hypotheses for potential quantitative research. Qualitative Research is also used to uncover trends in thought and opinions, and dive deeper into the problem. Qualitative data collection methods vary using unstructured or semi-structured techniques. Some common methods include focus groups (group discussions), individual interviews, and participation/observations. The sample size is typically small, and respondents are selected to fulfill a given quota.
Quantitative Research is used to quantify the problem by way of generating numerical data or data that can be transformed into usable statistics. It is used to quantify attitudes, opinions, behaviors, and other defined variables – and generalize results from a larger sample population. Quantitative Research uses measurable data to formulate facts and uncover patterns in research. Quantitative data collection methods are much more structured than Qualitative data collection methods. Quantitative data collection methods include various forms of surveys – online surveys, paper surveys , mobile surveys and kiosk surveys, face-to-face interviews, telephone interviews, longitudinal studies, website interceptors, online polls, and systematic observations.
Research Other Solutions
Analysing other solutions and software that are similar to what you intend to create is a great way to get ideas about how the problem could be solved. You could show your end-user these solutions and get feedback to help determine what your end user requires of their solution.
When evidencing the research from other solutions, it is possible to include screenshots , diagrams or explanations of the solution. In some cases it may be appropriate to then add comments about what you do and don't like. This along with the comments from your end-user should inform the objectives created during the analysis.
You might believe that your idea is unique and that there are no other comparable systems that exist. If this is the case you should find systems that are as similar as possible or look at components from other solutions that solve parts of your own.
You will find that meeting your end-user will have a number of benefits during the analysis section of your project, but you also need to be avoid the drawbacks that can also happen.
Balancing whether to meet the end-user(s) or not depends on many considerations. You may decide to meet with your end-user to have an initial meeting to discuss your idea and then put together a survey/questionnaire to finalise your plans.
Remember that a key part of the analysis is having a dialogue with your end-user(s) or supervisor. This does not have to be through a face to face meeting and you may find that engaging in this dialogue via email, phone calls or other online form of communication may be easier for you to organise.
Surveys/Questionnaires
Surveys/Questionnaires are a way of collecting data without needing to be present. They can be created quickly and are easy to send out, but you need to be careful when designing your survey/questionnaire.
Electronic surveys/questionnaires are a very effective way of collecting data from a large number of people. Using this method to gather data also means that the questions that have been asked will be the same for everyone.
Prototyping
Prototyping is used when your initial idea is formed, but the requirements are very vague and undefined, Prototyping allows you to build short and quick examples that can be evaluated and refined as you proceed through your project. This may lead to an iterative design that can be developed and then re-evaluated as time passes.
The prototype created should inform on the development of your objectives and a well put together prototype will allow you to develop parts of your final solution testing to see if they work as expected.
Modelling of the Problem
There are times when you may find the creation of models, diagrams or formulae that are key to the problem a good way of conveying your problem and possible solutions in your project. These models are likely to be the same sort of models that you may be creating for the design section, but you might find that if they directly relate to, or help the understanding of the problem, then they should be included at this point.
Project Objectives
The set of objectives you create define the requirements for the rest off the project. Each objective should have some sort of research to support its inclusion in your project. One way to show the research supports inclusion is to make a note as you do the research. For example when you have a meeting with your end-user you should write the key points into your objectives.
You will need to number each of your objectives and this will enable you to reference this later in your project. It is useful if each objective references the research that is related to its inclusion.
The best way to create your objectives is to to start with the most important ones and then break them down into smaller objectives. Eventually each of those objectives should become a small measurable objective, which is some cases will lend itself quite nicely to a subroutine.
The following is an extract from a set of objectives for a website that allows parents to book parents' evening appointments.
Your commentary throughout your report should take both your teacher and the moderator through the journey to reach your final solution. It is not a specific section but runs through the whole project. Commentaries are written explanations of what, when and why you are doing something.
Quality is more important than quantity so be concise and don't write more than you need to.
Commentary for the analysis should show how you have gone from your initial idea, researched it, discussed it with your end-user of supervisor, and reached your final decision for the solution.
Write Up Your Analysis
Structure and c ontent.
Required documentation for ‘Analysis’: this section of the report should include:
a clear statement that describes the problem area and the specific problem being solved / investigated
an outline of how the problem was researched
a statement indicating who the problem is being solved / investigated for
background in sufficient detail for a third party to understand the problem being solved / investigated
a numbered list of measurable, "appropriate" specific objectives, covering all required functionality of the solution or areas of investigation (‘appropriate’ means the specific objectives are single purpose and at a level of detail that is without ambiguity)
any modelling of the problem that will inform the Design stage, for example a graph / network model of Facebook connections or an E-R model, state diagrams, scientific / mathematical models or formulae, data flow diagrams.
The setting of well-defined, appropriate objectives is the most important part of the analysis, as these objectives will eventually be used to assess the success of the project and award marks to the solution produced.
Create a clear description of the problem being solved/investigation.
Identify the end-users/supervisor that will be used during your project.
Research products/software for similar problems (if appropriate for your project)
Research relevant websites and books (if appropriate for your project)
Carry out interviews, discussions, communication or dialogue with your end-users/supervisor
Carry out surveys/questionnaires with end-users(s) or other third parties (if appropriate for your project)
Make prototypes of key/critical areas (if appropriate for your project)
Make sure you have included enough detail to make sure a third party would understand the problem being solved or investigation.
Add models/diagrams/formulae that can be used to inform the design section.
Create a list of numbered objectives which are specific, measurable and cover all required functionality of the solution/area of investigation.
Ada Computer Science
You need to enable JavaScript to access Ada Computer Science.
IMAGES
VIDEO