NUS Module Reviews 2023/2024 Business Analytics (BZA), School of Computing (SoC) - Y2S2: BT3103, IS3103, BT3102, EL1101E, DAO1704X

I took 5 courses which are 20 units in total during this semester. Among them, two are core courses (IS3103, BT3103) for my major, one is programme elective for my major (BT3102), two are Interdisciplinary / Cross Disciplinary courses (EL1101E, DAO1704X).

BT3103 Application Systems Development for Business Analytics

Introduction:

Link to Nusmods: https://nusmods.com/courses/BT3103/application-systems-development-for-business-analytics

Semester 2

Lecturer: Shashank Shekhar Tripathi

Timetable Workload (lecture): 3 (however you need to spend a lot of time after class for project)

Attendance: Yes, through PollEv

Lecture Recordings: Videos are uploaded after lectures.

Grading Scheme / Assessment:

Evaluation:

● Individual Assessments(Quizzes-Lecture 3,5 & 8)

● Mid-Sem Group Project Submission (~ Recess Week) 

● Final Group Project Submission(Lecture 13)

Assessment:

● 15% for participation in class and completing class activities (Individual)

● 30% for quizzes and assignments (Individual)

● 25% Mid Sem Project Submission (Group)

● 30% Final Project Submission (Group)

Lect 3 : HTML + CSS (Lect1 +Lect2): MCQ, (~25 to 30 Questions) 30 Minutes 

Lect 5: Javascript ( Lecture 3 + 4) MCQ, (~25 to 30 Questions) 30 Minutes 

Lect 8 : SCRUM (The scrum guide) MCQ, (~25 to 30 Questions) 30 Minutes 

Mid Term Project Report: End Recess week ( 1 March 2024 - 23:59)

Peer Evaluation + Final Term Submission : 26 April 2024 - 23:59

No changes after submissions and deadlines

Lectures:

In my cohort, there are two lecture slots, and students can only form groups within their corresponding lecture slot. This means that if you want to be in the same group with your friend, you should select the same lecture slot during course registration. However, I believe this varies depending on the number of students enrolled in the course. For example, a friend of mine took this course in the following semester, and they only have one lecture slot available.

Lecture attendance is tracked using poll questions on PollEv, and participation is recorded rather than accuracy. Personally, I found the lectures quite dry, and the late timing made it difficult for me to stay focused. The good thing is, Professor Shashank would upload the lecture videos to Canvas afterwards, so if you happen to zone out during class, you can always refer back to the recorded sessions.

Individual Assignment:

My records for this course were very messy so I am unsure about the specific number and dates of assignments. If I remember correctly, individual assignment started from week 2's lecture onwards. After that, each lecture will have one assignment until lecture 6 or 7. The last assignment was group-based, and each group only needed to have one student attempting the question and submit. There are about 8 assignments in total. 

It may seem scary, but Professor Shashank actually provides most of the necessary code in the lecture slides. However, the frustrating part is that there are many errors and inconsistencies in the slides. So, if you try to copy and paste everything, you're likely to encounter bugs. Additionally, the code was inserted as images in the slides so you can't directly copy and paste.

Usually people should get full marks for the individual assignments because almost everything was provided. So if you encounter problems, do consult your group mates, or TAs, or Prof in time. Don't miss the submission and try not to make errors.

Keep in mind that you can only submit once for all individual assignments!

Group Project:

I had a tough time with this project because I'm not very good at coding in general. The project involved designing a web app as a group following the SCRUM framework (which is just a project management method—it's not as fancy as it sounds, and the details are covered in the lectures). Students needed to form groups within the first two weeks and all group members should come from the same lecture slot.

There isn't too much to do before the midterm project submission. The midterm project was a report with a maximum of 25 pages, covering topics such as product requirements, product designs and architecture, relevant information flow charts, and more. The slide below was provided as a reference for the structure of the midterm report, and you may use it as a guide.

I have also put the table of contents for my group's midterm submission as a reference.

