I wanted to have the assignment done in 3 days.

This is an individual project, so the program and accompanying report must be produced by yourself (see Section 6).

After the completion and submission of your project, you will be required to give a 10-minute live demonstration of your program to a module tutor (see Section 1.4).

1.1 S ubm is sio n R eq uir e m en ts Y ou should gather all of the files required to build and run your program into a ZIP archive. If you have used V isual Studio as your development environment, then the simplest way to submit your files is to create a ZIP archive of the entire V isual Studio project folder. You should not submit any machine code, so please 'clean' your V isual Studio project before creating the ZIP archive.

Your report should include a title page, and, if you have any references, a reference list. The length of the report should be between 1500 and 2500 words, excluding the title page and any references. Do not include a copy of your C# code in the report. Y ou should also complete a  Declaration of Authorship form. You should submit the following to the NOW dropbox folder: 1. A ZIP ar chive containing all of the files needed to build and run your program. 2. A PDF document containing your report. 3. A text file containing your  Declaration of Authorship form. The project demonstrations will be held after the project submission deadline. Y ou will be contacted regarding the specific time and date of your demonstration.

1.2 P ro gra m R eq uir e m en ts Y ou are required to produce a C# console application. Y ou are free to choose the nature of the application, and its specific functionality. The application is not expected to be complete or detailed enough for real-world use — the purpose of this assessment is just to exhibit the extent of your software engineering abilities. Attempting an ambitious challenging application but then only partially completing the application is fine for this project; you will be assessed on the functionality completed, not penalised for any missing parts of the application. See Section 3 for advice and suggestions regarding application ideas.

Your C# program that implements the application should exhibit your skill in decomposing problems, and in selecting and using appropriate C# language features and library components to implement solutions to those problems. The application functionality should be complex enough that using all of the following programming-language concepts would be appropriate for a high-quality software implementation: Console input and output Variables for storing data at run-time Conditional branching Repetition using loops (or recursive functions) Functions and/or methods File input and output Sequential data structures (arrays or lists) and/or dictionaries User -defined structs or classes To achieve the highest possible grade, the application functionality should also: Not have errors for valid inputs.

Make clear to the user what inputs are expected. 11/23/2020 02 Assessment Brief 1.html file:///Users/venkatagovindu/Downloads/02 Assessment Brief 1.html 2/8 Be robust against invalid inputs (errors in console or file input, missing input files).

Not have arbitrary or unnecessary limits on the amount of data (e.g. limited to 10 customers).

Load input data from text file(s).

Load configuration settings from text file(s).

Use serialisation to save and load the program state between program runs.

If the program is a data-processing application, then allow searching and sorting of the data.

Solve problems dif ferent to those covered in the module programming exercises.

Require the use of C# language features and standard-library components beyond those taught. See Section 2 for the details of the assessment criteria. If you have any uncertainty about what is required, or have an application idea but are not sure whether it is of suitable complexity , then please ask a module tutor for guidance.

The majority of your submitted program code is required to be your own original work. However , a minority of the program may consist of code reused/adapted from other sources. This is fine, provided that the source is correctly acknowledged. See Section 6 for the requirements regarding acknowledgement.

1.3 R ep ort R eq uir e m en ts Y ou are required to produce a reflective report in which you evaluate your development process, the strengths and weaknesses of your final program, and what you have learned from the project. Note that you ar e not being asked to document the design, functionality , or testing of the program, nor to provide a user manual.

Specifically, your report should cover the following topics: 1. Describe the approach that you took to developing the program. Evaluate what went well and what went badly with this approach. Explain and justify what you would change about this approach if you were to develop another C# console application.  (E.g. Did you design the whole program in advance, or did you incrementally design and implement features? Did you write pseudo-code or a control-flow diagram before C# code? Did you implement a prototype? Did you adapt existing code or write everything from scratch? How did you test the program?) 2. Explain any significant problems encountered, and how you resolved them. Also explain any unsolved problems, including issues that are causing errors in your submitted program. 3. Evaluate the quality of your program code, identifying both strengths and weaknesses, and noting the main ways in which the quality could be improved. 1.4 D em on str a tio n R eq uir e m en ts Y ou are required to give a live demonstration of your program running, during which you should demonstrate the program's functionality (including how the program copes with erroneous input, if applicable). Y ou should be prepared to answer questions about your C# code, and how it provides the program functionality.

2. Assessment Criteria You will be assessed on: the complexity of the functionality that your program provides; the quality of your program code; the awareness and insight conveyed by your report. The detailed criteria for each of these aspects are listed in the grade grids below . (For conciseness, the grids use some technical terminology in places. Refer to the Technical Glossary for any unfamiliar terminology .) Note that there is no credit just for having any particular pr ogramming-language feature present in your code. Rather , you earn credit for the functionality provided. The code-quality criteria will assess whether you have used appropriate language features and library components to provide that functionality . Having language features or library components present in your code that do not serve a useful purpose will be detrimental to your code-quality grade.

