\PassOptionsToPackage{unicode=true}{hyperref} % options for packages loaded elsewhere
\PassOptionsToPackage{hyphens}{url}
%
\documentclass[]{article}
\usepackage{lmodern}
\usepackage{amssymb,amsmath}
\usepackage{ifxetex,ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[T1]{fontenc}
  \usepackage[utf8]{inputenc}
  \usepackage{textcomp} % provides euro and other symbols
\else % if luatex or xelatex
  \usepackage{unicode-math}
  \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
\fi
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage[]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
}
\usepackage{hyperref}
\hypersetup{
            pdftitle={CSci 487 Senior Project, Spring 2018 Postmortem},
            pdfauthor={H. Conrad Cunningham},
            pdfborder={0 0 0},
            breaklinks=true}
\urlstyle{same}  % don't use monospace font for urls
\setlength{\emergencystretch}{3em}  % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{0}
% Redefines (sub)paragraphs to behave more like sections
\ifx\paragraph\undefined\else
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\fi
\ifx\subparagraph\undefined\else
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\fi

% set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother

\usepackage{caption}
\DeclareCaptionLabelFormat{nolabel}{}
\captionsetup{labelformat=nolabel}

\title{CSci 487 Senior Project, Spring 2018 Postmortem}
\author{H. Conrad Cunningham}
\date{22 May 2018}

\begin{document}
\maketitle

\hypertarget{senior-project-postmortem}{%
\section{Senior Project Postmortem}\label{senior-project-postmortem}}

The following aggregates the items I listed in the series of emails with
the subject line ``Senior Project Postmortem, Part n''. I preserve the
stream-of-consciousness order of items from those emails.

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{-1}
\item
  (Added) Changes made in Spring 2018 from most previous offerings

  \begin{itemize}
  \item
    assigned a TA to help the instructor with his 32 students
  \item
    dropped the separate Bibliography assignment
  \item
    replaced the License Agreement assignment with a modified version of
    ORSP's Undergraduate Capstone Survey form
  \item
    divided Design Specification into an initial and a revised
    submission
  \item
    required explicit specification of a Minimum Viable Product
  \item
    required use of version control software
  \end{itemize}
\item
  Research-related projects

  If a student undertakes a research-related project rather than an
  application (as more and more are doing), then the student's final
  report probably should include some appropriate record of the
  ``research product'' not just materials about the software/hardware
  system assembled to carry out the research.

  For example, if the student carried out an experiment and collected
  data, there should be appropriate plots, analyses, etc., in a short
  ``scholarly'' paper as a part of the final materials.

  A special case is probably an Honor's College student whose thesis and
  project are combined. We probably want the thesis as well as the usual
  documents requested.

  We may want to talk about this issue in a faculty meeting early in the
  Fall.
\item
  Version control

  One new \textbf{required} component Armando suggested this semester
  and I made part of the course was use of version control (e.g., git
  using a server on the network).

  The result was mixed. A number of students (who had 387 in 2017 or
  2018 or who just learned it for 487) did well, a few used version
  control some but not all that effectively (infrequent commits or many
  just at the end) and a few chose not to use version control. This
  latter group including some who had 387 but maybe did not learn
  effective use of version control, some who did not have 387 (e.g.~BA
  majors) or took 387 in 2016 or earlier, and some who just did not want
  to be bothered with this requirement.

  In general, I think requiring use of version control was a reasonable
  step (e.g., to avoid disasters when laptops die and perhaps most of
  the students will need to use it after graduation).

  But many of us (including me!) need to learn how to use it or use it
  more effectively. We may need to introduce some explicit version
  control training.
\item
  Turing software (for Web and database development)

  A few students use our server Turing to develop web applications that
  may be migrated to client servers. At least one student commented that
  the older version of PHP on Turing caused some issues because his
  client had a newer version. (I mentioned this to Jeff before I sent
  the orginal email.)

  We probably need to better define what software we plan to support on
  Turing and have that software base on the same kind of regular update
  schedule as the Adler labs.
\item
  Requirements elicitation and analysis

  Some of our students are reasonably skilled at eliciting and defining
  the requirements for fuzzily-defined software and database projects
  ``in the wild''. Most are not.

  Some worked for half the semester or longer on the wrong things.

  We do not have a systems/requirements analysis course. I suppose we
  cover some aspects of this in 387, but not all students practice that
  in group projects where others probably take the lead on particular
  aspects.

  Perhaps as we define the new core course and shift some content
  around, we need to consider whether we can address the requirements
  elicitation and requirements/domain analysis issue.
