FREQUENTLY ASKED QUESTIONS

This section attempts to further explain aspects of the module based on frequently asked questions from previous years.


Requirements

The full set of requirements can be accessed in the downloads section.

What do the requirements mean?

- These are a set of functional requirements describing the full (beta) system, which is to be developed by the end of Semester 2. You are supplied these now in order to provide you with the means to research, design and plan how you wish to approach the full development of the system, which begins next Semester (or before if you wish!). Careful research and planning should take place in this semester to ensure you are ready to tackle the challenge of development in Semester 2.

Why do I need to conduct further research?

- The requirements are supplied by the Client, who has described what they need from a system, at the maximum level of detail they have. It is up to each team to ascertain the additional detail which can be used to determine a full specification and plan for developing the system based on these requirements. Research into the domain of Student Information Systems (including the emcubent QSIS) will allow this. The client will have no more detail than has been supplied in the requirements list, but will be willing to discuss ideas (during "consultations") with the groups which may be used by them to determine the best approach for certain requirements. It will come across as unprofessional, unprepared and uninformed if groups ask for details which can be readily determined by undertaking research into the area. The research can be carried out by looking at existing systems, Googling for information/documents, and by interviewing/querying users (staff and students) into what works or does not when using these types of systems. There is no single approach to this research, and the more thought put into this early on will provide the most benefit to students in the medium to longer term.

"What would you like to see in...?"

- Do not fall into the trap of asking the client for details of what they would like to see on various pages, forms or outputs, as this will come across as extremely unprofessional. A better approach is to come to the client with ideas, and ask if this is sufficient, too much, about right, etc. You should show that you have researched and have many options, and you are now checking with the Client as to what suits best.

How many core requirements should we do?

- You are required to include all core functionality in your system. Each requirement can be covered in a very basic way or can be very rich in functionality, however marks may depend on how functional this is. This must also be balanced with the extra time required for any non-core requirements covered, so requires the use of careful planning and time analysis. A good balance is usually all core covered to a mid-range (or higher) degree and about half of the non-core requirements covered to a satisfactory level.

How much of the non-core requirements should we attempt?

- You can attempt none, all or some of the requirements. It is difficult (usually impossible) to cover everything to a satisfactory degree, especially when attempting to cover all core requirements, so requires the use of careful planning and time analysis. A good balance is usually all core covered to a mid-range (or higher) degree and about half of the non-core requirements covered to a satisfactory level.

What is an academic?

- Lecturer like myself, teaching one or two modules with certain students enrolled.

What is an academic programme manager (and difference to academic).

- Usually also an academic, but with several more responsibilities, mainly being Advisor of Studies and the tasks involved in this (helping students enrol).

What is a super user?

- Someone who ensures all required accounts are added, including maintaining basic data on the system, and who is trusted with all access to the entire system. Usually only one of these per department.

What is a Senior University Manager (SUM)?

- Management staff who is not involved in the day-to-day administration or teaching duties, but reports to higher management on the running of the school, especially involving student retention, satisfaction and results.

What is an administrator?

- Staff who have responsibilities for keeping records up to date and dealing with student and module related enquiries.

Which roles can teach modules?

- Only Academics and Academic Programme Managers teach on modules.

What is a department?

- University usually broken into departments or schools, based on general discipline. They are usually self-contained with ownership of their own courses and modules, staff and certain (non-central) rooms. Some departments share modules, but ultimately one will out-right "own" a module and courses (e.g. EEECS "owns" the BIT Course, but the course contains modules delivered by both EEECS and School of Management departments).

What sort of style would you like to see?

- I, as the client, expect you to come to me with some ideas for this, and will happily provide my opinion if you have some ideas to run past me. I will say that I would expect you to be able to sell this system to other institutions, therefore some level of branding/style configurability would increase my confidence that this is the case.

How often do we meet for consultation in Semester 1?

- Please read all material supplied, including the lecture notes, in which this information is provided (see slide on "key dates"). It is much better for groups to find information in this material if it is already there as opposed to asking the client.

