3 STORIES, TASKS, SPRINTS, BURNDOWN CHART § Burndown chart per sprint. § How many story points have you addressed per sprint? § How do you assign tasks? § Who did what? § How many story points are accomplished per team member (total)? § Review and Retrospective of Sprint 4 and full summary Part 1. The process
4 § NOT for the video. A link will be provided for this § (self and peer evaluation) What should be your grade and the grade of each of your teammates? (self and peer evaluation)
5 § BLUEPRINT, CODE, METRICS, DEPLOYMENT § Describe your architecture ( a diagram with boxes is fine) § Describe your design. Could it be easy for a new developer to reuse, modify or extend what you have created? § Show a class diagram (Explain it and describe the details) § Be sure the diagram and code match. § What components were developed by each team member? What were the criteria for splitting the work (components, classes, methods)? Part 2. The product
6 § Source code clean, DRY, and KIS § Code Metrics: LOC, eLOC, lLOC, CC § Structure Metrics: Abstractness, Instability, Distance § Does the product have a “good” quality? § What features were Unit Tested? § How many test cases are in total? § Coverage (statement, condition, condition-decision)? § Services? Part 2. The product
7 § What about Continuous Integration? § Did you implement and use GitHub Actions (or equivalent)? § Releases? § Docker? § Libraries? Part 2. The product
8 § Not for the video a link will be provided § What should be the team grade for the product accomplished – consider functionality, code, and quality. Does it have value for the customer? (self and peer evaluation)
9 a) Final Version of your Source Code - submit your Java files b) Software Design - your UML class diagram c) Screenshot of your Backlog, Task board, and your Burn-down Chart from Taiga d) Links to your GitHub repository and Taiga project site f) Metrics (Code and Structure) e) Link to your video of the Final Presentation Wednesday, June 12
13 § Independent – loosely coupled with one another § Negotiable – Stories are what and why , not how ( 99% ). § Valuable – for the customer! § Estimatable – Effort/Cost of design, build, and test. § Small (sized appropriately) § Testable – pass or fail INVEST in good requirements
22 § Students and Staff members can request the Library to notify him/her when a Book becomes available. § Also, they can reserve the book. Before reserving a Book for someone the Library check, for students, with the Registrar, if the Student is currently enrolled, and for employees, with Human Resources if the employee has an active contract. Case 3
23 § Students and Staff members can request the Library to notify him/her when a Book becomes available. § Also, they can reserve the book. Before reserving a Book for someone the Library check, for students, with the Registrar, if the Student is currently enrolled, and for employees, with Human Resources if the employee has an active contract. Case 4
24 § Students and Staff members can request the Library to notify him/her when a Book becomes available. § Also, they can reserve the book. Before reserving a Book for someone the Library check, for students, with the Registrar, if the Student is currently enrolled, and for employees, with Human Resources if the employee has an active contract. Case 4
31 Given a Date class with the following methods: opublic Date(int year, int month, int day) opublic Date() // today opublic int getDay(), getMonth(), getYear() opublic void addDays(int days) // advances by days opublic int daysInMonth() opublic String dayOfWeek() // e.g. "Sunday" opublic boolean equals(Object o) opublic boolean isLeapYear() opublic void nextDay() // advances by 1 day opublic String toString() § Come up with unit tests to check the following: oThat no Date object can ever get into an invalid state. oThat the addDays method works properly. • It should be efficient enough to add 1,000,000 days in a call. JUnit
32 public class DateTest { @Test public void test1() { Date d = new Date(2050, 2, 15); d.addDays(4); assertEquals(2050, d.getYear()); // expected assertEquals(2, d.getMonth()); // value should assertEquals(19, d.getDay()); // be at LEFT } @Test public void test2() { Date d = new Date(2050, 2, 15); d.addDays(14); assertEquals("year after +14 days", 2050, d.getYear()); assertEquals("month after +14 days", 3, d.getMonth()); assertEquals("day after +14 days", 1, d.getDay()); } // test cases should usually have messages explaining } // what is being checked, for better failure output Junit + Coverage
38 § What? The practice of automating the integration of code changes from multiple contributors into a single software project. Continuous Integration (CI) https://www.pagerduty.com
45 # Environment variables for MySQL ENV MYSQL_ROOT_PASSWORD=root ENV MYSQL_DATABASE=yourdbname # Start MySQL and the Java application CMD service mysql start && \ sleep 10 && \ mysql -u root -proot yourdbname < /docker-entrypoint-initdb.d/init.sql && \ java -jar /app/your-app.jar Dockerfile
Fall 2022 Copyright. These slides can only be used as study material for the class CSC308 at Cal Poly. They cannot be distributed or used for another purpose.
javiergs
zsmb
harunatsujita
petamoriken
manfredsteyer
maruto
yusukeito
qnighy
hollycummins
righttouch
seike460
ivargrimstad
marokanatani
ufuk
tammyeverts
denniskardys
lemiorhan
smashingmag
lauravandoore
samanthasiow
chrisshort
tanoku
notwaldorf
reverentgeek
ddemaree
![jgs CSC 308 Software Engineering I Javier Gonzalez-Sanchez, Ph.D. [email protected]](https://files.speakerdeck.com/presentations/e29318a7ef394ebb8d26eb234fa50412/slide_49.jpg){kind=link}