List view
### Write an individual retrospective Write a 1-2 page retrospective (on your own) of lessons learned from the project experience. The lessons can be in terms of specifications, design, planning, implementation, tooling, teamwork, etc. Below are some questions that you might answer, though the format and specifics are up to you. You will be graded on the thoughtfulness, insights, and justifications of your answers, not on what you actually believe. Example questions: What worked well? What would you do differently next time? What do you wish you had known ahead of time? What surprised you? What do you now believe that you did not believe at the beginning of the quarter, and why? What ideas taught in class do you still not believe, and why? What advice would you give future CSE 403 students? Are you happy/proud of the work you completed? If not, why, and what could you (not others) have changed so that you were happy/proud of your accomplishments? Do you think others on your team feel the same way?
Overdue by 2 year(s)•Due by June 6, 2023•2/2 issues closed### Finalize your project Complete the implementation of your project in your GitHub repository. Based on the provided instructions in the top-level README.md file, anyone should be able to understand the purpose of the project and easily find instructions for building, testing, and running the system without issues. You are also expected to address the feedback from the peer review comments. Complete this in the main branch of your repository by due date. ### Record a demo and group reflection Record a demo and group reflection presentation that’s 16-20 minutes long and in which all members participate in some way. Your presentation should have two parts: The actual demo of the system (8-10 minutes). Focus on the final system and how a user interacts with it for the majority of this time; afterwards, you may also highlight some key accomplishments and technical challenges. A reflection on the overall group project (8-10 minutes). This part of your presentation should address and reflect on the following: * _Features and cuts_: Have you completed the major functionality and features listed in your original requirements document? What about the extra features (stretch goals) you listed? Did you add any additional features during the project that were not listed in your original requirements document? If you did not implement all features, why not? What features did you cut to help you complete the project in time, and why did you choose these to be cut? How much work do you estimate you saved by cutting these features? * _Roles and responsibilities_: What ended up being your team members' current roles? How does this differ from your original expectations and specifications? * _Process and timeline_: Did you change your software developement process model? What occupied the majority of each team member's time and workload? How does this differ from your original expectations and specifications? Where did you spend too much time, and why? Where did you spend too little time, and why? * _Testing and tooling_: How much time have you spent on testing; how much time have you spent on code reviews? Would you increase or decrease the amount of time spent on each, and why? What issues (bugs, invalid assumptions, etc.) did the peer-review process reveal? What would you change to identify and address issue earlier in the future? * _Planning and estimates_: Briefly contrast what you ended up doing with your original plan and estimates. For example, your weekly progress reports and the version control logs are a good starting point for determining how each member has actually spent their time and how long it took to implement each feature -- these may be very different from your original estimates. You will not be graded on your original estimates, nor on whether your overall development process matches the one described in your original specification.
Overdue by 2 year(s)•Due by May 30, 2023•7/11 issues closed- Overdue by 2 year(s)•Due by May 23, 2023•2/3 issues closed
### Make progress in your public GitHub repository Each group member must contribute to the code base. Each group member must demonstrate proper use of version control and CI. Each contribution (commit/pull request) must be tested, commented, and code reviewed. Complete this in the main branch of your repository by due date. ### Write user documentation Your public repository must contain a complete user manual (the wiki page!!!). Anyone looking at your repository should be able to easily find the user manual. The user manual is focused solely on people who want to use your project. The user manual should describe the functionality of your project as you expect it to be at the end of the quarter. For this assignment, indicate missing functionality as work in progress. The user documentation should include at least the following information: A high-level description. What does the system do and why would a user want to use it. How to install the software. If your system has prerequisites (e.g., tools, libraries, emulators, third-party applications, etc.), your instructions should list all of them and indicate how to install and configure them. Make sure to indicate what specific version requirements these prerequisites must satisfy. If running the system requires the installation of, e.g., a virtual machine, a database, or an emulator, make sure to provide clear step-by-step instructions. How to run the software. How to start up the system? How to use the software. You can assume that your user is familiar with your particular platform (e.g., use of a Web browser, desktop applications, or mobile applications). For missing functionality, your documentation should simply indicate that this functionality is work in progress. How to report a bug. This should include not just the mechanics (a pointer to your issue tracker), but also what information is needed. You can set up a bug-report template in your issue tracker, or you can reference a resource about how to write a good bug report. Here is an example for bug reporting guidelines. Known bugs. Known bugs or limitations should be documented in the bug tracker. A user testing the implemented use case(s) should not encounter trivial bugs (e.g., NPEs) or a large number of bugs that are unlisted in your bug tracker. Complete this in the main branch of your repository by due date. ### Developer documentation Your public repository must contain developer guidelines (also in wiki!!!). Anyone looking at your repository should be able to easily find these guidelines. The developer guidelines are focused solely on people who want to contribute to your project. The developer documentation should include at least the following information: How to obtain the source code. If your system uses multiple repositories or submodules, provide clear instructions for how to obtain all relevant sources. The layout of your directory structure. What do the various directories (folders) contain, and where to find source files, tests, documentation, data files, etc. How to build the software. Provide clear instructions for how to use your project’s build system to build all system components. How to test the software. Provide clear instructions for how to run the system’s test cases. In some cases, the instructions may need to include information such as how to access data sources or how to interact with external systems. You may reference the user documentation (e.g., prerequisites) to avoid duplication. How to add new tests. Are there any naming conventions/patterns to follow when naming test files? Is there a particular test harness to use? How to build a release of the software. Describe any tasks that are not automated. For example, should a developer update a version number (in code and documentation) prior to invoking the build system? Are there any sanity checks a developer should perform after building a release? Complete this in the main branch of your repository by due date.
Overdue by 2 year(s)•Due by May 16, 2023•19/19 issues closed### Solidify your toolchain, processes, and instructions All technical processes (version control, bug tracking, build system, testing and CI) must be fully functioning and documented. We expect proper use of version control, including coherent commits with descriptive commit messages. Your public GitHub repository must provide a top-level README with: Clearly labeled instructions for how to build and test the system. (Strive for a high degree of automation.) Clearly labeled instructions for how to run the system. Based on the provided instructions, the course staff must be able to build and test the system without issues. Complete this in the main branch of your repository by deadline. ### Implement and integrate first versions of all your system’s major components Implement and demo a first prototype. At least one use case that touches all major components of your system must be operational. For example, in the case of a client-server web application, a user command invoked from the front end should be able to return data from the back end. The top-level README in your repository must reflect which use case(s) are operational. Complete this in the main branch of your repository by deadline. ### Record a short demo and reflection Your presentation should have two parts: A demo of your prototype (9-11 minutes). Focus on the operational use case(s), highlight major accomplishments, and discuss open challenges. A reflection on the current experience (3-4 minutes). This part of your presentation should include three slides that reflect on (1) process and timeline, (2) architecture and design, and (3) testing and tooling. For each, briefly motivate your initial plan and state whether you made changes, and if so what they were. Further requirements: Each group member must participate in some way in the presentation. You must stick to the timeline of 12-15 minutes. If appropriate to make your demo more realistic, you must pre-populate any database or other data source with an amount and type of (possibly faked) data that a typical user would see.
Overdue by 2 year(s)•Due by May 9, 2023•24/24 issues closed