How much security is required?

- You do not need to show any real security for the basic prototype, but for the beta system at end of Semester 2, it is expected some level of protection (e.g. encrypting passwords) would be in place.

Should we use further security for login for the super user, or a different login page?

- Probably a good idea, but if you are providing this for super-user, why not for all other user roles too? You may consider a separate (more secure) URL for the super-user, but for all other users, there should be a standard single URL login page which can determine the user role when a user logs in.

How much real data to use?

- You can base your sample/prototype data on some actual modules within QUB, but it does not need to be 100% accurate or complete, just enough to be familiar to the client viewing the system. You can have more data for one particular department that you are focussing your prototype on, as opposed to requiring the same level of data for many departments. You can pick up some sample data simply by looking at EEECS web site.

How do students/staff get added initially to the system?

- These would be using a bulk upload (excel, CSV, etc) from a source list of students and their details (as outlined in requirements) supplied by the central Student Records department.

Do we need to provide accurate or real payments for registration?

- The information should have a reasonable degree of "realism", in that the fees should be based on number of modules, status of student, etc. when working out a final total. This does not have to be hooked up to any real payment system, but you could show how the amount decreases as the student "pays off" some or all of it, and a record kept in the database of their payment history.

What is best in terms of notifications?

- You can use "internal" notifications for things like Advisor of Studies requests to help students. This could also be complemented with emails being sent at appropriate times. For example, if a class is cancelled, it may be more likely a student will read an email alert as opposed to the chances they will login into the system to see the change in circumstances.

What should be shown on the home page?

- This is up to your own design decisions and what you think is most useful. Some examples can be large buttons to navigate quickly to commonly used areas of the system (which can be dependent on the user role), or advertisements/useful external links, as well as alerts and relevant news.

What are the best/worst aspects of QSIS which could influence the new system?

- In general, QSIS is seen as unintuitive and very out-dated looking. As a modern institution, moving from this image to a new system, built on modern technology with fresh design and HCI ideas, will help the image of QUB. However, it cannot be forgotten that QSIS is very powerful, with a lot of rich functionality. Any new system must be quite functional, as evidenced by the core and non-core functionality listed in the requirements document.

Should the system be designed for smaller screens and/or accessibility (including colour-blindness)?

- Absolutely. Responsive design and accessibility can be described as the "most core of the non-core" functional requirements. Given there are useful platforms (such as Bootstrap) freely available to make this straightforward to achieve, you should consider involving this technology early in your design and development process.

The Proposal

The Guidance document including Marking Scheme can be accessed in the downloads section.

What is the proposal supposed to be exactly?

- This is an outline plan, delivered in a series of slides, of the full approach in your team tackling the challenge of developing the full (beta) Student Information System. Full details are provided in the guidance document.

Do I need to print it?

- No. This will be kept in electronic format (slides) and emailed to the Client (p.p.mcmullan@qub.ac.uk).

What format is required?

- This is a set of slides, so most likely Powerpoint format is best, although I am happy to accept other slideshow formats as long this can be viewed by freely available software (please include instructions if so).

Is it one per group or one per individual?

- This is a group submission, so only one per group. When emailing, all team members can be included in the email, or one team member (or a selected few) can be included. Responses will be only provided to those sending the original document, so any feedback received will need to relayed by the recipients to other team members.

What are the page limits (minimum or maximum)?

- The minimum document length is 14 slides, with a maximum of 20 slides. Details can be found in the guidance document for the proposal.

When do we need to submit the Proposal?

- The proposal should be submitted to the client via email (p.p.mcmullan@qub.ac.uk) on or before 4pm, 7th December 2017.

When will I receive results and feedback?

- You will receive results and feedback (via email, to the senders of the Proposal) by or before Friday 15th December 2017.

Prototype

The Guidance document including Marking Scheme can be accessed in the downloads section.

What sort of Prototype system do we need to deliver?

- The system is merely a very basic prototype, which does not have to have any of the actual working functionality in place when submitted. It should however, provide the user with a basic idea of the style, design and navigation of the system when completed. To this regard, it is useful to "mock up" some of the key pages within the system and possibly show how some functionality may work when completed.