If any code in your program was reused/adapted from pre-existing code, then it should have an accompanying reference to the original code. Reused/adapted code will not earn credit for its functionality directly , but will earn credit for the skills you have shown in adapting that code to the requirements of your application. See Section 6 for the requirements regarding referencing. 11/23/2020 02 Assessment Brief 1.html file:///Users/venkatagovindu/Downloads/02 Assessment Brief 1.html 3/8 The report is a piece of reflective writing. Credit is earned for conveying what you have learned about software development, and for showing awareness of the quality of the program code that you have produced. No credit is awarded for describing the design or functionality of the application.

There is no grade for the demonstration itself, but attending the demonstration is compulsory , and a zero grade will be awarded for program functionality if you do not attend. You will not r eceive credit for any code that that you ar e unable to explain during the demonstration.

Pro gra m F unctio n alit y ( 5 0% o f p ro je ct g ra d e) Criteria Distinction Commendation Pass Fail Zer o Decomposing Problems Challenging domain-specific problems solved, of greater complexity than the programming exercises. Problems solved of similar complexity to the 'Advanced' programming exercises. Problems solved of similar complexity to the 'Core' programming exercises. Problems solved of less complexity than many of the 'Core' programming exercises. No problems solved. Contr ol-flow Nested definite and indefinite repetition, and branching. Definite and indefinite repetition, and branching. Repetition and branching. Branching only . Limited to linear control- flow. Input/output Loading of configuration settings from user-friendly configuration files. Loading and processing of input data from text files and console, with user - friendly console output. Saving and loading complete program state between runs using serialisation. Loading of configuration settings or input data from text files. Processing input data from console input, with user- friendly console output. Saving and loading some information between program runs using serialisation. Writing output to text files and console.

Some processing of console input. No file usage. Some console input or output, but no processing of console input. No program input or output. Data Handling Arbitrarily sized homogeneous collections of compound heterogeneous data OR two- dimensional data structures.

Sorting, searching and updating of data. Unnecessarily size-restricted homogeneous collections of compound heterogeneous data. Some searching and updating of data. Homogeneous collections of primitive data. A small finite amount of data. No data processed. 11/23/2020 02 Assessment Brief 1.html file:///Users/venkatagovindu/Downloads/02 Assessment Brief 1.html 4/8 Criteria Distinction Commendation Pass Fail Zer o Robustness No run-time errors for valid and invalid inputs, including console input and missing/corrupt input files. No run-time errors for valid inputs. Almost all invalid console input is handled without run-time errors. Mostly free of run- time errors for valid inputs, except for unusual inputs/circumstances.

Invalid console input may cause numerous run-time errors. Run-time errors occur for typical valid inputs/circumstances. Run-time errors occur for all inputs. Cod e Q ualit y ( 3 0% o f p ro je ct g ra d e) Criteria Distinction Commendation Pass Fail Zer o Readability Consistent and clear layout; well- chosen indicative names. Layout is mostly consistent and clear , with minor aspects for improvement.

Most names are indicative of their role. Layout is fair, but with some aspects that could be substantially improved. Some fair attempts at indicative names, though with substantial scope for improvement. Small amounts of redundant code. Layout is poor. Most variable names do not indicate their role in the program.

Substantial amounts of redundant code. Code not comprehensible to a typical software engineer without reformatting. Maintainability All program constants named, with no magic numbers/strings.

Only minor duplication of identical or similar code. Code directly and concisely solves problems with well-chosen language features and library components consistently throughout. Most program constants are named, but a few magic numbers/strings.

Some missed opportunities to introduce and reuse functions, but otherwise only minor duplication of identical or similar code. Code consistently solves problems using appropriate language features, but could be made more concise/direct in several ways. A fair attempt at naming program constants, but at least half are magic numbers/strings. A substantial number of missed opportunities to introduce and reuse functions OR some missed opportunities to introduce and reuse procedures.

Code is unhelpfully verbose and/or sometimes uses inappropriate language features and library components. Uses workarounds and/or placeholder values to compensate for poor structure or inappropriate features/components. Almost all program constants are unnamed.

Some missed opportunities to introduce loops to combine repetitive code. Code is convoluted, often doing substantial unnecessary work, using inappropriate language features and library components, or accomplishing results 'by accident'. No naming of program constants. No use of functions/procedures/methods or loops to combine repetitive code. 11/23/2020 02 Assessment Brief 1.html file:///Users/venkatagovindu/Downloads/02 Assessment Brief 1.html 5/8 Criteria Distinction Commendation Pass Fail Zer o Modularity Consistent organisation of code into multiple classes and numerous small functions/methods.

