fixing dev plan for rev1

Doc/DevelopmentPlan/DevelopmentPlan.tex

@@ -20,68 +20,67 @@ Added project schedule section\\ Sept. 26 & Riley McGee & Added Proof of Concept
 Demonstration Plan,Technology, \& Git Workflow sections \\ Sept. 29 & Pavle
 Arezina & Updated Introduction and Formatting\\ Sept. 29 & Nicolai Kozel & Final
 Proofreading\\ Sept. 30 & Riley McGee & Final aditions to Rev 0, formatting
-corrected throughout \\\bottomrule \end{tabularx} \end{table}
+corrected throughout \\Nov. 30 & Nicolai Kozel & Edited for revision 1\\\bottomrule \end{tabularx} \end{table}
 
 \newpage
 
 \maketitle
 
-The Development Plan for Gifitti is to clearly state how the project will be
-created. The team meeting and communication plan will allow us to work
-cohesively as a group with clearly defined team member roles. To ensure that the
-team can work on the project without conflicts, the git workflow plan is defined
-and the risks pertaining to Gifitti are stated to develop plans to avoid them.
-The presentation of the code and documentation has been constrained to
+The Development Plan for Gifitti clearly states how the project will be
+created. The team meeting and communication sections demonstrate how we will work
+cohesively as a group within our clearly defined team member roles. To ensure that the
+project can be worked on without conflicts, the GIT workflow plan is defined
+and the risks pertaining to Gifitti are stated in order to develop plans to avoid them.
+The code and documentation has been constrained to
 guidelines to ensure a uniform project is produced on the schedule defined by
 the group members.
 
 \section{Team Meeting Plan} Team meetings will occur on Mondays and Tuesdays.
 The meetings on Monday will happen twice a day when possible during the lab
-periods. Tuesday meetings will happen once a day on the first floor of Thode
-Library. While all three of the group members will contribute during the team
-meetings, Nick will act as the Team Leader and Riley will scribe the meetings.
+periods. Tuesday meetings will occur once a day on the first floor of Thode
+Library. All three of the group members will contribute during the team
+meetings; however, Nick will act as the Team Leader and Riley will scribe the meetings.
 The agenda will follow the Harvard guidelines. (See
 Gifitti/ReferenceMaterial/HarvardGuidlines.pdf)
 
 \section{Team Communication Plan} Facebook messaging will be utilized to ask
 simple questions about the project to other group members. To track errors in
 the documentation or code, GitLab issue tracking will be used to help
-communicate these errors. A Combination of texting and calling will be used to
+communicate these errors. A combination of texting and calling will be used to
 contact a group member when they cannot be reached through Facebook messaging.
-Skype is the primary method to conduct calls for team meetings when physically
+Skype will be the primary method to conduct calls for team meetings when physically
 meeting is infeasible. To contact a T.A. or Professor due to questions or issues
-with the project, mcmaster e-mail will be used.
+with the project, McMaster e-mail will be used.
 
-\section{Team Member Roles} Nick will be in charge and will be the Team Leader.
+\section{Team Member Roles} Nick will be in charge of the proejct and is designated as the Team Leader.
 His job is to assign tasks and provide a clear goal on what needs to be
-completed. He is knowledgeable on Gantt charts, git, image manipulation and C\#.
+completed. He is knowledgeable on Gantt charts, GIT, image manipulation and C\#.
 Riley will be responsible for scribing the team meetings and is experienced with
-git and C\#. Pavle's responsibility will involve the documentation because he is
-an expert in git and LaTex.
+GIT and C\#. Pavle's responsibility will involve formatting and creating the documentation because he is
+an expert in GIT and LaTex.
 
-\section{Git Workflow Plan} The development of Gifitti is to follow the Feature
-Branch git workflow.
+\section{Git Workflow Plan} The development of Gifitti will follow the Feature
+Branch GIT workflow.
 
 \subsection{When and how to Create a Feature Branch} \begin{itemize} \item The
 repository will have no direct code changes made on a local version of master.
