This is a guide for students attempting Software Engineering in digital technologies achievement standard 3.44. This guide is not official, although we intend for it to be helpful, and welcome any feedback.
In order to fully cover the standard, you will also need to have done a project in one other 3.44 topic. The other project should be in either Complexity and Tractability, Artificial Intelligence, Formal Languages, Network Protocols, or Graphics and Visual Computing.
Additional Information: Required skills and preparation for this project
For this project, students will need to interview somebody from the software engineering industry about what software methodologies (Agile and Waterfall) their company uses. It would be best to pick a company that uses Agile (which is now very common). They will also need a couple of examples of projects they have done themselves: one where they used an Agile approach, and one where they used a Waterfall approach. The projects could either be ones they do this year, or ones they have done in the past.
The teacher should arrange for the class to visit a local software company where there is a software engineer they can interview, or for a software engineer to visit the class. The students should prepare “interview” questions before the visit, to ask the software engineer in order to get the information they need to complete their report.
The student's Waterfall project to use as an example need not be in computing; in other technology classes, such as hard materials, students might have used a waterfall process where they had to do analysis/requirements gathering, then design, and then implementation (building) in that order, without being able to easily go back to the previous step. Some students naturally carry this process over to digital technologies, and they may have even used it in 1.45/1.46 and 2.45/2.46.
To get an example of an Agile project the student did: some of the level 3 digital technology standards, such as 3.46 or 3.43, give students an excellent opportunity to put agile processes into practice. If they were to approach these standards using a Waterfall approach (by trying to design their entire project and then implementing their entire project, and then testing their entire project), they would be risking wasting a lot of time unnecessarily or completely failing at them when something takes longer than expected or doesn’t go as planned. Instead, it is far better to work in small increments, designing and then implementing small pieces of functionality so that they always have something that works that they can show to their teacher. It is possible they are already using Agile processes in this way without realising it.
By including both a real world project a software engineer told them about and some of their own projects, students will be able to both consider the real world issues, and have a deeper personalised understanding of the issues than if they were only told about them by the software engineer. This approach to the standard seems to have worked well for students in the past.
Students who chose this project for 3.44 will need to have the following skills (keep this in mind when picking projects, because different projects require different main skills):
- Good written communication: While all of 3.44 requires students to write well, it is most important in this topic because all the ideas are presented in writing, and their report for software engineering will be around 3 to 4 pages of solid text (others, particularly tractability and formal languages, have more room for expressing information in diagrams).
- Good verbal communication: They will need to be able to get the information they need out of the software engineer they are interviewing.
- Good listening skills: They will need to be able to understand the responses to their interview questions, and explore them.
- Good note taking skills: As they will need to be able to remember the details in the information they got.
These skills are also important for software engineers, for very similar reasons. It isn’t just about programming!
In New Zealand, a convenient way to find software engineers to come to a class for an interview is through the ICT-Connect programme (http://www.ictconnect.org.nz/) or FutureInTech (their "ambassador" program: http://schools.futureintech.org.nz/forschools.cfm).
Note that a plural means “at least two” in NZQA documents. Because this is one of the two areas of computer science that the student must cover, most of the plurals effectively become singular for this project, which is half their overall report. This project will give them at least one algorithm/technique and practical application, and the other project they do will give them another of each.
- Achieved: [A1] “describing key problems that are addressed in selected areas of computer science”
- Achieved: [A2] “describing examples of practical applications of selected areas to demonstrate the use of key algorithms and/or techniques from these areas“
- Merit: [M1] “explaining how key algorithms or techniques are applied in selected areas”
- Merit: [M2] “explaining examples of practical applications of selected areas to demonstrate the use of key algorithms and/or techniques from these areas”
- Excellence: [E1] “discussing examples of practical applications of selected areas to demonstrate the use of key algorithms and/or techniques from these areas”
- Excellence: [E2] “evaluating the effectiveness of algorithms, techniques, or applications from selected areas”
The terminology in the 3.44 standard can be challenging to understand because it applies to six different areas. The following list describes how the terminology of the standard maps onto this project.
- Selected Area: Software Engineering
- Key Problem: Minimising the risk of failure when designing large and innovative software systems.
- Algorithms/ Techniques: Waterfall Process, Agile Processes
- Practical Application: Software Development
- Practical Application Examples: Experiences of a software engineer working in industry (this information is obtained by interviewing them), your own experiences using the processes.
In summary, to satisfy the standard you might do the following:
- Describe the key problems, giving some background information about why they are so important. [A1]
- Explain how Waterfall Processes and Agile processes are applied in the company/ your own work. [M1]
- Describe/ Explain/ Discuss what the company does, and how this was impacted by the agile processes. [A2, M2, E1] (and) Describe/ Explain/ Discuss how the work you have done in your own projects was impacted by Agile/Waterfall processes. [A2, M2, E1]
- Evaluate the use of Agile processes and Waterfall processes. e.g. projects done in the past that worked well with the Waterfall, what would happen if the company you interviewed used Waterfall (ask them this in the interview!), what might have happened if you had used Waterfall in some of your own projects that you used Agile in. [E2]
It is important to understand what not to include as well. Remember that you only want to write 4 pages (your total report has to be under 10 pages), and you want the marker to easily find the material that is relevant to the standard. If what you are writing is not fairly closely related to the software processes (Agile and Waterfall), it is probably not relevant to the standard.
Ideally you should read through the entire Software Engineering chapter, as it is all going to help you to improve your understanding of why Software Engineering is so challenging. Don’t worry about doing the projects (although this assessment guide is based on one of them).
This project is based on the “Software Processes” project in the CS Field Guide. Your teacher will arrange for a software engineer to visit your class or for your class to visit a local software company. In this visit, you will interview a software engineer to find out about the software development practices their company uses and how this impacts their work, in particular Agile processes. This guide assumes an agile process is used by the company interviewed, because this is generally used in large and innovative software projects - the projects that are the most challenging to bring to success. Before the interview, you need to come up with a list of interview questions which will help you to get the information that you need to complete this report.
In addition, you should also have your own experience using Agile processes (and Waterfall processes). You might have even used a form of Agile without realising it! Being able to discuss these experiences and how they were impacted by the user of Waterfall and Agile will be valuable for your report. Some ideas are: Working on a large program or website, you might have designed, implemented, and tested small parts of the functionality at a time, as opposed to trying to design your entire project, then implement it, and then test it.
In other technology projects, you might have used the Waterfall Process. For example, in hard materials technology, you would typically do analysis to get ideas, and then come up with a bunch of designs, and then pick one to actually build. In other digital technology projects, you might also have used the Waterfall Process. In some cases, this would have worked well (if the project was simple for you and you fully understood it). In other cases, you may realise that an Agile Process would have been more effective.
It makes sense to structure your report based on the 4 different bullet points in the achievement standard (note that 3 of them are step ups of each other, so are just being counted as 1 by this guide). The order in which this guide presents them is probably the best order for your report to present them. You should come up with suitable headings based on these 4 different bullet points to avoid the report being a continuous block of text!
Follow the page limit recommendations, as these will help you to ensure you have enough room in your report for everything. Your goal should be to write the best possible explanations and discussions you can within the page limits. Try to write concisely and to only include the most interesting points (you don’t need to include everything you know on the topic). Some points also have paragraph recommendations, to help prevent you writing more than you needed to.
This should ideally be no more than ½ a page long.
The kinds of things you should include are: What is the key problem you are discussing in your report? Start the first sentence of your report with “A key problem in software engineering is…”.. Also make sure you include some of the risk factors for projects failing (e.g. new ideas, size, characteristics of the engineers working on it…) This will ensure the marker can easily tick off bullet point A1. (1 paragraph is enough)
What is some motivation for being interested in the key problem? e.g, what interesting software disasters have you read about? What are the consequences of not paying attention to it? (1 paragraph, or possibly 2 short paragraphs should be enough) What company did you visit (or that visited you), and what kind of software do they make? What methodology do they use? (just 1 short paragraph is enough)
What are your own projects that you will be discussing in your report? Describe each project in one sentence, and state (without defining or justifying) whether it is your example of Agile or Waterfall. If it wasn’t purely one or the other, state what it is closest to, and you can discuss why later in your report (i.e. no details are required at this point).
This information is mostly to satisfy the first bullet point, and to convey key information to the marker about your personalised examples that your report uses.
Additional Information: This section mostly covers M1, but will help with A2
Even students that are only aiming for achieved should do this part. It will help count towards A2 as well. Note that forgetting to address this bullet point is a common reason that students who have otherwise done great work did not get excellence. They could potentially include it in the next section, although we recommend doing it explicitly here, unless they are a very good writer. Students who mix this section and the next one should be very careful that their report does satisfy all the criteria, in particular ensuring that they have clear examples of how Agile and Waterfall are put into practice (that is required for M1 and good students frequently overlook it).
We decided to put A2 in the heading despite the limit relevance to help prevent students skipping it.
This should ideally be around ½ to 1 pages long.
The point of this section is to define what the Waterfall process and Agile processes are, and give some specific examples of how Agile methodologies are actually implemented in practice, that is, what specific practices mean that the overall methodology the software engineer you interviewed is using Agile? And what practices did you use in your own project(s) that made them Agile? You don’t need to go into too much depth here, you just need to give several examples of practices, and make sure you have explained them, so that it is clear to the marker what they mean. (For example, just saying “X company does development in sprints” is not enough. You need to explain what a sprint actually is). You should also include 1 or 2 examples from one of your own Waterfall projects (e.g. the order in which you did the phases in it).
You might want to do the following:
- Explain what the Waterfall process is, and the key steps in it.
- Explain what Agile processes are, and the key steps in it, ensuring that your explanation is clear in why they are different to the Waterfall process.
- Give a list of examples of ways in which the Agile and Waterfall methods are put into practice. Each example should be something you did in one of your projects, or from what the software engineer you interviewed told you. State what the practice is, which of your example projects it is from, and explain what it means (especially where jargon is involved). Don’t go into depth about the implications, you should do this in the next section. This information for this section could safely be presented as bullet points, as long as the bullet points are each 2 to 3 full sentences.
Additional Information: An example for this section
These points could be in the form of something like “xxxx company has stand up meetings every morning. These go for xxxx minutes, and are so that everybody in the team can catch up with what each other is doing, and xxxx”. The key idea is that they are short, but long enough for the student to briefly explain, and they are personalised based on the situation they have heard about.
This should ideally be around 1 ½ to 2 ½ pages long.
In this section, you now need to pull everything together, and discuss how your example projects were impacted by whatever methodology was used. Remember that your example projects are the one that the software engineer you interviewed was working on, and a couple of the projects you have done yourself (one Agile and one Waterfall). The way you go about this is very open ended, although some key points you might like to consider when discussing each project are:
- What the project involves, and its characteristics (size, novelty, number of people involved in it, etc).
- Some examples of the Agile/ Waterfall processes in action in the projects (this is more in-depth than the previous section, where you were just trying to define what the Waterfall Process and Agile Processes actually are).
- Whether or not the process being used is effective for the project.
- What the positives of the process being used for the project are.
- What the downsides of the process being used are for the project.
- What you would do differently (with regards to Waterfall and Agile) if you were to do the project again (for the ones that are your projects).
This should ideally be around ½ to 1 page long. Remember to only include your most interesting points, and write concisely. Your goal should be to conclude your report by evaluating whether or not the Agile process addresses the key problem (go back to your first paragraph if you cannot remember what you wrote for the key problem). In addition to using the information you gained from interviewing a software engineer, you might want to do some additional reading. Some points you might consider:
- What would happen if the company you interviewed used Waterfall instead of Agile? Would they still be able to develop their software effectively? Do they consider Agile to be effective? Is there anything about Agile that still isn’t ideal for them? (The questions you ask them when you interview them will be essential for this.)
- How well does the Agile process address the key problem you outlined in your introduction?
- What shortcomings does the Agile process have? What kinds of ideas are being considered to address them?
- Are there any modifications the company you interviewed are considering to address issues in their own Agile Process?
- It is better to keep the scope of your report small, and go into depth within the small scope. There are many ideas in software engineering that you could potentially include in your report, in addition to software processes (Agile and Waterfall). Some students also talk about the details testing methodologies, implementation methodologies, requirements gathering, etc. Remember that for the standard, you only need to talk about 1 key problem per topic, and only 1 - 2 techniques for it. For this assessment guide, you should only focus on Agile processes vs the Waterfall process.
- Make sure you are focussing on the software methodologies of Agile processes and the Waterfall process. If you have an entire paragraph that has nothing to do with Agile processes or the Waterfall process, then it is probably not relevant to the project you have chosen for the standard.
- Be sure that all your explanations are centered around examples (i.e. the interview with an engineer or your own projects). Remember that you are supposed to be discussing those examples in order to demonstrate techniques, i.e. agile and waterfall.
- Be careful when using bullet points and pros vs cons lists.
- Generally, single sentence/ statement bullet points don’t work well for merit/ excellence, because you need to have explained and justified the point you have made. Simply stating facts is only “describing”. For example, when evaluating the processes, you may be tempted to have a bunch of bullet points such as “Does not work well for innovative software projects”. This statement isn’t going to help you at all - it will look like you just copied this fact from the field guide! You need to justify it, and explain why the Waterfall process does not work well for innovative software projects. Once you have done this, you will have several sentences or a paragraph.
- One exception is for an introduction or conclusion. You might say “In summary, the key points are” and then follow with a list of bullet points that summarise your key points.
The page limit for achievement standard 3.44 is 10 pages. Remember that you have to do a project on a second, different topic as well, so that leaves 5 pages for Software Engineering. We recommend aiming for 4½ pages so that if some sections go slightly over, you will still be under 10 pages overall. Also, don’t forget you will need a bibliography at the end. The page recommendations for specific sections are within the main part of the assessment guide.