TR 12:15 - 1:30 pm (CAS) 135
Week 7 Class 13 Tue Oct 08 Posted: Oct 08
Announcements
Dr. Collard: Out of Town
Dr. Collard is in Flagstaff, Arizona, for 2024 ICSME. He cancelled his Office and Advising Hours this week. He is available via email.
Mr. Kyle Rossi is teaching class this week.
Class
Exercise 27: Team Use Case Diagram
Create a Use Case Diagram for your project. Use the user stories as use cases. Select up to 10 of your user stories. You may have to cut down the title of a user story for the use case.
Use yuml.me to draw the diagram.
Each member of the team must either create their own diagram at yuml.me, or draw a diagram on paper.
By the end of the class period, upload to Brightspace a PDF of the diagram, or a photo of your hand-drawn diagram.
Note: I removed Chapter 6.5, cmake, and make from the Midterm. It will be on the Final Exam instead.
The Midterm Exam is Thursday, October 17, during our regular class time and classroom. It covers Chapters 1 - 6 6.5 of the Head First Software Development book, plus notes and in-class examples.
make and cmake; Given a Makefile, what would happen with specific targets.The exam has various problem types, including short answers, definitions, comparisons, creation of user stories, and planning. The question may require you to:
It is a good idea to review the "Dumb Questions" and the answers.
The questions are based on what we covered in the book, the exercises, and the projects. If I did not cover it in class, it is not on the exam.
A calculator is not needed for any required math and, therefore, not permitted.
This exercise is optional. However, completing this exercise will add points to your Project 1 score.
The exercise is due by Tuesday, Oct 8 at 11:59:59 pm EDT.
In your repository for the Requirements Report is the file Corrected.md. This is an edited version of what you submitted with fixes and improvements to the writing.
To see the difference between these two files, you can use the diff command:
The diff utility is line-oriented. Since many of your lines are quite long (the lines are wrapped when you view them), this may be difficult to read. You can also use the wdiff command:
The codespace for Project 1 has diff and wdiff installed. You will have to start a new codespace to use wdiff.
If you want to use wdiff outside of a codespace, install on WSL/Linux apt-get update; apt-get install wdiff, and on macOS brew install wdiff.
Your workflow must be the following:
Each correction must be a contiguous change. That means that each commit only contains one correction. Practically, this means that each correction/commit will be on a single line.
To get credit, your resulting Requirements.md file must be exactly the same as the Corrected.md file. You will reach this stage when diff shows no differences.
The git commit messages must be in the proper form, such as:
The commit messages must following good git commit message guidelines:
Fix, not Fixed, FixingFix, not fixFix spelling of "calendar", not Fix spelling of "calendar".The score on this exercise will be 0 if the commit messages do not follow the above guidelines, or there is no effort to use an appropriate commit message.
Note:
There will be a lot of commits, so you want to be efficient creating them. After you do the first few corrections, you can push to GitHub and verify at GitHub periodically and not every time. And, to save time with entering commands, bring up previous commands in a shell using the up arrow ⇧ or Ctrl + P, and edit the git commit messages if necessary.
Project 2 is due on Tuesday, Oct 15 at 11:59:59 pm. A GitHub Classroom invitation link is on the Brightspace course page.
For Project 2, take all the user stories from Project 1 and create a series of iteration plans.
Use the examples in the book to show which parts of the user story you should show in your iteration plan (e.g., do not restate descriptions in the plans). Also, clearly state the entire new iteration plan for each plan, not just the changes. However, make sure to thoroughly discuss what the change was and what effect it had.
This is an individual project. Each member of a team has different user-story priorities. To get individual priorities for Project 2, select the number of user stories:
Note: You may get a warning from your browser that the information is not secure. You can safely ignore that.
Put these in the Priority field in the order in which you listed the user stories. In the report, do not discuss how you generated your report's priorities, i.e., pretend that the customer gave them.
The following plans may require you to add additional user stories. This violates our rule that only the development team can create estimates. However, as part of the exercise, put in an estimate.
Each plan is a point in time. For each plan, show the entire estimation plan, including the iterations already completed.
| Plan | Events |
|---|---|
| 1 | Create an initial iteration plan: 2 Weeks (14 calendar days) iteration, 2 developers, 0.6 velocity |
| 2 | The customer adds two new user stories of the highest priority at the end of the first iteration. For the two new user stories, one is a new feature, and one is an emergency. Create a non-trivial estimate (i.e., an estimate that makes the planning interesting) for these new user stories. |
| 3 | A user story with a non-trivial estimate takes twice as long. Assume this occurred right before the last iteration. |
| 4 | At the beginning of the last iteration of your current plan, the other developer leaves for another project, and it is up to you to finish the project. |
After the plans, create a section with all of your user stories, including their titles, descriptions, estimates, and priorities. You will need estimates for all of your user stories.
Regarding the format, GitHub Codespaces, checkmd, and a Final Check with an asciinema session, all of those requirements of Project 1 are also in effect for Project 2.
TA: Ms. Afia Asante aa998@uakron.edu