csc 510-001, (1877)
fall 2024, software engineering
Tim Menzies, timm@ieee.org, com sci, nc state
home :: syllabus :: corpus :: groups :: moodle :: license
Project2, Project3
Your task
Extend the project you selected from the last project.
Important notes:
- You goal is to do enough work, and paint a clear vision for the future, such that someone else wants to use your code for project3
- your deliverables here include a 15 minute demo with a tutor where they will be looking for significant improvement in your current project (compared to what you started with).
What to hand in
One pdf with
- a poster advertising your project (just like the project1 poster) with the aim to attract some other team to work on this code for project3.
- a link to your project repo. That repo must have the follow
- Repo is public (not at NCSU)
- No keys or passwords in files
- New stuff should be in separate branch to old
- The repo contains the file names
- READMME.md (with badges)
- .gitignore
- Bages have to be ‘real’: i.e. if yu click on them you end up at the service that generated the (e.g._ 78% of tests passing” badge.
- Project shows evidence of parallel work; i.e. merged pull requests
- At least 20 test cases per team member. - test cases include nominal and off-nominal cases (so you are testing for expected and problematic cases)
- A table with three columns:
- Column1 has all the following points shown in the table below PLUS all the points from the Software Sustainability Evaluation.
- Column2 is your self-assessment. For each items, score yourself zero (none), one (a litte), two (somewhat), three (a lot).
- Column3 is for any links you are adding to support your claim in column two.
- At the top, show the sum of column2,
Rubric for Repo
| Notes | evidence |
|---|---|
| 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 |
Rubric for poster
One anti-patterns seen in the prior posters (and don’t let this happen to you):
- It was hard to distinguish what existed, right now, in the current
project
- From the proposed extensions
Your poster:
- Is a standard page size
- Uses very small fonts ( text may be as small as 4 to 6 point)
- Is a pdf file
- Does not have vast amounts of white space
- Has
- a screen snaps of the running system;
- has a url/QR code to the repo (to ensure that the QR code of the poster does not expire, use tiny.cc or NCSU go links
- optionally (but preferred) has a url/QR code to a live demo (and how you host that demo is up to you).
- Sells the software:
- i.e. up to 5 ways that this software (Version i) is better than what was true BEFORE this software was written
- Proposes a better version for version i+1
- 3 to five implementation milestones, each of which takes version i+1 to a better place
- Note that these milestones have to demonstrate a possible implementation plan, with clear goals.
- Perhaps some milestones will be explored in parallel.
- Boasts your number of test cases (one group listed 130+, which is really cool since that means you can make new changes to the system while checking if the old stuff still works)
Ways to lose points:
- Your poster does not have the above features.
- Your poster fails to sell. Specifically:
- in the first 15 seconds or reading, the poster offers does not very clear understanding of what was going on (so good intro sentence)
- the poster does not make a case that this technology stack is interesting (e.g. “select this project so you can learn about kubernetes”)