Report.tex

\documentclass[12pt]{article}
\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage[latin1]{inputenc}

\title{Final Report}
\author{Smart CCTV}
\date{Spring 2020}

\begin{document}
\maketitle
\pagebreak

\section*{Software Architecture}
\pagebreak

\section*{Component/Class Design}

\pagebreak

\section*{Function Design}
\pagebreak

\section*{Design Practices}
\subsection*{Review Process}
For our review process, we decided it'd be best to rely on our SCRUM meetings, and heavily emphasize talking about blockers to enable peers to help each other find solutions.
\\
\\Through this method, we've been able to benefit from an enviroment where everyone shares a singular vision of the end product, which allowed for a high level cohesion in the team.
\subsection*{Anti-patterns}
\\The most common offense is \textbf{"Lava-flow"}, where we end up planning past a feature or change our strategy and end up leaving 'dead code' in the project that was no longer serving any purpose.
\\
\\A good example of this is the folder we left in the repository specifically for the purpose of debugging, but never took out because nobody remembered why it was in there.
\\\begin{figure}[h]
    \centering
    \includegraphics[scale=0.3]{https://i.imgur.com/58RieQw.png}
    \caption{Random folder in repository}
\end{figure}
\\
\\Another issue we encountered \textbf{"Continuous Obsolescence"}, where more than a few times Qt, OpenCV, or even both updated and left our project to pick up the pieces of whatever broke during that update.
\\\begin{figure}[width=0.25\textwidth]
    \centering
    \includegraphics[scale=0.25]{https://i.imgur.com/cXNE76q.png}
    \caption{Update on April 6th breaking OpenCV code}
\end{figure}
\pagebreak

\section*{Automated Testing}
\\\includegraphics[scale=0.3]{https://docs.travis-ci.com/images/TravisCI-Full-Color.png}
\\
While not perfect, our TravisCI and testing serve as an important reminder to us as to what issues the end-user could face as they install the product. 
\\
\\It's an especially important part of our program that we've considered along the way, but haven't been able to make much headway with because of a 30-40 minute build time. The biggest issue is that the two core components, QT and OpenCV, are relatively large and take an excessively long time to get onto a fresh OS, which makes testing essentially infeasible within the time alotted to us.
\\
\\
\\\includegraphics[scale=0.5]{https://prdeving.files.wordpress.com/2017/03/google-c-testing-framework-gtesk-300x200.jpg?w=300}
\\Although we haven't had the chance to implement this feature yet, we've discussed plans on how we'd roll out the testing framework for our project as we have done in class assignments. 
\\
\\We'd initially start with making sure that the 'daemon' (which runs the OpenCV code in the background) is functional, and move onto other parts such as the UI that runs that deamon.
\pagebreak

\section*{Coverage}
Unfortunately, due the extreme nature of our program's dependencies on both \textbf{Qt and OpenCV leading to an average of 30 minutes of build time}, we could not feasibly instantiate any form of code coverage/testing within reasonable limits.\\
\\\begin{figure}[width=0.25\textwidth]
    \centering
    \includegraphics[scale=0.25]{https://i.imgur.com/UJPKVSY.png}
    \caption{Real build-time exceedes 30 minutes}
\end{figure}
\\
That's to say nothing of the fact that a large portion of our code is run as background processes or as UI, meaning that \textbf{we're unable to be actually test much of anything} bar killing the processes or manually calling the API from the deamon.
\\
\\Not only that, but to fully test our program would \textbf{require a matrix for TravisCI across the two different languages (R/CPP)}, one of which is entirely community driven and prone to bugs.
\begin{figure}[width=0.25\textwidth]
    \centering
    \includegraphics[scale=0.20]{https://i.imgur.com/CIbfjMc.png}
    \caption{Limited success with R based CI in another repository}
\end{figure}
\pagebreak
\\\subsection*{Planned Coverage}
\\Apart from compiling, our coverage was \textbf{planned} to consist of basic tests such as,
\\\begin{itemize}
  \\\item Did the R, OpenCv, and Qt install \textbf{correctly} from a clean OS?
  \\\item Did the UI's api calls for the daemon correctly kill/start the processes it interacts with?
  \\\item Was the program able to access the camera, even if it was a psuedo-camera displayed only for the test?
  \\\item Was the program able to access to generate an example output from a example logfile?
  \\\item Was there any permission errors with accessing any system logging features or misc. issues?
  \\\item If there was an error generated from any particular part of the program, did it kill the process correctly?
  \\\item Was there any issue with generating downloading dependencies? 
\end{itemize}
\pagebreak


\end{document}