Aspects of software development

Quick links

3.8.1

Aspects of software development

 

Useful
links

Syllabus content

Content   Additional Information

Design
Be aware that before constructing a solution, the solution should be designed, for example planning data structures for the data model, designing algorithms, designing an appropriate modular structure for the solution and designing the user interface.

 

 

Students should have sufficient experience of successfully structuring programs into modular parts with clear documented interfaces to enable them to design appropriate modular structures for solutions.
Students should have sufficient experience of successfully including authentication and data validation systems within their computer programs.

Implementation
Be aware that the models and algorithms need to be implemented in the form of data structures and code (instructions) that a computer can understand.
  Students should have sufficient practice of writing, debugging and testing programs to enable them to develop the skills to articulate how programs work and argue using logical reasoning for the correctness of programs in solving specified problems
     
Testing
Be aware that the implementation must be tested for the presence of errors, using selected test data covering normal (typical), boundary (extreme) and erroneous data.
  Students should have practical experience of designing and applying test data, normal, boundary and erroneous to the testing of programs so that they are familiar with these test data types and the purpose of testing.
     
Evaluation/refining
Be aware that code created during implementation will often require refining as a result of testing.
Be aware of the importance of assessing how well the solution meets the requirements of the problem and how the solution could be improved if the problem were to be revisited.
  Students should have practical experience of refining programs in response to testing outcomes.
Students should have practical experience of assessing how well their solutions meet the original requirements of the problem.
Students should have practical experience of explaining how a solution could be improved if the problem were to be revisited.

Important

While it is possible that the examiner may include questions on this section in the terminal examination, this are is primarily assessed through the coursework (The NEA activity).

The development life cycle

While it is possible that the examiner may include questions on this section in the terminal examination, this are is primarily assessed through the coursework (The NEA activity).

Sixth form notes from Unit 06 LO1

Task. Create a spider diagram in Visio to show the main phases of the SDLC. While Waterfall is the most common when describing a model, which model do most students tend to follow without knowing they are doing so? The prototyping model.

Add notes to your diagram to explain where and why you would add documentation to your project.

Design

Be aware that before constructing a solution,  the solution should be designed, for example  planning data structures for the data model,  designing algorithms, designing an appropriate  modular structure for the solution and designing  the user interface.

There are a number of issues to consider when looking at the design process. Firstly, what evidence of theory is required in your practical work? (i.e. how do I get most marks even if I am not too sure how to solve the problem?) Secondly, how do I present this evidence so as to maximise my mark? Thirdly, how do I create a suitable design making sure that all of the elements that the examiner wishes to see are included? Fourthly and finally, how do I do all of this quickly enough so that I can move on to phase 2 whilst getting many of the marks for phase 1?

Firstly, looking at the guidance in the syllabus it is clear that the emphasis is on a modular structure and a user interface. This implies the use of decomposition to work out if the problem can be broken down into a series of smaller problems that can either be solved or further subdivided until you have a series of connected problems, all of which can be solved that come together to make a workable solution. Possibly. At this point your solution is not in code and need not work, it is your idea. As long as you have shown some decomposition in your solution and have shown a modular arrangement that you think will lead to a solution than you will be on the right lines.

Secondly, you can show your solution in a diagram; either blocks connected by lines or a spider diagram will be fine. There is no need to draw a flowchart or write code at this stage. For example, using the Card Trick Task as an example, this diagram although not perfect and not necessarily a complete solution would enable a candidate to be able to show decomposition.

It shows that the candidate has taken the original task, a card trick using 21 cards and has clearly identified that the solution is made of a number of smaller problems each of which will need a solution. This is deliberately not a complete solution but it clearly demonstrates that a difficult problem can be broken down into a number of smaller problems that may or may not have a solution.

Task: Use the Card Trick Task documentation and this diagram as a starting point and using Word, create a better diagram. You may wish to show the stages of development of your solution - this would be a great idea! Make sure that you add notes to your diagram to explain in your own words why you subdivided a task into a series of two or more subtasks.

The next aspect would be to document the user interface, what the user will actually see on the screen. How could this be documented?

A design such as this would be fine.

This is a mock-up of what you want to put on the screen.

You would now annotate your diagram to show which interface designs would appear where in the design. Even if you find coding difficult, this you can do.

The last part of the design is to add authentication and validation to the design. Authentication would be for passwords so a loop back to the authentication block if the password is incorrect for example. Validation means making sure that the computer knows that the values being entered are sensible. For example, the only sensible range of answers when asked to choose a pile is either 1 or 2 or 3. There are notes in the python guide on how to do this but for the design just add a note to say that validation takes place where and what sort it is.

You now have a design. It might not be the best possible solution and you might not have a clue as to how it can be made in Python, but you will have marks in your coursework and you will have a basis upon which to build your solution.

Task: Add interfaces and validation to your design.

You will require a table of all of the data structures that you use in your program. This will grow as you work through the program. You must add each new variable or data structure to your list as you create it.

Implementation

Be aware that the models and algorithms need to be implemented in the form of data structures and code (instructions) that a computer can understand.

Once you have a design broken into a number of algorithms or sections you must do your best to try and make those pieces work. I know at this point most of you are making it plain that you cannot do this but you can still try.

Here is my first attempt at the interface that is required.

... and here is the result of the code.

At this point you have run some code so this is a test. Every time you try something out it is in effect a test. Look at the testing section to see how the first test should look.

The next step would be to change the print statement to be an input statement so that Python asks the user a question: "While pile is your card in?"

