Day 21

Day 06-09 (writing a requirements document)/CampusVisits.md

@@ -1,8 +1,8 @@
 
-# Campus visits
+# Campus visits requirements document
 
 Prepared by: Michael Kowalczyk  
-Revision date: 9/12/2024
+Revision date: 9/28/2024
 
 ## Overview
 
@@ -39,7 +39,6 @@ We would like a system to address the following:
         - *Faculty* - a user who can do campus visits for Computer Science.
     - *Available times* - (for faculty only) a weekly schedule of regularly available times for campus visits
 - Visit
-    - *Visitors* - a list of people in the visiting group
     - *Possible times* - a list of time intervals in which the visitors are available on the visit day
     - *Day* - the calendar day for which the visit has been scheduled with the campus visit office 
     - *DecidedTime* - the time at which the faculty member has agreed to meet for this visit
@@ -80,7 +79,7 @@ There are a few problem domain events of interest.  For each of these a source i
 - *ConfirmVisit* - the department secretary contacts the Campus Visit office that someone has taken the visit.  Parameters: visit's *decidedGuide* and *decided time*.  *Source:* department secretary (coordinator role).
 - *CancelVisit* - the campus visit office notifies the department secretary that the visit has been cancelled by the student.  *Parameters:* Visit.  *Source:* department secretary (coordinator role).
 - *AbaondonVisit* - some circumstance has caused the faculty member to vacate the guide position for a visit.   *Parameters:* Visit.  *Source:* faculty member.
-- *VisitTimePassed* - the *decidedTime* for the visit plus an hour has passed in Eastern Time.
+- *VisitTimePassed* - the *decidedTime* for the visit plus an hour has passed in Eastern Time; the visit is assumed to be completed.
 - *AdjustNotificationFrequency* - *Parameters:* Visit, numberOfDays.  Sets the frequency for periodic notifications to the given number of days.  *Source:* department secretary (coordinator role)
 - *SetCommittmentLevel* - a faculty member sets (or clears) their committment level for a particular visit.  *Parameters:* faculty, visit, level.  *Source:* faculty.  Invariant: The committment level must always be "can do" for the assigned guide, if any.
 - *EditAvailableTimes* - *Parameters:* faculty, subset of daytime hours for each weekday.  Sets the available times for that faculty member.

Day 21 (lifecycle models)/notes.md

@@ -0,0 +1,39 @@
+# Software development life cycles (SDLC)
+
+Here are several popular SDLC models:
+
+## Waterfall
+The waterfall model is best suited for well-defined complex projects, where problems can be spotted early and complexity is dealt with in an orderly way.  Key distadvantages include low customer visibility and low flexibility to mid-project changes.
+
+## Incremental development
+"Incremental" here refers to adding to the work products (requirements, source code, etc.) in stages.  In each stage, more functionality is added (core functionality first).
+
+## Iterative development
+In iterative development one iterates through the whole process (requirements →  ... → deployment) multiple times.  Iterative and incremental development often go together.
+
+## Spiral
+Spiral is a type of incremental and iterative development where risk assessment occurs at the start of each cycle.
+
+## Agile
+Agile is a form of incremental and iterative development with emphasis on frequent face-to-face communication, high customer visibility, adaptability to change, and minimizing non-software work products.
+
+## Evolutionary
+In an evolutionary model, deliverables are given to the customer frequently and incrementally.  The focus is on high-value features first and getting customer feedback early and often.
+
+## Code & Fix
+This is a kind of incremental development where life cycle phases other than coding and debugging (requirements analysis, software design,  testing, etc.) are skipped, and code refactoring is often neglected.
+
+## Prototyping
+This isn't really a life cycle on its own (although it can be adapted as such, as with "evolutionary prototyping").  Rather, it's a technique that is good for dealing with unclear requirements, assisting in communication, or in developing initial user interface design.
+
+# Questions guiding the choice of SDLC model
+This list is adapted from *Rapid Development* by Steve McConnell.
+- How well do the customer and development team understand the requirements?
+- How likely are requirements to change?
+- Are major archiectural changes likely?
+- Are there hard schedule constraints?
+- Are the relevant tools and technologies well-understood by the development team?
+- Is high visibility important to customers and/or management?
+- How will human factors affect the project (discipline, skills, training, and intellectual limits)?
+- What opportunities are there to parallelize work phases?
+

assignments.html

@@ -29,6 +29,19 @@
             <th>Value</th>
             <th>Description</th>
         </tr>
+        <tr>
+            <td class="center top">Friday 10/4/2024 9:00am</td>
+            <td class="center top">Reading</td>
+            <td class="center top">N/A</td>
+            <td class="top">Read section 2.3 starting with 2.3.1 (pg 39-50).  Read Chapter 3 up through and including section 3.3.  Also read 3.5.2, 3.6, and 3.7.</td>
+            <!-- Choose an agility principle from section 3.3.1 in the text (pg 69) and comment on whether and how it can be applied to each of the following lifecycle models: waterfall, iterative, incremental, spiral, evolutionary, code & fix.  -->
+        </tr>
+        <tr>
+            <td class="center top">Wednesday 10/2/2024 9:00am</td>
+            <td class="center top">Reading</td>
+            <td class="center top">N/A</td>
+            <td class="top">Read Chapter 1 of Pressman.  It's good stuff.</td>
+        </tr>
         <tr>
             <td class="center top">Friday 9/27/2024 10:00pm</td>
             <td class="center top">Milestone 2</td>