Appropriate use of objects and parameters rather than global/static variables. Consistent organisation of code into numerous logical functions/methods, though some may be quite lar ge and could be further broken down. Appropriate use of parameters for communication rather than global variables. Several appropriate functions/methods introduced, but the majority of the program logic is in large monolithic blocks. The executable program code is in a single Main procedure OR reliance on inappropriate global variable use. All code is in a single Main procedure, with no other functions/procedures or structs/classes defined. Reusability Classes provide a simple interface to objects, encapsulating more complex internals.

Functions created that typically have at most 3 parameters (methods at most 2), and do not use reference parameters for value types. Classes provide objects with private fields and public constructors/methods.

Functions/methods created that do not use reference parameters for value types. Classes/structs provide constructors.

Functions/methods created. Any functions, constructors or methods present are copies of examples. No classes, functions or procedures defined. Language and Library Use Appropriate use of numerous C# language features and library components beyond those taught. Appropriate use of some C# language features or library components beyond those taught. Appropriate use of most of the taught C# language features and library components. Several missed opportunities to use taught C# language features and library components. Mathematical expressions only — no valid use of C# language features. Rep ort ( 2 0% o f p ro je ct g ra d e) Criteria Distinction Commendation Pass Fail Zer o Software Development Approach Clearly conveys the software-development approach taken.

Thorough critical evaluation of the approach. W ell justified explanation of lessons learned. Conveys the main aspects of the software- development approach taken. Some positives AND negatives of the approach identified.

Lessons learned explained with some valid justification. Partially conveys the software-development approach, though with notable omissions and/or some lack of clarity .

Some positives OR negatives of the approach identified.

Reasonable lessons learned stated, but without (valid) justifications. An attempt has been made to convey the development approach, but it is very unclear, and lacks evaluation.

Lessons learned do not pertain to the development approach, or are factually incorrect. No comments on the development approach. No discussion of lessons learned. 11/23/2020 02 Assessment Brief 1.html file:///Users/venkatagovindu/Downloads/02 Assessment Brief 1.html 6/8 Criteria Distinction Commendation Pass Fail Zer o Problems Encountered Clear description of problems encountered, and appropriate solutions to those problems, demonstrating firm understanding of the causes of those problems. All causes of errors in the final program are explained. Mostly clear description of problems encountered, and their solutions, with some limited understanding conveyed of the causes of those problems.

Most errors in the final program are identified, but may lack explanation. Mostly clear description of problems encountered, but without understanding of the causes of those problems. Some errors in the final program are identified, but may lack explanation. Some description of problems encountered, but mostly unclear .

Errors in the final program are not identified. No discussion of problems/errors. Awareness of Code-quality Thorough well- justified critical evaluation of code quality . Correctly identifies both the main strengths and weaknesses of the code quality . Correctly identifies some of the strengths and/or weaknesses of the code quality, perhaps with some lack of clarity . Evaluation of code quality is either unclear or incorrect. No discussion of quality of submitted code. 3. Advice on Getting Started Once you have an idea for a program, you should think about who the (hypothetical) intended user is. This will help you clarify the required functionality of the application. For example, if your idea is to make a 'Cinema' application, you should consider whether it is intended to be used by a customer , a manager, or a front-line sales staf f member — each of these users would require significantly dif ferent functionality.

Once you have determined a user (or users), then you should think about the specific requirements of your system. That is, what functionality should it provide, what inputs will it take, and what outputs will it produce?

If you are struggling to think of an idea for a program, I recommend that you look through the programming exercises and textbook examples for inspiration. These contain a variety of dif ferent types of programs, and it would be fine for you to create something similar, or to extend one of the programs you have already written with additional functionality . If you are still stuck, here are some additional suggestions: A mortgage-assessment calculator. This could be used by either a staf f member of the mortgage provider, or the customer. It would take customer details (such as property price, deposit, customer age), and then of fer a range of mortgage deals. To do well, this should involve compound interest calculations.

An appointment-booking system for a hair -dressing salon. This would be intended to be used by a staf f member at the salon, and could allow for storing customer details, booking and cancelling appointments, and tracking staf f availability.

A computer version of a card game or simple board-game such as 'Connect 4'. This would be used by one or two human players.

A text-based adventure game. This would be intended to be used by a player of the game, and would allow them to move North/South/East/W est around a map. At each location, the player would be given a description, and options as to what to do.

A text parser that does some analysis on written text, such as computing the typical sentence length or linguistical complexity, or identifying sentences that end with prepositions.

A simulation of some simple discrete process, such as Conway's 'Game of Life' [4].