\item
  Remote sponsors

  5 of the 32 projects had sponsors outsideof Lafayette county -- 3
  where students came of up projects on their own (McConnell, Logan,
  Rankins) and 2 from the list that we suggested (Conway, Calhoun). All
  of these had some issues related to the remote nature of the project,
  although these issues could also happen on campus.

  We may want to consider to what extent we want to allow or encourge
  such projects in the future.
\item
  Sponsor/user interaction

  In most cases, there was limited interaction between the sponsor and
  the student. Most sponsors complained about this on the evaluation.
  Much of this is that the student did not choose to meet with the
  sponsor much -- because they were making slow progress or thought the
  project was easier/different than it was or the student was really the
  sponsor himself/herself. In some cases sponsors were hard to get a
  response from.

  Perhaps the instructor should talk with the sponsor up front if not a
  person we know.

  Perhaps there should be more required interactions between student and
  sponsor.

  By the way, students who got feedback from a variety of users tended
  to make the product better (e.g.~Jesse Coleman).
\item
  Deployment systems

  In many cases (particularly for web applications) students and
  sponsors did not give sufficient attention to where the system would
  be deployed -- despite my explicit warning about this problem.

  At the end of the semester, we still had a number of projects on
  either Turing or local-hosts with no deployment target yet identified.
  Some of these may never be deployed as a result.

  Sometimes this resulted in poor technological choices on the part of
  the student. Students chose a language or framework that was not
  supported on the likely available servers.
\item
  Testing

  In general, students did not test the systems sufficiently well.

  This was particularly a problem where the project was a piece of a
  larger system that was under development by others (e.g.~McConnell) or
  the project involved enhancing an existing system (e.g.~Feaster).

  I found in CSci 450 last semester that many of our students are not
  quite sure how to go about testing systematically (even though many
  had used JUnit some in 211 or other courses). The ones who have had
  internships in software development shops do this better than those
  who have not. (In CSci 450, I expected the students to test their
  Haskell program. I did not provide a testing framework or give
  explicit instruction on its use.)
\item
  Selecting a project early

  Most students wished they had selected a project before the semester
  began.

  Of course, that would mean that the project selection is less under
  the control of the course instructor, unless the instructor wants to
  give involved earlier.
\item
  Smaller, quicker, more specific deliverables

  My version of the course had the usual deadlines for certain documents
  and gave general guidelines for those documents, but some students
  wished for more specific guidance to keep them on track.

  We can probably do some better in defining what we want, but dealing
  with their own schedule is part of what we want students to master.
  And, of course, each project is unique, so the specific deliverables
  differ among them.
\item
  One-on-one meetings

  I had Armando as the TA. We scheduled two required meetings with
  Armando. He and I also have open office hours. I held the class
  meeting and asked for verbal reports 2 or 3 times.

  Some students failed to show up for at least one of the meetings with
  Armando. Others commented that a 3rd meeting would have been helpful.
\item
  Journal entries

  I used the Blackboard journal feature but gave few guidelines to what
  to report. (And I did not examine the journal entries sufficiently
  frequently.)

  Perhaps replacing this free-form journal with a list of specific
  questions they are expected answer would be helpful.
\item
  List of resources for student projects

  At least one student suggested an up-to-date list of Department or web
  resources (tutorials, tools, etc.) available to support student
  projects would be helpful.
\item
  Choosing technologies

  Some students are good at choosing technologies to use. Many have to
  meander around quite a bit before they settle on the technologies to
  use -- often changing after the design spec.

  Some students try to learn too many new technologies and then use them
  to carry out the projects. Some did this successfully, but others used
  so much time on trying to learn the tools that they had little time to
  actually do the project.

  A few might have been overly conservative, choosing only technologies
  that they were familiar with. They could have had more interesting
  projects and could have learned more if they had taken a few more
  risks.
\item
  Unclear schedule

  A few students complained that I had not made the schedule
  sufficiently clear.

  Part of this stemmed from the changes we made to the course and my
  lack of making all the needed changes at the beginning of the
  semester. (``My bad''.)

  The schedule was on my website and I made Blackboard/email
  announcements, but I hesitated bombarding the students with too many
  routine announcements.
\item
  Proactivity

  Some students were insufficiently proactive when dealing with
  non-technical sponsors. They tried to deliver what the sponsor wanted,
  without necessarily exploring design/technology options and presenting
  them to the sponsor. (Of course, some students chose technologies
  without considering issues such as deployability or long-term
  support.)