You can use interface design platforms like Figma or opt for HTML interfaces. While Professor mentioned that HTML interfaces are preferred because you can build on them for the final project, he also clarified that no extra marks would be given for using HTML interfaces, and the grading wouldn't be focussed on the aesthetic design. Still, I recommend to have a decent design as least. For my group, we used Figma for midterm report.

For the final submission, you need to submit four things: the final report, the code for the web app, the SCRUM report, and a video demonstrating the web app. My advice is to work on the SCRUM report as you go, rather than leaving it until the last minute, because you'll likely forget many details if you try to do it all at once later on.

You may refer to the below youtube video (it's not my group's) to get a better idea of how the project product looks like and what the presentation is like. You can also find other videos online. 

Group Project: thoughts and suggestions

I couldn’t find the grading scheme for the midterm and final either, and I don't think Prof ever shared it with us as I remember discussing with my group mates about what Professor might prioritise in the grading. However, he did disclose some relevant information. For instance, he mentioned that "no extra marks would be given for using HTML interfaces for the midterm" and that "grading would not focus on the aesthetic design." He also said it was okay if we couldn’t complete all the requirements for the final, as long as there was evidence that the features were in development. 

This raises the question: how does Prof know if an incomplete feature is still in progress? Prof explained that there should be classes or pages related to that feature in the code you submit. So, if your group is struggling with certain features, don’t just delete the relevant code. You can comment it out or simply leave it unused. The key point is to provide some evidence that you've put effort into developing that feature.

Secondly, both the midterm and final reports should include sufficient detail regarding functional and non-functional requirements. Prof will provide examples during lectures on how to write these requirements, so pay close attention. You may find that you're unable to complete some of the requirements listed in the midterm report. Don’t just delete them from the final report and act as if they were never there. Instead, mark those requirements as "in progress" in the final report. The key is to be authentic and sincere—don’t try to fool Prof or TAs.

Thirdly, when it comes to UX/UI design and aesthetics, keep in mind that UX/UI design is not the same as aesthetic design. Even if your group isn’t particularly strong in aesthetics, it’s important to ensure that user interaction is fluent and intuitive.

Lastly, the SCRUM report is crucial. Prof emphasised multiple times that he would grade based on how well the SCRUM report is done and how consistent it is with your GitHub code history. So, don’t underestimate this component—make sure to clearly describe what each group member has done in the SCRUM report. Again, don't try to fool Prof or TAs.

Individual Quizzes

Quizzes were conducted during lectures and started right at the beginning, so don’t be late for the quiz sessions. We used Canvas for the quizzes, which typically consisted of 25-30 questions and lasted 30 minutes. You can't navigate back, meaning once you clicked "next question," you couldn't return to change your answers. The quizzes were open-book and open-internet, featuring both multiple-choice (MCQ) and multiple-response questions (MRQ).

My personal experience: the quizzes often had little connection to the lecture content. In other words, they were difficult, and most students either relied entirely on ChatGPT or used it for assistance. My suggestion is not to rely solely on ChatGPT for MRQs, as its answers were sometimes inconsistent, leading to lower accuracy.

Moreover, manage your time carefully, as the time limit is actually quite tight. If you take screenshots of the questions and input them into ChatGPT, it can take a while for it to generate answers. I often found myself either rushing through the last few questions by randomly selecting answers or finishing the quiz too early with nothing else to do.

I know some of you may be curious about the bellcurve, and YES, I TOOK PHOTOS OF THE QUIZ SUMMARY AFTER ALL THREE QUIZZES. Anyway, the below are lecture 2 students' performance.

You can tell that we really messed up the second quiz, and I highly suspect that Prof got concerned afterward. As a result, he made the third quiz extremely simple, which led to an average score of 85%. I digress, but it was pretty funny.

Conclusion:

I struggled a lot with this course, but I also learned a lot. That being said, I felt like most of the knowledge I gained came from self-study, particularly while working on the project. This seems to align with a common complaint among BZA students about BT-coded courses: they teach you a lot of things that aren't practically useful, and you end up having to self-study almost everything that really matters.