A multilingual children’ s maths quiz. This would be intended to be used by a child taking the quiz, and would randomly generate mathematical problems. At the start of the quiz, the program would ask the user to select a language from a list, and thereafter all questions would be in the chosen language. 4. Resources that may be Useful The module reading list contains several introductory C# textbooks [1, 6, 9]. These are all available from the NTU library , either electronically or as hard copies. For advanced code-quality advice, the textbook by Martin [5] is an excellent resource.

See the module reading list for reading notes on each book, and to access the electronic copies.

NTU library offers support with academic writing, and with mathematics and statistics skills. Individual appointments with librarians or student mentors can be booked online [2]. The library has also published a guide for the correct use of citations 11/23/2020 02 Assessment Brief 1.html file:///Users/venkatagovindu/Downloads/02 Assessment Brief 1.html 7/8 and references [3]. NTU also provides online advice for avoiding plagiarism [7].

Note that failure of personal IT equipment is not considered to be extenuating circumstances, and will not provide grounds for an extension to assessment deadlines. Y ou ar e ther efore str ongly advised to maintain a backup copy of your pr oject work at all times. The University provides the NTU OneDrive [8] remote-storage drive for your use, though you could also use a personal cloud service, or a personal memory stick or portable hard drive.

5. Feedback Opportunities You may request verbal feedback on your work-in-progress project during the online sessions. Y ou will receive written feedback regarding both your program and report within three weeks of the submission deadline.

6. Referencing, Plagiarism and Collusion This is an individual project. This means that your program should be developed individually , and the report describing your program should be individually authored. However, discussing ideas, programming techniques and reference sources with other students is encouraged, provided that you then individually apply those techniques and ideas within your project.

In the field of Software Engineering, it is standard practice to reuse and adapt pre-existing code (subject to licensing restrictions). However, for this project, there is a requirement that the majority of submitted program code is your own original work. You may therefore reuse or adapt some pre-existing program code, but such code must be identified and acknowledged as follows: You should give the full reference details as a comment in the file containing the code, above or below the reused/adapted piece of code. The comment should also clearly identify the amount of code that has been reused/adapted.

You should also give the reference details in the reference list in your Declaration of Authorship form. Note that the use of standard-library components is encouraged, and individual library components do not need to be referenced.

Any reference must identify precisely where the original code is to be found so that it can be examined when assessing your work. For example, a reference to a website must identify the specific webpage on which the code is found, whereas a reference to a textbook must identify the specific page(s) on which the code is found. If the precise location of the original code is not specified, then your work will be assessed under the assumption that the code was copied verbatim with no adaptations. For guidance on how to reference a webpage or textbook, see the NTU Guide to Citing References [3].

Failure to identify and correctly reference reused or adapted code is plagiarism . This includes code written by another student — such code, if not publicly available, can be referenced as a ‘personal communication’, and a copy of the original code submitted as an additional file with your submission. Furthermore, you should not jointly develop a program with another student — doing so is collusion . In the report, any text that was not written by yourself must be enclosed in quotation marks, and the source must be acknowledged by providing an accompanying citation referring to an entry in your reference list. Any diagrams that you did not create should also be cited and referenced. Failure to do so is plagiarism . If you summarise or paraphrase another person’ s work without a citation and reference to acknowledge the source, then that is also plagiarism . See the NTU Guide to Citing References [3] for guidance on correct use of citations and references.

Note that the key here is acknowledgement . If you are in any doubt about whether your use of material from another source is correctly acknowledged, then ask a module tutor for guidance before submitting your project.

7. Aspects for Professional Development This project will give you practical experience of software development, and increase your familiarity with the C# programming language. It should also raise your awareness of code-quality considerations.

References 11/23/2020 02 Assessment Brief 1.html file:///Users/venkatagovindu/Downloads/02 Assessment Brief 1.html 8/8 [1] Jamie Chan. Learn C# in One Day and Learn It W ell. CreateSpace Independent Publishing Platform, revised edition, 2017.

[2] NTU Library. NTU Library bookings. [Accessed 28/09/20] [3] NTU Library. Citing references: A guide to NTU Library Harvard Style, 10th edition, 2016.

[4] LifeWiki. Conway’ s game of life. [Accessed 28/09/20] [5] Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall, 2008. ISBN 978- 0132350884.

[6] Rob Miles. C# Programming Y ellow Book. Imprint: Independently Published, 9th edition, 2018. ISBN 978-1728724966.

[7] NTU. Plagiarism. [Accessed 28/09/20] [8] NTU Information Systems. OneDrive basics: Student user guide, 2016.

[9] Radek Vystavěl. C# Programming for Absolute Beginners. Apress, 2017. ISBN 978-1-4842-3317-7. DOI: 10.1007/978-1- 4842-3318-4.

Go to top