proj23.md

 

 

🌀 CSC510: Software Engineering
NC State, Spring '25

Project 2 & Project 3

Deadlines

• Project 2 Deadline: February 26
• Project 3 Deadline: April 16

Your Task

Project 2: Extend and enhance an existing project.

Project 3: Work on another team's Project 2 code.

Important Notes:

• Your goal is to do enough work and paint a clear vision for the future so that someone else wants to use your code for their next project.
• Your deliverables include a 15-minute demo with a tutor, who will assess significant improvement in your current project compared to its initial state.
• Projects 2 and 3 will be assessed in live demo sessions with the tutor/grader. These sessions will occur during the weeks of March 3 and April 21. We ask students for help scheduling all these demo sessions. Our graders/tutors are students with their own exams and assignments to complete. Hence, they might suggest demo times outside normal working hours (evenings, weekends). Please do them the courtesy of considering those times. That said, if those proposed times are inconvenient, you can, should, and must ask for other times.
• Cameras ON for all participants. NO AI voices—we want to hear and see you.

⚠️ Demo Sessions:

• Live demo sessions will be held in the weeks of March 3 and April 21.
• Tutors may suggest demo times outside normal hours (evenings/weekends). Please be considerate.
• If the suggested times are inconvenient, you may request alternatives.

What to Submit

Submit a single PDF file containing:

1. A project poster (similar to the Project 1 poster) aimed at attracting another team to work on your code for Project 3.
2. A link to your project repository. The repository must meet the following requirements:
   • Public repository (not hosted at NCSU).
   • No keys or passwords in files.
   • New work should be in a separate branch from the old.
   • The repository must contain:
     • README.md (with badges)
     • .gitignore
   • Badges must be functional (i.e., clicking them should lead to the respective service, such as a code coverage tool showing "78% tests passing").
   • Demonstrate parallel work, showing merged pull requests.
   • Each team member should add at least 20 new test cases, for a total of 60 new test cases for a team of 3 covering both nominal and off-nominal scenarios (expected and problematic cases).
3. Fill Software Sustainability Evaluation self-assessment and Repository Rubric tables:

Software Sustainability Evaluation self-assessment table:

Category	Question	Yes	No	Evidence
Q1 - Software Overview
Question 1.1	Does your website and documentation provide a clear, high-level overview of your software?	✅	❌
Question 1.2	Does your website and documentation clearly describe the type of user who should use your software?	✅	❌
Question 1.3	Do you publish case studies to show how your software has been used by yourself and others?	✅	❌
Q2 - Identity
Question 2.1	Is the name of your project/software unique?	✅	❌
Question 2.2	Is your project/software name free from trademark violations?	✅	❌
Q3 - Availability
Question 3.1	Is your software available as a package that can be deployed without building it?	✅	❌
Question 3.2	Is your software available for free?	✅	❌
Question 3.3	Is your source code publicly available to download, either as a downloadable bundle or via access to a source code repository?	✅	❌
Question 3.4	Is your software hosted in an established, third-party repository like GitHub, BitBucket, LaunchPad, or SourceForge?	✅	❌
Q4 - Documentation
Question 4.1	Is your documentation clearly available on your website or within your software?	✅	❌
Question 4.2	Does your documentation include a "quick start" guide, that provides a short overview of how to use your software with some basic examples of use?	✅	❌
Question 4.3	If you provide more extensive documentation, does this provide clear, step-by-step instructions on how to deploy and use your software?	✅	❌
Question 4.4	Do you provide a comprehensive guide to all your software’s commands, functions and options?	✅	❌
Question 4.5	Do you provide troubleshooting information that describes the symptoms and step-by-step solutions for problems and error messages?	✅	❌
Question 4.6	If your software can be used as a library, package or service by other software, do you provide comprehensive API documentation?	✅	❌
Question 4.7	Do you store your documentation under revision control with your source code?	✅	❌
Question 4.8	Do you publish your release history e.g. release data, version numbers, key features of each release etc. on your web site or in your documentation?	✅	❌
Q5 - Support
Question 5.1	Does your software describe how a user can get help with using your software?	✅	❌
Question 5.2	Does your website and documentation describe what support, if any, you provide to users and developers?	✅	❌
Question 5.3	Does your project have an e-mail address or forum that is solely for supporting users?	✅	❌
Question 5.4	Are e-mails to your support e-mail address received by more than one person?	✅	❌
Question 5.5	Does your project have a ticketing system to manage bug reports and feature requests?	✅	❌
Question 5.6	Is your project's ticketing system publicly visible to your users, so they can view bug reports and feature requests?	✅	❌
Q6 - Maintainability
Question 6.1	Is your software’s architecture and design modular?	✅	❌
Question 6.2	Does your software use an accepted coding standard or convention?	✅	❌
Q7 - Open Standards
Question 7.1	Does your software allow data to be imported and exported using open data formats?	✅	❌
Question 7.2	Does your software allow communications using open communications protocols?	✅	❌
Q8 - Portability
Question 8.1	Is your software cross-platform compatible?	✅	❌
Q9 - Accessibility
Question 9.1	Does your software adhere to appropriate accessibility conventions or standards?	✅	❌
Question 9.2	Does your documentation adhere to appropriate accessibility conventions or standards?	✅	❌
Q10 - Source Code Management
Question 10.1	Is your source code stored in a repository under revision control?	✅	❌
Question 10.2	Is each source code release a snapshot of the repository?	✅	❌
Question 10.3	Are releases tagged in the repository?	✅	❌
Question 10.4	Is there a branch of the repository that is always stable? (i.e. tests always pass, code always builds successfully)	✅	❌
Question 10.5	Do you back-up your repository?	✅	❌
Q11 - Building & Installing
Question 11.1	Do you provide publicly-available instructions for building your software from the source code?	✅	❌
Question 11.2	Can you build, or package, your software using an automated tool?	✅	❌
Question 11.3	Do you provide publicly-available instructions for deploying your software?	✅	❌
Question 11.4	Does your documentation list all third-party dependencies?	✅	❌
Question 11.5	Does your documentation list the version number for all third-party dependencies?	✅	❌
Question 11.6	Does your software list the web address, and licences for all third-party dependencies and say whether the dependencies are mandatory or optional?	✅	❌
Question 11.7	Can you download dependencies using a dependency management tool or package manager?	✅	❌
Question 11.8	Do you have tests that can be run after your software has been built or deployed to show whether the build or deployment has been successful?	✅	❌
Q12 - Testing
Question 12.1	Do you have an automated test suite for your software?	✅	❌
Question 12.2	Do you have a framework to periodically (e.g. nightly) run your tests on the latest version of the source code?	✅	❌
Question 12.3	Do you use continuous integration, automatically running tests whenever changes are made to your source code?	✅	❌
Question 12.4	Are your test results publicly visible?	✅	❌
Question 12.5	Are all manually-run tests documented?	✅	❌
Q13 - Community Engagement
Question 13.1	Does your project have resources (e.g. blog, Twitter, RSS feed, Facebook page, wiki, mailing list) that are regularly updated with information about your software?	✅	❌
Question 13.2	Does your website state how many projects and users are associated with your project?	✅	❌
Question 13.3	Do you provide success stories on your website?	✅	❌
Question 13.4	Do you list your important partners and collaborators on your website?	✅	❌
Question 13.5	Do you list your project's publications on your website or link to a resource where these are available?	✅	❌
Question 13.6	Do you list third-party publications that refer to your software on your website or link to a resource where these are available?	✅	❌
Question 13.7	Can users subscribe to notifications to changes to your source code repository?	✅	❌
Question 13.8	If your software is developed as an open source project (and, not just a project developing open source software), do you have a governance model?	✅	❌
Q14 - Contributions
Question 14.1	Do you accept contributions (e.g. bug fixes, enhancements, documentation updates, tutorials) from people who are not part of your project?	✅	❌
Question 14.2	Do you have a contributions policy?	✅	❌
Question 14.3	Is your contributions' policy publicly available?	✅	❌
Question 14.4	Do contributors keep the copyright/IP of their contributions?	✅	❌
Q15 - Licensing
Question 15.1	Does your website and documentation clearly state the copyright owners of your software and documentation?	✅	❌
Question 15.2	Does each of your source code files include a copyright statement?	✅	❌
Question 15.3	Does your website and documentation clearly state the licence of your software?	✅	❌
Question 15.4	Is your software released under an open source licence?	✅	❌
Question 15.5	Is your software released under an OSI-approved open-source licence?	✅	❌
Question 15.6	Does each of your source code files include a licence header?	✅	❌
Question 15.7	Do you have a recommended citation for your software?	✅	❌
Q16 - Future Plans
Question 16.1	Does your website or documentation include a project roadmap (a list of project and development milestones for the next 3, 6 and 12 months)?	✅	❌
Question 16.2	Does your website or documentation describe how your project is funded, and the period over which funding is guaranteed?	✅	❌
Question 16.3	Do you make timely announcements of the deprecation of components, APIs, etc.?	✅	❌

Repository Rubric

• The project repo MUST have a branch called MAIN. Groups will be assessed via their commit history (seen under "Insights") in MAIN. Projects where all group members are not actively making commits will lose marks, or the offending student may be expelled from the group.
• Groups need to maintain an active discussion in some online forum. GitHub issue reports will be fun. Optionally, students can request a Discord channel. Projects where all group members are not active in discussions will either lose marks, or the offending student may be expelled from the group.