If we do start adding actual requirements to the prototype in Semester 1, do we get more marks?

- No, but you will have the advantage of having a better head-start for the full version in Semester 2, but there is no requirement in terms of marks to do so.

What development language can we use?

- You can use .NET C#/VB (ASP or MVC) or Java if you wish.

What Source Code repository can we use?

- GItLab or SVN is recommended and supported within EEECS.

Which database can we use?

- SQL Server is recommended and supported within EEECS. You may also use MySQL or any other appropriate database system. There is no requirement to actually hook the prototype up to a database for the purposes of assessment, but it may be useful to have this ready for the main system in Semester 2.

How do I go about hosting it?

- You can set this up independently if you have access to a web account with database server capability, or can contact the Computer Science technical team to assist (Sean McKeever).

When does it need to be ready?

- It should be accessible by the Client at 4pm on Thursday 7th December.

What do I need to provide to allow you access to the prototype?

- The client will access the system via a supplied (by you via email) URL, which should point to the Login page. If required to login, please supply Login details. It may also be useful to provide some guidance in exploring the system, a brief directed walk-through to ensure the Client sees all elements of the prototype available.

When do we need to make this available?

- The prototype should be available to the client on or before 4pm, 7th December 2017.

When will I receive results and feedback?

- You will receive results and feedback (via email, to the senders of the URL/details) by or before Friday 15th December 2017.

General System

Can I use an Open Source (or trial) web component I have found on the web?

- Yes, within reason. It is perfectly fine to use Javascript components as may be found in JQuery, etc. A good example is "FullCalender" for calendar functionality. If you do find an actual "application" which is more fully functional, you would need to check this. For example, if you find a web application which performs student enrolments, this is not allowed as this should be written yourselves.

Can I add more (or alternate) functionality which has not been listed in the non-core requirements?

- This is okay, only as long as it adds value to your system and is relevant to the overall use and quality of the system itself. You can swap this out for some specified non-core functionality, but it is best to check this beforehand to make sure.

Which database can we use?

- SQL Server is recommended and supported within EEECS. You may also use MySQL or any other appropriate database system.

Security

Do I need to encrypt passwords?

- This is recommended to ensure a good level of security, but will require you to research the most appropriate way of doing so.

Forgotten passwords - what's the best approach for the user?

- This is up to the group in which of the various methods of password retrieval they wish to employ. Always remember to try to ensure this is as secure as possible.

Groups

I am having problems with my group, one or more of the following:
  • A group member is (or several are) dictating terms and I don't have a say in what I do or the direction of the group. What should I do?
  • I don't feel like I fit in.
  • One or more members are not pulling their weight.

- The first and best method is to communicate this with all or relevant group members and try to work out the problems. Your leadership can be proven in bringing difficult or weak group members along with the others. Please note this in your development diary as this will be noted.

Can I move to another group?

- No. The groups are carefully chosen and each group will have their own (similar or other) challenges, with the distribution of abilities spread evenly. Your leadership can be proven in bringing difficult or weak group members along with the others. Please note this in your development diary as this will be noted.

Can I get one or more group members moved out of my group?

- No. The groups are carefully chosen and each group will have their own (similar or other) challenges, with the distribution of abilities spread evenly. Your leadership can be proven in bringing difficult or weak group members along with the others. Please note this in your development diary as this will be noted.

Should I be worried if I hear any rumours being spread among groups (about anything to do with the course)?

- This normally happens each year, and you can ignore any rumours which may have been spread by class mates either deliberately or by misinterpretation. Only that information from myself or contained in the notes/guidance should be given any notice.

Peer Assessment

The Peer Assessment form including Guidance can be accessed in the downloads section.

What is peer assessment and do I need to use it?

- As well as the questions below, the guidance in the Peer Assessment form (document) and in the Lecture Notes. Anything not answered in this FAQ will be covered in these documents.

We all feel we contributed evenly.

