News
-
Week 8 Class 15 Tue Oct 14 Posted: Oct 14
Announcements
- Office Hours For today, Office Hours are 10:30 - 10:45 am and 3:15 - 4:15 pm
-
Project 2 The
checkmdrequired a file called Requirements.md. To use this with IterationPlan.md, we needed to remove this restriction fromcheckmd.This changed
checkmdis now in the image mlcollard/checkmd, which you get when you run a GitHub Codespace. If you have an existing GitHub Codespace for Project 2, you will have to create a new codespace to get this change. -
Project 2 Keep in mind the following:
- Each plan includes all user stories
- Carefully check your calculations, including the numbers you are using
- The unit of granularity for an iteration plan is an iteration, not day-by-day
- Do not assign work to each developer
- Project 2 Grading I will post some type of preliminary feedback on your plans by end-of-day on Wednesday. See the "After Class" on Wednesday for details.
- Midterm Exam
-
In your repository the branch feedback in the file Feedback.md is a Claude (LLM) analysis of the team history for Exercise 33: Team Text Match. I suggest viewing it at GitHub.
Some observations regarding team collaboration and outcomes:
- All team members should have a basic understanding of the technology used. In this case, for building programs: compiling, linking, options, etc. For Make, how to write rules. Some research might be needed, and while some team members may know more about particular points than others, everyone must have a fundamental understanding.
- All changes must be verified by any means necessary. Many commits included modifications that would cause an error when
makeis run. Not every team member did this. - It was necessary to coordinate who was doing what. The team was in person at the same time, so this should have been straightforward. Consider what would happen if the team were distributed across different work schedules.
- Allowing the team to only work on the program sequentially wastes (n-1)/n of the potential. There was no reason why the two executables,
textmatchandregexCountTest, couldn't be worked on in parallel. Declarative languages are easier to work on independently than other types of languages due to simpler structures. E.g.,makeis easier to work on independently than C++. - The team cannot afford even one member who makes unverified commits, submits changes that aren't aligned with other work, or has limited foundational knowledge.
Class
-
Make Prerequisites
Make prerequisite graph for srcComplexity:
- HFSD Chapter 7
-
Exercise 34: Team Text Match II
- build-files-020
- GNU Make
- Make Rule Introduction What a rule looks like
- Automatic Variables including
$@,$<, and$^
-
Exercise 34: Team Text Match II Posted: Oct 14
In your repository the branch feedback in the file Feedback.md is a Claude (LLM) analysis of the team history for Exercise 33: Team Text Match. I suggest viewing it at GitHub.
Read over the analysis and think about what can be improved, not only about your current version of the code, but also about your process. Even if your process worked and you did well, consider how you can parallelize your development (instead of waiting while someone else makes changes).
Follow the instructions for Exercise 33: Team Text Match
The targets from last time were:
make clean,make run,make testOnce you have all those targets implemented, implement the following:
-
Add the target
manpage, i.e.,make manpage, that creates a man page. This was added to the build-files-020. Note that my example also added a comment. The manpage will be namedtextmatch.1. It is generated from the markdown filetextmatch.1.md. This conversion uses the commandlowdown. It is not installed in your GitHub Codespace. However, you do have the permissions to install it. First, updateThen install the package:
If you are in WSL, you need to use
sudobefore each command. On macOS,brew install lowdown - Add the target
man, i.e.,make man, that views the created manpage. This was also added to the build-files-010, and it has its own comment. - Add a comment to the
textmatchexecutable and its object files. - Add a comment to the
regexCountTest.cppexecutable and its object files. - Add a comment to the
cleantarget - Add a comment to the
runtarget
As before, this is due by the end of class. No commits outside of class.
-
-
Midterm Exam Posted: Oct 09
The Midterm Exam is Thursday, October 16, during our regular class time and classroom. It covers Chapters 1 - 6.5 of the Head First Software Development book, plus notes and in-class examples.
- Big Bang approach to development - description, the path it takes, and disadvantages
- Iterative approach to development - description, the path it takes, and advantages
- Role of the customer/client
- User Stories - all parts, description, creation, valid user story titles
- Estimates and the Estimation Process, including all details of planning poker
- Iteration and deadline planning
- Utopian vs. Real-World days
- Velocity - description, standard rate, what does it mean if velocity is higher or lower
- Big Board - basics of what it shows and how developers use it
- Good-enough design, SRP, DRY
- Version control - jobs that it does, commit messages, branches (specific git information not on this midterm)
- Role and importance of build artifacts (code, configuration, tools), the general purpose of
makeandcmake; 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:
- Explain a process or terminology of a process
- Answer specific questions about parts of the process. E.g., "Explain why the recommendation is to come up with user stories whose estimates are 15 or less."
- Explain what process and activities you would follow for a particular scenario
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.
-
Project 2: Iteration Plan Posted: Oct 02
Project 2 is due on Tuesday, Oct 14 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:
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 iteration 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 anasciinemasession, all of those requirements of Project 1 are also in effect for Project 2.Submit the URL via this form: Project 2