Each team starts with full marks but loses 0.33 marks for missing items:

Notes	Evidence	Score
Workload is spread over the whole team (one team member is often Xtimes more productive than the others... --
but nevertheless, here is a track record that everyone is contributing a lot)	evidence in GH
Number of commits	in GH
Number of commits: by different people	in GH
Issues reports: there are many
Issues are being closed	evidence in GH
Docs: doco generated, format not ugly	in GH
Docs: what: point descriptions of each class/function (in isolation)
Docs: how: for common use cases X,Y,Z mini-tutorials showing worked examples on how to do X,Y,Z	doc page entries
Docs: why: docs tell a story, motivate the whole thing, deliver a punchline that makes you want to rush out and use the thing
Docs: short video, animated, hosted on your repo. That convinces people why they want to work on your code.
Use of version control tools
Test cases exist	dozens of tests and those test cases are more than 30% of the code base
Test cases are routinely executed	E.g. travis-com.com or github actions or something
Issues are discussed before they are closed	even if you discuss in slack, need a sumamry statement here
Chat channel: exists	Link or screenshots
Test cases: a large proportion of the issues related to handling failing cases.	If a test case fails, open an issue and fix it
Evidence that the whole team is using the same tools: everyone can get to all tools and files
Evidence that the whole team is using the same tools (e.g. config files in the repo, updated by lots of different people)
Evidence that the whole team is using the same tools (e.g. tutor can ask anyone to share screen, they demonstrate the system running on their computer)
Evidence that the members of the team are working across multiple places in the code base
Short release cycles	(hard to see in short projects) project members are committing often enough so that everyone can get your work
The file .gitignore lists what files should not be saved to the repo. See [examples]i(https://github.com/github/gitignore)	in GH
The file INSTALL.md lists how to install the code	in GH
The file LICENSE.md lists rules of usage for this repo	in GH
The file CODE-OF-CONDUCT.md lists rules of behavior for this repo; e.g. see example	in GH
The file CONTRIBUTING.md lists coding standards and lots of tips on how to extend the system without screwing things up; e.g. see example	in GH
The file README.md contains all the following	in GH
Video	2min video of new functionality, showing a significant delta from prior.
DOI badge: exists. To get a Digitial Object Indentifier, regiser the project at Zenodo. DOI badges look like this:	in GH
Badges showing your style checkers	config files in GH showing your config, badges in README
Badges showing your code formatters.	config files in GH showing your this formatter's config, badges in README
Badges showing your syntax checkers.	config files iin GH showing this checker's config, badges in README
Badges showing your code coverage tools	config files in GH, badges in README
Badges showing any other Other automated analysis tools	config files in GH, badges in README

• Column 1: Required points (see table above and ).
• Column 2: Supporting evidence (e.g., links to GitHub, documentation, reports).
• Column 3: Self-assessment score (0 = none, 1 = a little, 2 = somewhat, 3 = a lot).
• At the buttom, show the sum of Column 3.

Poster Requirements

Each poster must:

• Be a standard page size (e.g., letter or A4).
• Use small fonts (text may be as small as 4 to 6 points).
• Be submitted as a PDF file.
• Avoid vast amounts of white space.
• Include the following:
  • Screenshots of the running system.
  • URLs/QR codes:
    • To the repository.
    • To a live demo (how you host the demo is up to you).
  • Sell the software:
    • Highlight up to 5 ways Version i is better than what was true BEFORE this software was written.
  • Propose a better version (Version i+1):
    • Include 3–5 implementation milestones to improve Version i+1.
    • Milestones must demonstrate a possible implementation plan with clear goals.
    • Some milestones may be explored in parallel.
  • Boast your test cases:
    • E.g., "One group listed 130+ test cases, showcasing their ability to make changes while maintaining old functionality."

📌 Submission Instructions:

• Submit your work to Moodle (1 poster) AND
• Post your poster to the Discussions Forum.

💬 Get Involved!

• React in the Discussions Forum to the posters you like so we can identify the best ones! 👍👎

Grading Criteria

Project 2:

• Demo: 5 marks
• Rubric Compliance: 8 marks (see below)
• Poster: 2 marks

Project 3:

• Demo: 21 marks
• Poster: 2 marks

Ways to Lose Points

• Your poster or demo does not have the above features.
• Your poster fails to effectively sell the project. Specifically:
  • Within the first 15 seconds of reading, the poster does not clearly explain what the project is about.
  • The poster does not make a compelling case for why this technology stack is interesting (e.g., "Select this project to learn about Kubernetes").