- Great. You don't need to use Peer assessment. If you do not include the form with your report, it is assumed this is the case.

Some contributed more than others, and we are agreed on our different weightings.

- Great, just make sure you submit one form (hard copy) with your final report. Follow the guidance on the form and this will be taken into account when working out the final allocated marks for system and report.

What is the usual maximum minimum weightings typically when the contribution is uneven?

- The top mark is 100% (there should be at least one person at 100%), with others of lesser contribution less than this. Normal values don't go much lower than 70%, and when they do we may seek to check this in case anything is untoward.

Some members did not contribute enough, but they do not agree with others and feel they deserve more.

- This requires individual peer assessment forms for each group member, stating their own weighting and that of others. Please refer to the guidance in the form. Each person should also be fair about the weightings (both theirs and for others) as anything which looks suspicious (inflating your own weighting, or depressing others) will be examined carefully and may affect the final mark. The assessor will use academic judgement to settle on a final weighting for each group member. Individual forms should be submitted to Brian Fleming in the general office.

When do we need to submit either group or individual forms?

- Group forms may be submitted (hard-copy) with the final Report. Individual or Group forms may be submitted directly to Brian Fleming in the General Office of Computer Science Building no later than 5pm, 27th April 2018.

One or more members did a lot more of the work as they were stronger at coding, but now feel they deserve most of the marks.

- Again, individual peer assessment will be required, and each member should use their right to provide what they feel is fair. Where someone has suppressed the chances of others attempting to contribute, fearing a lesser final mark, this will be examined and identified. A major part of the project is team work, and there is no place for someone keeping others back.

One or more of the group are telling me what weighting to give, either to them, myself or someone else in the group. Is this ok?

- Unless you agree with what they say, no. You should exercise your own judgement in assessing your own contribution and that of others. Do not feel intimidated or forced by anyone else, despite what pressure or persuasion they may put on you.

Someone contributed basically zero, didn't turn up to meetings, and still feel they deserve marks. What do I do in this case?

- Where there is definite evidence of non-contribution, you can assign a weighting of less than 70%. Weightings of zero can also be assigned, although it has to be very clear that they had no part to play in the group effort.

Development Diary

The Guidance document including Marking Scheme can be accessed in the downloads section.

When and how do I submit my development diary?

- This is submitted at 4pm on Thursday 19th April (Semester 2, Week 12), by email to myself (p.p.mcmullan@qub.ac.uk). Any submissions not received by this time may be subject to penalty on marks, although any extenuating circumstances will be considered.

Do I need to print it?

- Absolutely not. In a small attempt to save some trees, we request that you do not print these, and submit by email only, as outlined.

Is it one per group or one per individual?

- This is an individual submission, so you are solely responsible for writing and submitting your own diary. This is NOT a group effort. Plagiarism will be identified and affect marks.

Do I need to include full minutes of meetings?

- Please see guidance. Only minutes of certain key meetings, and use of Appendices are encouraged. Full details are provided in the guidance documentation.

What are the page limits (minimum or maximum)?

- Please see guidance. As a rough guide, the final document should be a minimum of 13 pages, or a maximum of 20 pages in length. If you are slightly above this limit, do not worry as this will not affect your marks. You can also use Appendices to provide any further material you wish as required. These are not included in the page limit guide.

Can I talk openly about other group members and is it confidential?

- Yes, you are encouraged to do so, especially if you wish to heap praise on people or criticise members for lack of contribution or creating difficulties. This is completely confidential and will not be seen by anyone other than the assessor, even in the future.

Do I have separate sections for Semester 1 and Semester 2?

- No, the diary should seamlessly cover both semesters (the entire module), although it is recognised that there will be more development-related content for the Semester 2 timespan. It should be chronological as much as possible, showing your "journey" through the module.

Presentation

The Guidance document including Marking Scheme can be accessed in the downloads section.

When do we do the final presentation?

- This will occur early (probably Tuesday/Wednesday) on Week 12 of Semester 2. You are encouraged to prepare this the week before and practice the delivery beforehand.

Do we all need to present?

