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.
Week 6 Class 12 Thu Oct 03 Posted: Oct 03
Announcements
Class Meetings Tuesday, Oct 8 and Thursday, Oct 10
I will be in Flagstaff, Arizona, the week of Oct 7 - 11 for the 2024 ICSME (International Conference on Software Maintenance & Evolution). In addition to a paper at the conference, we are holding a srcML Meeting, which is required as part of our NSF grant.
Although I will be away, you will still have class. My RA, Mr. Kyle Rossi, is presenting, and there will be team exercises, with Mr. Rossi assisted by my TA Ms. Afia Assante.
My Office and Advising Hours are canceled on those days.
Iteration Plans
Do not leave space in an iteration because:
There is only one reason for having space left in an iteration: there is not another user story that would fit. If you use any of the above reasons to explain your iterations, I will deduct points.
Each student must get their own priorities. Do not reuse the ones from the Team Exercises.
Class
Demo: diff
and patch
on the Linux kernel
du -hs *
patch -p 1 < ../patch-6.11
Make
$@
, $<
, and $^
srccomplexity
Exercise 27: Makefile
Code along and make the same commits with the same commit messages as I do in class.
I suggest you use GitHub Codespaces as all necessary packages are installed.
Note: We did not get to any commits. So, it is not due. Wait until I get back.
Unless stated otherwise, all exercises are due by 3 pm on Fri Oct 04
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.
The first iteration ended. One of the user stories had an unexpected task, and it was large enough to delay the completion of that user story. Rewrite the first iteration to remove that user story.
Now, design a second iteration
Use the principles in the book to decide which of the remaining user stories belong in the second iteration.
Individually, each team member will turn in to Brightspace notes with the following:
Do not assume any dependencies between user stories.
The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone).
If you finish early, work on the estimates for your user stories. All user stories will require estimates for Project 2.
Week 6 Class 11 Tue Oct 01 Posted: Oct 01
Announcements
Class Meetings Tuesday, Oct 8 and Thursday, Oct 10
I will be in Flagstaff, Arizona, the week of Oct 7 - 11 for the 2024 ICSME (International Conference on Software Maintenance & Evolution). In addition to a paper at the conference, we are holding a srcML Meeting, which is required as part of our NSF grant.
Although I will be away, you will still have class. My RA, Mr. Kyle Rossi, will present, and there will be team exercises, with Mr. Rossi assisted by my TA Ms. Afia Assante.
My Office and Advising Hours are canceled on those days.
Project 1 Project 1 scores are in Brightspace. The feedback is in two parts in your Project 1 repository:
General Feedback:
Class
Unless stated otherwise, all exercises are due by 3 pm on Wed Oct 02
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
, Fixing
Fix
, not fix
Fix 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.
As a team, create the first iteration.
Ideally, we would have enough Team Meeting time to estimate all user stories using Planning Poker. However, we do not and almost all teams only have enough user stories for trivial iteration planning. To make up for this, I am providing estimates for the rest of your user stories. Enter the following:
Note: You may get a warning from your browser that the information is not secure. You can safely ignore that.
Add these estimates to your user story cards.
The other missing item are the priorities. These come from the customer. To get priorities, select the number of user stories:
Add these priorities to your user stories.
You have 1 developer and a one-month iteration with a 70% velocity.
Use the principles in the book to decide which user stories belong in the first iteration.
Individually, each team member will turn in to Brightspace notes with the following:
Do not assume any dependencies between user stories.
The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone).
If you finish early, use planning poker to work on more estimates for your user stories.
Week 5 Class 10 Thu Sep 26 Posted: Sep 26
Announcements:
Class
Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 27
As a team, take a user story that has an estimate, and create the tasks for that user story. Then, create the estimate for each task by playing planning poker using the procedure described on pages 48-49 of the book. Go through the estimation process at least one time.
When the team reaches a consensus for the estimate, place the estimate at the bottom of the task, e.g., "Estimate: 1 day" or "Estimate: 3 days".
Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:
If the team cannot reach a consensus, table that task and go on to another one.
The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone). The notes are for today only. Do not start with the notes from the previous team meeting.
The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements.
Week 5 Class 9 Tue Sep 24 Posted: Sep 24
Announcements:
Published - Feedback Read I spend time giving feedback and grades on the Team Exercises. This may be comments on current user stories (titles, etc.), assumptions, the planning poker procedure, etc. However, 50% of students never look at the feedback and continue to make the same mistakes on the exercises. There are even entire teams where no member looked at the feedback from the last team meeting.
One of the main topics of this course is processes that lead to successful and predictable outcomes. For exercises, this involves:
Class
Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 25
As a team, take a user story that has an estimate, and create the tasks for that user story. Then, create the estimate for each task by playing planning poker using the procedure described on pages 48-49 of the book. Go through the estimation process at least one time.
When the team reaches a consensus for the estimate, place the estimate at the bottom of the task, e.g., "Estimate: 1 day" or "Estimate: 3 days".
Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:
If the team cannot reach a consensus, table that task and go on to another one.
The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone). The notes are for today only. Do not start with the notes from the previous team meeting.
The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements.
Week 4 Class 8 Thu Sep 19 Posted: Sep 19
After Class
Announcements
Resume
If you bring a printed copy of your resume to me during my Office Hours on Thursday, September 19, I can review it and provide suggestions for improvement.
Project 1: Requirements Report
Class
Exercise 16: Commit to Project 1 Repository
Following the procedure given in the assignment and demonstrated in class, contribute at least one commit to the Project 1 repository. This must be a valid and useful commit.
git
CLI to make the commit. You can do this wherever you have the repository cloned. You can even do this in a GitHub Codespacegit
commits:
You can see your commit messages with the git log
command.
Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 20
Start by reviewing your user stories, particularly the titles. Titles that do not have an action term, or have a poor action term, will reduce your score on Project 1.
As a team, create estimates for the user stories by using the planning poker procedure described on pages 48-49 of the book.
When the team reaches a consensus for the estimate, place the estimate at the bottom left of the User Story as indicated by the example, e.g., "Estimate: 1 day" or "Estimate: 3 days".
Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:
If the team is not able to come to a consensus, table that User Story and go on to another one.
The notes are due by the end of class. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).
The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements. Also, you may think of additional user stories. Be sure to add them.
Week 4 Class 7 Tue Sep 17 Posted: Sep 17
After Class
Announcements:
Resume
If you bring a printed copy of your resume to me during my Office Hours or Advising Hours on Tuesday, September 17, or Thursday, September 19, I can review it and provide suggestions for improvement.
gh
to the image. Create a new codespace if you need it and it is not there.Windows File Explorer & WSL
To open the Windows File Explorer on the current directory in WSL:
If you open a path it has to be in Linux format, e.g., C:\Users\JohnDoe\Documents would be /mnt/c/Users/JohnDoe/Documents.
Dependencies
I see a lot of user story estimates where the assumptions include the completion of a previous user story. This is a dependency. Avoid dependencies at all costs. For example, Add … does not have to be completed before Delete …. Obviously there will be some dependencies, but they are to be at the user-story level, not the implementation level.
Estimates
Class
Exercise 16: Commit to Project 1 Repository
Following the procedure given in the assignment and demonstrated in class, contribute at least one commit to the Project 1 repository. This must be a valid and useful commit.
git
CLI to make the commit. You can do this wherever you have the repository cloned. You can even do this in a GitHub Codespacegit
commits:
You can see your commit messages with the git log
command.
Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 18
Your management is concerned that your team does not have a complete set of user stories. The first problem is low recall, i.e., the team is not capturing all the user stories the customer needs. The second problem is that without not enough work, the organization will have to let some of the team members go cut everybody's pay.
The customer met with their team and returned with a list of potential user-story titles. These possible new user stories fall into one of the following categories:
Code | Description |
---|---|
A | Already have as a user story |
N | Not a user story title |
P | New, but needs to be converted from plural to singular |
S | New, but needs to be split into multiple stories |
X | Not part of the description |
On the provided sheet, code each of the user stories into one of these categories.
Create a new user story, or multiple user stories, for each of these valid potential user stories. This includes fixing any title issues and adding a description. Also, take this time to fix any existing user stories.
Each team member will turn in both of the following:
If you have any additional time, then create more estimates. As you did before, keep track of details for the next team meeting.
Week 3 Class 6 Thu Sep 12 Posted: Sep 12
Announcements:
Engineering, Engineering Technology, and Computing Career Fair October 1 (Tuesday) from 10am to 3pm in Student Union. Pre-registration is open through Friday, Sept. 13, 2024, at 11:55 PM.
If you bring a printed copy of your resume to me during my Office Hours or Advising Hours on Tuesday, September 17, or Thursday, September 19, I can review it and provide suggestions for improvement.
Similar Action Words
Many action words are similar in meaning, but can vary in specificity or in details to what they imply.
Word 1 | Word 2 | Explanation |
---|---|---|
Remove | Delete | "Delete" often implies a permanent action, while "Remove" can be less final or reversible |
Accept | Approve | "Approve" generally has an authoritative connotation, while "Accept" is more general |
Connect | Invite | "Invite" is very specific, suggesting a request for participation, whereas "Connect" is broader |
Add | Create | "Create" is making something new, whereas "Add" means including something that already exists |
Register | Subscribe | "Subscribe" is ongoing engagement, while "Register" is often a one-time action |
Validate | Approve | "Approve" is a decision or permission, while "Validate" suggests checking or confirming correctness |
Link | Merge | "Merge" is combining into one, whereas "Link" connects them without combining |
Send | Submit | "Submit" is submission to a process, while "Send" is transferring information |
Pause | Stop | "Stop" is final, while "Pause" is temporary |
Stop | Cancel | "Cancel" is preventing something from starting or finishing, whereas "Stop" is halting an ongoing action |
Note that the customer may not realize the difference between these terms, and say one when they mean the other.
Keep Up
Class
Exercise 12: Create Project 1 Repository
Create your Project 1 Repository from GitHub classroom. Log into GitHub, then use the link on Brightspace to create your repository.
As you use the link, it will ask you to select your UA username (email address) from the list. Please do so carefully, and do not select the wrong email.
This is due by 3 pm on Monday, Sep 16
Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 13
Start by reviewing your user stories, particularly the titles. Titles that do not have an action term, or have a poor action term, will be counted off on your score for this exercise.
As a team, create estimates for the user stories by using the planning poker procedure described on pages 48-49 of the book.
When the team reaches a consensus for the estimate, place the estimate at the bottom left of the User Story as indicated by the example, e.g., "Estimate: 1 day" or "Estimate: 3 days".
Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:
If the team is not able to come to a consensus, table that User Story and go on to another one.
The notes are due by the end of class. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).
The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements. Also, you may think of additional user stories. Be sure to add them.
Note Include all user stories, even those without estimates. If a user story does not have an estimate, leave the estimate value blank.
Project 1 is due Friday, September 20, Monday, September 23 at 11:59:59 pm, in the file Requirements.md in a GitHub Classroom repository. You will need a GitHub account. Once you have an account, an invitation link to create the repository is on the Brightspace course page.
At your place of work, you need to submit a formal report describing the project's current state. Write a report of your individual and team activities, including these primary sections:
1. User Stories
User Stories with title, description, estimate, and space for priority
This will be shown to the customer. This section should not contain any information that a customer should not see.
2. General Process
Details of the overall process and procedure that created the Estimates
This will be shown to the customer, so only data on the User Story cards from section 1 should be shown.
3. Background Data
Details on spread, assumptions, issues, etc.
How did the team interaction work, and what did and did not work well
This will not be shown to the customer. It is for your supervisor.
In other words, the report describes all the work and processes followed while creating the user stories and their estimates. The details of the general process and the general observations in Section 3 are in the form of a narrative, i.e., describe what you did, how you did it, and the result, ordered by time. The report's tone is professional, with a clear, consistent presentation.
The team created the User Stories and Estimates, but this report is an individual project. In your account, make changes to User Stories if they do not follow the guidelines given in the book. These changes are especially crucial for the Title and the Description. Split User Stories if the Estimate is too large. Explain any changes in your report.
The report uses plain-text formatting syntax Markdown. Markdown is an almost universal format for text formatting in software development. Due to its direct conversion to HTML, Markdown has replaced HTML and other plain-text formatting languages in SE.
You will use git
to work on your report. Assuming a username of jdoe@uakron.edu
, the steps are as follows:
jdoe@uakron.edu
Note: All commits must have non-blank commit messages. Any non-blank commit messages will not be accepted, leading to a 0 on the entire project.
A GitHub Codespace is available for this project. See the guide GitHub Codespaces.
After you have committed your final change to the project, you must run your report through a report check to see if it follows many of the Markdown requirements of the project. To do so, create a GitHub Codespace for the project. When in there, enter the command:
You should see a clean report. If it finds anything, fix it and rerun the checkmd
command.
The checkmd
is a custom command created for this project to verify specific Markdown requirements. A clean run does not mean you have nothing wrong with your project.
Upload an terminal session of your report successfully passing the checkmd
program.
To demonstrate this, you will record a terminal session using asciinema. It records the commands you enter and the output the command produces. asciinema
is already installed in the GitHub Codespaces image. You can also install asciinema on Linux/WSL/macOS.
asciinema
is relatively straightforward to use.
You can play, pause, skip, etc. You can also copy the commands as text. Note that the replay even includes your pauses and any delay as the command is run.
At the end of the terminal session, asciinema
will show a URL. Anybody can use this URL to view the session. This is what you will submit for the exercise to the link in the exercise title. The URL should not contain "connect" or be a local file. Test your URL in a browser; an incorrect URL will receive a 0.
Submit the URL via this form: Project 1
The report content, format, and involvement in team activities are all considered for your score.
Think carefully about how you present the report, including using Markdown. Remember, the User Stories form an unordered set, not an ordered list.
Week 3 Class 5 Tue Sep 10 Posted: Sep 10
Announcements:
Action-Oriented Titles
The primary goal of user stories is to capture a specific need or goal of a user in the context of software development. It's about "what the user wants to do" or "achieve" with the software.
Benefits of Action-Oriented Titles:
User Story Titles and the Number Grammatical Category
Strongly consider using a title with a singular noun for a user story, instead of a title with a plural noun, because it emphasizes the atomic nature of the action.
Plural | Singular |
---|---|
Upload Documents | Upload a Document |
Send Messages | Send a Message |
Add Products to Cart | Add a Product to Cart |
Register for Events | Register for an Event |
View Notifications | View a Notification |
Search for Jobs | Search for a Job |
In general, user stories with singular titles are going to be easier to implement. There can be exceptions, as "View Notifications" may be simpler than "View a Notification" due to not having to select just one.
The most important aspect is clarity and understanding. If "Purchase Clothes" effectively communicates the intent without ambiguity and your team finds it more natural, it's also acceptable. The choice between singular and plural should ultimately be guided by what best serves the clarity and focus of the story in your context.
Class
Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 11
Your team is to correct the current user stories and increase the number of user stories. Very carefully go over your user titles and descriptions. Add more user stories and see what you are missing.
Remember to split any user stories that you can. Apply the "and" rule.
In addition to the team work of extracting user stories from the app description, each team member will turn in to Brightspace individual notes that includes:
The individual notes are due by the end of class uploaded to Brightspace. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).
Week 2 Class 4 Thu Sep 05 Posted: Sep 05
Announcements:
Pattern Recognition
Pattern recognition and adaptation are essential skills in software development. This involves closely following examples while adjusting them to fit specific needs, whether working with APIs, formatting code, handling data, or configuration. Lacking this skill can complicate development, introduce bugs, and waste development time.
Correct Format:
Firstname,Lastname,Email,Section,Team
John,Doe,johndoe@uakron.edu,020,Harpo
Missing field name row:
John,Doe,johndoe@uakron.edu,020,Harpo
Spaces that are not part of the data:
Firstname,Lastname,Email,Section,Team
John, Doe, johndoe@uakron.edu, 020, Harpo
Wrong section format:
Firstname,Lastname,Email,Section,Team
John,Doe,johndoe@uakron.edu,20,Harpo
Very wrong section format:
Firstname,Lastname,Email,Section,Team
John,Doe,johndoe@uakron.edu,CPSC480-020,Harpo
Priority At a mega-level:
Class
Exercise 7: HFSD Chapter 2 p42 User Story Interview
Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 06
Each Team is assigned a separate App with the description in Brightspace.
As a Team, create as many User Stories as you can for that app from the app description. For now, this is just the Title and the Description. The Title is just an action that a user can perform. The Description is from 1 to 3 sentences that describes what that action is. Follow the examples given in the book.
The User Stories are written on the provided index cards. I will provide a folder for you to put the cards in as I will collect the cards at the end of class.
In addition to the team work of extracting user stories from the app description, each team member will turn in to Brightspace individual notes that includes:
The individual notes are due by the end of class uploaded to Brightspace. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).
Week 2 Class 3 Tue Sep 03 Posted: Sep 03
Announcements:
Exercise 3: App Idea I posted scores and feedback in Brightspace
Following directions is important in any field, but particularly important in Computer Science.
The instructions clearly stated:
Class
Exercise 5: HFSD Chapter 1 Crossword
Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 04
Form a team of 4 members. The final team composition is at the discretion of the instructor.
After forming a team, your team needs to decide on a name from the following choices:
Pick at least 4 names.
Send Dr. Collard an email with the following:
CPSC480-020 Team
members.csv
, in the CSV (Comma-Separated Values) format. Use the following as an example:
Firstname,Lastname,Email,Section,Team
John,Doe,johndoe@uakron.edu,020,Harpo
Jane,Doe,janedoe@uakron.edu,020,Harpo
Brian,Doe,briandoe@uakron.edu,020,Harpo
Suzy,Doe,suzydoe@uakron.edu,020,Harpo
Harpo
Moe
Yoda
Zeppo
The purpose of a team is not just to divide the work but also to meet a required level of quality. All members of the team must check any team assignment in this course. You, as a team, are responsible for these directions. Any emails sent as part of an assignment (including exercises) must have the correct subject, CC list, and contents. Exercises are not accepted and do not receive points if they do not have the proper form and content.
The exercise is due by the end of class.
Week 1 Class 2 Thu Aug 29 Posted: Aug 29
Announcements:
Class
Exercise 3: App Idea - Submit via Brightspace in PDF form. Due by 3 pm on Mon, Sep 2
All applications start with an idea or a need. As a user, write a description of an application. The description should include who would use it and its features. The application can be one that you create yourself or an existing program.
Guidelines:
Comments:
Week 1 Class 1 Tue Aug 27 Posted: Aug 27
Announcements
Exercises
Exercise 2: Software Development Diagram
Draw the Software Development Diagram that I present in class. Upload a PDF or JPG through Brightspace.
All exercises are due by 3 pm on Wed Aug 28
Greetings and welcome to CPSC 480 Software Engineering (SE) section 020 for Fall 2024.
See you on Tuesday, Aug 27 at  2:00 - 3:15 pm in (CAS) room 134