In order for this to work I need a variable to store the answer the the user gives. Choice is a sensible name for such a variable. At this point I should go back to my design and add "Choice" to my list of variables.

Next I should test the code.

It works ...

... in that there are no errors but it does not do what I want. Do you see the error that I have made?

There is a section in the Python Guide that will help you work this out; section 6. Data entered using input is always a string data type, but is this what I want? This will solve itself later.

An even bigger mistake is I have not shown the three piles of cards so the user has nothing from which to pick. In Python the \t is used for tab, a good way of lining text items up.

This works as intended. You will have noted (I hope) that I have done the third box in my design.

Now I have to make sure that the user can only give the answer, 1, 2 or 3.

Section 14 in the Python Guide shows you how to make a menu and explains the technique in some detail...

If you read chapter 14 you will see how to make the code more robust and to add in error checking.

So incorporating the ideas from Chapters 14 and 15 I get...

... which I can now test using the criteria for testing an input value, normal (typical), boundary (extreme) and erroneous data. The testing document now looks like this. Note that there has been at least one retest of something that did not go to plan.

In the slice of code shown below is another way of introducing a range check. Set the value at the start to be outside the range, so in this case answer = 0 and then use a while statement to make sure that the question is repeated until the user submits and answer in the correct range, 1, 2 or 3.

Adding a type check (i.e. making sure that the user types in a number and not a string value or a real such as 1.2) makes the program even better.

How are the cards dealt every time so that the right cards get to the right place and "magic" happens? This animation shows (slowly) how the cards are dealt from one set of three piles to another. I have given the first pack of cards the variable name "pack_of_cards" and the second set the name "temp_pack". Each is a 21 element array.

Content on this page requires a newer version of Adobe Flash Player.

Get Adobe Flash player

It is possible to write a section of clever code that can do this or you can use a brute force method such as this. (It is green because I have made it into a comment so it is ignored in my program.)

I agree that this is not "elegant code" but it works; which is more important?

The number in the square bracket is the index value of the item in the array. So, pack_of_cards[0] has the value "3 of diamonds" and so on.

So now I can show the first interface (a design and a few print statements) and I can move cards between piles. How do I shuffle the pack? This uses random numbers so you will need to have the "random" library included at the start of the program. Again you can use the Python Guide to explain a little more. We are using a reduced pack of 21 cards but the process for shuffling remains the same however many cards are involved. Google "how to shuffle cards in python" and see how many results you will find.

Here is my solution:

The issue to solve is that there has to be a third, temporary value to store one of the two items that you are swapping.

In the diagram below, (1) the value of A is stored in Temp - this writes over whatever used to be in temp, then (2) the value of B is stored in A which writes over whatever used to be in A but I don't mind as the original A value is currently in Temp and then (3) the value of Temp is stored in B writing over whatever was stored in B but that value is already in A so I don't mind.

In order to know which two cards to swap I use the random number generator random.randint(0,20) which gives a randomly selected whole number between 0 and 20.

If I do this once I will have a pack of cards where two cards are not where they started, so to shuffle the whole pack repeating this about 100 times should be sufficient.

This is all well and good sir, but how do I create the pack of cards in python in the first place? Again this is a little bit of a brute force approach but it works and would give you access to all the marks.

The temp_pack assignment at the bottom is how you make an empty array of 21 spaces.

Testing

Be aware that the implementation must be tested for the presence of errors, using selected test data covering normal (typical), boundary (extreme) and erroneous data.

You should show the testing in a 5 column table (orient the page to be landscape to give yourself more room).

Firstly, number the tests. Then describe each test in as much detail as you can. Then clearly state what you think the expected outcome should be. Then show a screenshot of the actual outcome. Finally for each test show what needs to be changed (if anything).

When using test data for a variable such as "Choice" you must use test data "covering normal (typical), boundary (extreme) and erroneous data". So you should use normal data (1, 2 or 3), boundary data (1 or 3) as well as data just outside the boundary (0 and 4) and erroneous data such as a letter (z or t)

 

Evaluation / refining

Be aware that code created during implementation will often require refining as a result of testing.
Be aware of the importance of assessing how well the solution meets the requirements of the problem and how the solution could be improved if the problem were to be revisited.

The question here is "how can you extend or develop the program so that it does more than the original brief?" Finishing the task is not a refinement, but as you do not have to make changes to your program for this section, this is not an issue. One change that could be made is to make the "magic" work for a full pack of 52 cards. What would you have to do to the program to make this possible? Could you improve the interface in some way? Use Notepad to make a mock-up of what it might look like. Is there a way of adding colour? Could this be done as a series of inages so that the cards appear to be dealt? All of these are possible and none have to be coded.

Marking

The project is marked using the following 5 headings

Section Criteria Maximum marks
1 Designing the solution 9
2 Creating the solution 30
3 Testing the solution 21
4 Potential enhancements and refinements 10
5 Overall quality of the report 10
  Total 80

 

 

3.1 Fundamentals of algorithms

3.2 Programming

3.3 Fundamentals of data representation

3.4 Computer systems

3.5 Fundamentals of computer networks

3.6 Fundamentals of cyber security

3.7 Ethical, legal and environmental impacts of digital technology on wider society, including issues of privacy

3.8 Aspects of software development

Glossary and other links

Glossary of computing terms.

AQA 8520: The 2016 syllabus

General content

3.8.1 NEA assessment

3.8.1 NEA guideance

Outwood (Students first) NEA python

Pythom crash course cheat sheets

GCSE Computer Science(9-1): NEA Preparations