- It is encouraged (as much as possible) that everyone in the group be in attendance, but not all need to be part of the actual presentation. Someone for example could field any technical questions at the end, even if they were not part of the delivery.

Do we need to dress up (formal) or is causal ok?

- There is no need for formal dress, this is a very informal session, although the usual Sports gear should be avoided!

What is the typical format?

- The presentation will take place within a "session" with a few (3 or 4) other groups, so you will have a chance to listen to other presentations as well as present to your peers. The presentation lasts a strict maximum of 25 minutes (although can be shorter than this), with about 5 minutes at the end for several (light-touch) questions. The guidance documentation provides more details of the make-up of the structure of your presentation.

How many slides usually?

- Can be anything between 4 to 8 slides, depending on how much content or visuals you wish to include.

Can I record demo and play-back by video?

- Yes, this is allowed, although we encourage this to be complemented with "live" demonstration as well. The video can be used for some complex, time-consuming or involved functionality which might be difficult to present live. You can edit this to speed things up.

Do I need audio included in this?

- This is fine, and can sometimes enhance the video experience, although text captions will suffice if audio is not possible.

How much "live" demo do I need to include?

- A minimum of 5 minutes or several functional requirements should be included in the live video. Please see the guidance for more information on the structure.

How much time will there be for questions at the end?

- Roughly 5 minutes, although these will be of general-interest (light touch) and not intended to trick or test groups.

What is a typical question asked at the end?

- "Why did you decide to use MVC rather than standard ASP.NET?"
- "How difficult was it to implement the Calendar control you are using?"
- "Who designed the crazy Logo you have used in the system banner?"

We heard some groups are printing business cards, brochures or bringing in promotional material. Will we be disadvantaged if we do not do this?

- Not at all. These can sometimes enhance the professionality of groups, but are not necessary for this purpose. This will come across from your delivery and content. These extra props are simply that, and if used, must not appear cheap or "gimmicky".

Final Report

The Guidance document including Marking Scheme can be accessed in the downloads section.

When do I submit final report?

- This is submitted at 4pm on Thursday 19th April (Semester 2, Week 12), as a hard-copy, printed, bound document, to Brian Fleming in the General Office of the Computer Science Building. Any submissions not received by this time may be subject to penalty on marks, although any extenuating circumstances will be considered.

Where do I leave this?

- As outlined, this is handed in to Brian Fleming in the General Office of the Computer Science Building.

Is it one per group or one per individual?

- This is a group-based document, so only one copy is required to be printed and bound and left with Brian. You do NOT need a copy per individual team member.

Hard copy or soft copy?

- We need a physical hard-copy, printed out.

Does it need to be bound?

- Yes, although the type of binding you decide is up to yourself. As long as it looks professional (and holds together), whatever you decide is fine.

What are the page limits (minimum or maximum)?

- There are no specific page limits, and the length of your system can vary between groups and the amount of content you need to include. As a rough guide, generally the main body of the report can be between 50 and 200 pages, so you do have a lot of flexibility. The lower end would not comprise a very "hefty" document though, and may be light on required detail. If you go above 200 pages, as long as it doesn't reach the 1000's, this is acceptable. Appendices can be used to ensure the flow of the main body of the document remains intact.

Should I include a User Guide?

- A short User Guide may be useful, although do not spend a lot of time on it.

How many Unit tests do I need to include?

- A sample (10%) of your Unit tests is enough, usually varied to show the different types of tests or on different parts of your system. Mainly though, this is up to yourself, and used to indicate that you have performed testing and have a reasonably thorough approach to this.

Dr. Paul McMullan
Room: 03.002
Computer Science Building
18 Malone Road
Belfast
BT9 5BN

CONTACTS
Email: p.p.mcmullan@qub.ac.uk
Phone: +44 (0)28 9097 4653

Please monitor the BLOG section for up-to-date information.

It is the responsibility of each student to turn up to each and every element of the module prepared and in a timely manner. If any student is experiencing difficulties they should contact Dr Paul McMullan.

LINKS