-However all documentation changes and additions may directly be added to master.
-All development of code is to occur on a feature branch from master, each branch
+However, all documentation changes and additions may directly be added to master.
+All development of code is to occur on a feature branch from master where each branch
 is unique to the feature it addresses. Once a feature is completed and has been
-reviewed and tested it is to be merged into master. This merge should link the
+reviewed and tested, it is then to be merged into master. This merge should link the
 resolution of the issue on GitLab that it solves. \item Feature branch names
 should follow the following naming practices:
 	
-\begin{itemize} \item Be brief in name of the branch, descriptive in the merge
-into master after complete \item Keywords such as fix (for fixing bugs), ui (for
+\begin{itemize} \item Brief yet descriptive \item Keywords such as fix (for fixing bugs), ui (for
 view additions), feature (for general additions) followed by a brief of what the
 branch addresses. i.e. ui/file-menu, fix/console-fault, feature/save-as-sprite
 etc. \item As seen in the examples above follow a $<$Category$>$/$<$Brief$>$
 with words separated with “’-” \end{itemize}
 
-\item Commit and push local feature branches as a backup \item Pull requests are
+\item Local feature branches must be committed and pushed often enough to act as a backup \item Pull requests are
 not needed for this project. We will all act as admins to the repository and
-will review feature branches up to date with master as a team before the
-featurebranch creator merges it into master. This step is only needed for major
+will review feature branches and ensure they are up to date with master as a team before the
+feature branch creator merges it into master. This step is only needed for major
 changes. \end{itemize}
 
 \subsection{Brief List of Commands for the Workflow} \subsubsection*{Make a new
@@ -90,43 +89,33 @@ feature} git checkout “’-”b $<$Category$>$/$<$Brief$>$ master
 $<$Category$>$/$<$Brief$>$ \subsubsection*{Publish Feature into Master} git
 checkout master \\ git pull \\ git pull $<$Category$>$/$<$Brief$>$ \\ git push
 
-\subsubsection*{Committing} All commits are done to the feature branch for code,
-and master for documentation
+\subsubsection*{Committing} All commits must be done to the feature branch for code,
+and master for documentation.
 
 \subsection{Tags} \begin{itemize} \item All deliverables should be tagged
 appropriately to mark that it is complete. \item All code releases should be
 tagged with a version, x.y.z where x is a major update, y is a minor update,
-andz is a bug fix. \end{itemize}
+and z is a bug fix. \end{itemize}
 
-\subsection {Milestones} \begin{itemize} \item Mark deliverables and their due
-dates. \item All milestones are found in the project schedule \item
-Deliverablesare considered major updates to the project. \end{itemize}
+\subsection {Milestones} \begin{itemize} \item The milestones will include all deliverables and their due
+dates. \item All milestones will be listed in the project schedule (Gantt chart).\item
+Deliverables will be considered major updates to the project. \end{itemize}
 
 \section{Proof of Concept Demonstration Plan}
 
-\subsubsection*{Risk 1} Reading in GIFs. GIF files must be read into Gifitti and
+\subsubsection*{Risk 1} The first risk will be reading in GIFs. GIF files must be read into Gifitti and
 parsed.
 
-\subsubsection*{Plan for demonstrate risk 1's feasibility} By the project demo
-an open source library that provides this functionality will be chosen and
-implemented into a base design.
+\subsubsection*{Plan to demonstrate risk 1's feasibility} An open source lirary that provides this functionality must be chosen
+and implemented into a base design by the project demo's deadline. This will be reflected on the Gantt chart. 
 
-\subsubsection*{Risk 2} Sprite Spreadsheet outputs for the currently used gif.
-This issue is a risk due to it being image manipulation. *A sprite spreadsheet
-is an image file where animation is broken into frames while stored in one
-location.
+\subsubsection*{Risk 2} The project will only be usable on a Windows platform, until
+.NET is able to be run on Linux and OSX platforms.
 
-\subsubsection*{Plan for demonstrate risk 2's feasibility} Image manipulation
-will be done with an external api. By the project demo this will be chosen. It
-can be proven that it will be achievable via functionality of the selected api.
+\subsubsection*{Plan for demonstrate risk 3's feasibility} All demonstrations 
+and development must be done on a Windows platform.
 
-\subsubsection*{Risk 3} The project is only usable on Windows platform, until
-.NET is made executable on Linux and OSX platforms.
-
-\subsubsection*{Plan for demonstrate risk 3's feasibility} All demonstrations,
-and development must be done on a windows platform.
-
-\subsubsection*{Risk 4} Testing is time consuming for all major components as
+\subsubsection*{Risk 3} Testing will be time consuming for all major components as
 the application is based on user input and experience.
 
 \subsubsection*{Plan for demonstrate risk 4's feasibility} Some test cases that
@@ -135,23 +124,24 @@ show that we can automate most of the testing that does not rely on user
 interaction. This saves time for the user tests.
 
 \section{Technology} Note: Currently, a Windows platform must be used to run and
-develop this project. In the near future .Net will be ported to OSX and Linux.
-\subsection{Programming Language$($s$)$} The majority of all development is in
-C\# however WPF will also be used for UI. \subsection{IDE} Visual Studio 2015
-Community \subsection{Testing Framework} Visual C\# Test Suite, specifically
-unit test. This platform comes integrated with Visual Studio 2015 Community.
-\subsection{Document Generation} \begin{itemize} \item Doxygen for code
-documentation. \item Visual Studio for any post code software model generation
-\item Gantt Project for the project schedule \end{itemize}
-
-\section{Coding Style} Coding standard utilized for the project is the
+develop this project. In the near future .NET will be ported to OSX and Linux.
+\subsection{Programming Language$($s$)$} The majority of all development will be done in
+C\#; however, WPF will also be used for the UI. \subsection{IDE} The IDE that will be used to develop this project will be Visual Studio 2015
+Community Edition. \subsection{Testing Framework} The testing framework that will be used will be the native Visual C\# Test Suite, specifically
+unit testing. This platform comes integrated with Visual Studio 2015 Community.
+\subsection{Document Generation} \begin{itemize} \item Doxygen will be used for code
+documentation. \item Visual Studio will be used for any post code software model generation
+\item Gantt Project will be used to document the project schedule \end{itemize}
+
+\section{Coding Style} The coding standard tha will be utilized for this project is the
 \href{https://msdn.microsoft.com/en-us/library/hh156542(v=vs.110).aspx}{.NET
 Framework Development Guide}.
 
 \section{Project Schedule} The Gantt Chart outlining the project schedule can
-befound
+be found
 \href{https://gitlab.cas.mcmaster.ca/kozeln/Gifitti/tree/master/ProjectSchedule}{here.}
 
 \section{Project Review}
+After completing Gifitti, we feel that our development plan worked well and aided in the successful completion of this project. Our GIT workflow plan was very helpful and reduced the amount of troubleshooting needed to fix merges or repository errors. Our master branch was clean throughout the entire development phase and as features were added and merged into master, it remained stable. We felt very comfortable within our team member roles and all performed within those roles to the best of our abilities. Our roles matched our personalities and we feel this made a big impact on everyone's motivation and attitude towards the project. The things that we felt did not work for us were the team meeting schedule and the coding style guidelines. We learned that because of time constraints or laziness, we did not adher to the coding guidelines all the time and we each had our own styles of coding regardless of the guidelines. The team meetings were effective but we did not have them as often as we said we would. This was due to the nature of everyones schedules and the fact that we did not want to meet on the weekends. Therefore, on a future project the only things that we would change would be to meet on dedicated days where we know everyone is available and choose less strict coding guidelines or have repercussions for not following them. 
 
 \end{document}
\ No newline at end of file