\item
  Bibliography

  We eliminated the Bibliography assignment, which I think was good in
  theory, at least in that it encouraged students to push into design
  earlier.

  However, most students did not document their Final Report in a
  scholarly fashion with a list of references (despite an indication
  they should do so).
\item
  Documentation of code

  Most students do not document code internally.

  Perhaps we do not stress this as much in our courses as we did a
  quarter century ago.
\item
  Database

  Most students do not do a particularly good job of analysis and
  database design. At least more students seem to have had database or
  were in it this semester than in some past years.

  Armando's suggestion of the use of the Firebase NoSQL database seems
  to have been good for those doing mobile apps and some web apps.

  I hope the new core course will help this aspect in the future.
\item
  Design Specification

  With the elimination of the bibliography assignment, I split the
  design spec assignment into an Initial and a Revised Design
  Specification. I think this was helpful. (Armando gave feedback on the
  initial spec; he, the other students, and I gave feedback during the
  mid-semester Design Presentations.)

  At Armando's suggestion, we also required a \emph{Minimum Viable
  Product} MVP) in this spec. Good idea! But many students had trouble
  knowing what this meant and in defining one for their project --
  defining either too large or too small an MVP.
\item
  Undergraduate Capstone Project Form

  I required this after Spring Break. It would have been better before
  Spring Break along with the Revised Design Specification.

  It was hard extracting these from some of the students. One student of
  the 32 never did it.

  I did not send these to ORSP. In maybe 4 cases where the sponsor kept
  the intellectual property, I should have.
\item
  Web design

  Some students spent waaaay too much time on the front-end, leaving
  insufficient time to do the server-side.

  Some students felt poorly prepared to do the full-development of a web
  app -- client side, server-side, database, deployment on a server --
  from the courses they had taken.
\item
  Final submission

  We have required submission of the final report as a bound paper
  document with the source code on some electronic medium such as flash
  drive, CD, or DVD.

  I had this in writing, but I probably did not remind the students as
  much as needed. So there was some confusion.

  I like to grade from paper, but there are a lot of documents to manage
  when the class is 25+ as we have had most semesters for the past 3
  years.

  Perhaps if we require version control in a place where the instructor
  and sponsor can access it, the submission of electronic media can be
  eliminated.
\item
  Seeking help

  Despite Armando and me being available during our office hours, few
  students came. \ldots{} However, many students bugged Kristi or Dawn
  about databased design. Thanks for helping them!

  Some students were almost pathological about trying to do everything
  themselves, without asking for any help. This resulted in some
  students risking complete failure, when a little bit of help could
  have made them quite successful.

  Of course, we sometimes have the opposite problem where students are
  helped too much or students who copy the work of others.
\item
  Curriculum issue: Object orientation

  One student made an interesting comment: He felt he had been taught
  the ``how'' of OO programming reasonable well, but he felt there had
  not been much talk about the ``why'' of OO programming.
\item
  Curriculum issue: Systems courses

  A few students complained about the lack of systems courses --
  particularly ``practical'' systems courses where they would know more
  about system admin issues related to things like deploying web apps,
  etc.

  Maybe more frequent offerings of CSci 323 will help this.
\item
  Curriculum issue: Required internships

  (: One or two students suggested there should be ``required''
  internships. :)
\item
  ``Close to the bare metal'' programming

  Several students did projects where they needed to understand and
  develop software that worked at a low level.

  Those that worked with Adam seemed to handle that aspect sufficiently
  well, but those that worked with outside sponsors struggled with that
  kind of programming. Saying, in retrospect, they did not feel they
  were well prepared by their coursework for their projects.

  One (Nguyen) handled that very well! Another (Conway) had mixed
  results.

  Can we prepare our students better for such projects?
\item
  Doing senior project with very heavy workloads

  One student was taking 23 hours, working part-time, and commuting from
  Tupelo. (Needless to say this student did to attend class frequently.)

  Another student had an ordinary load but was working essentially
  full-time. Others had heavy coursework including courses like 387,
  433, and 475. Etc. Some of the latter were students who changed to CS
  from other fields late in their programs.

  I am not sure we can address this point directly -- except advise
  students that they need to allow plenty of time to work on their
  project when they sign up for the course.

  Also see next item.
\item
  Curriculum: More frequent offering of core and popular elective
  courses

  A number of students commented that they did not get the opportunity
  to take courses they would have liked to take because of infrequent
  offerings and full classes.
\end{enumerate}

\end{document}
