fixed a spelling error, peer to pair.

second to last line:
    Would you use peer programming in the future given the chance?

to 
    Would you use pair programming in the future given the chance?
added marks.pl (it's better than Blaise's)
Update prac7checkpoints.txt

https://github.com/leed0019/se3prac3
For all whitebox tests please refer to test.c and there is a sample output provided in whiteBoxOutput
Merge pull request #148 from leed0019/patch-6

Update prac7checkpoints.txt
Update prac3checkpoints.txt
Update prac8checkpoints.txt
Update prac3checkpoints.txt
Update prac5checkpoints.txt
Update prac5checkpoints.txt
Update prac4checkpoints.txt
Update prac6checkpoints.txt
Merge pull request #160 from nort0100/master

Added Prac8 nort0100
Update prac9checkpoints.txt
add grade for vald0002
Update prac8checkpoints.txt
Update prac6checkpoints.txt
Update prac5checkpoints.txt
Added checkpoint 8 for jora0003

Pair programming strategy works when there are two developer/coder works on same work station. One is driver and one is observer. Driver is the usually a coder and drives the keyboard and coding. Observer is the person who is observes the driver and gives his feedback or observes the issues in the code.
Programming experience in pair programming was new for me but I liked it because it has given benefits over single programming…
1-	I had to pay more attention during working hours of programming because my partner programmer was observing my work.
2-	At the end of the programming session I found less bugs as instead of me verifying the output and logic, there was another mind involved to find the possible bugs.
3-	The code base was more accurate and precise as I found other shorter ways of achieving the same result. It gave me experience how other concept can be implemented in programming.
4-	It also gave benefit to my pair partner with knowledge and experience sharing.
5-	Overall development timing reduced by quickly finishing the code. Pair programming also saved time during bug fixing because there were few bugs present at the time of program execution.
6-	I concluded that pair programming helped in team building and resolving problems quickly.
Apart from benefit of pair programming I found following issues in pair programming…
1-	Pair programming stressed me as my partner observing me all the time so it gave me little personal space to free up my mind.
2-	Although there were less bugs left at the end of programming session I believe pair programming is not worth if the programmer is experienced and tackles the situation before it arrives.
3-	The total time given by both of us was not worth of the program we have developed. It may have been more beneficial if the program would have been complex nature.
The following things worked well in pair programming
1-	Easy and multiple solution for the complex problem because there were two minds working for the same problem
2-	Faster problem solving approach
3-	Experience sharing and less bugs
Following things I would like to change next time when I do pair programming
1-	Think of a goal and make an strategy before diving directly into the coding because I found most of the time wasted during code was finding logic of the program
2-	Documenting the problem during discussion so both can be on same page rather arguing at the time of coding
If I compare the benefits of pair programming then it is worth if we are trying to resolve complex problem. The nature of code can go wrong once developer lose focus on the logic. Pair programming gives opportunity to the second programmer to dive into the scene and provide his/her valuable feedback if something is going wrong. At the end of the day both has to achieve the accurate result.
Update prac10checkpoints.txt
Merge pull request #173 from jora0003/patch-7

Added checkpoint 8 for jora0003