Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • namy2/se3xa3
  • bokhari/se3xa3
  • kanwalg/se3xa3
  • sunx20/se3xa3
  • hameea1/se3xa3
  • aij/se3xa3
  • hanzy3/se3xa3
  • linl20/se3xa3
  • zhous20/se3xa3
9 results
Show changes
Commits on Source (83)
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 1190 additions and 263 deletions
BlankProjectTemplate/Doc/Design/MG/MG.bib
View file @ 0671a4ab
......@@ -8,33 +8,6 @@
%% Saved with string encoding Unicode (UTF-8)
@inproceedings{Parnas1978,
Address = {Piscataway, NJ, USA},
Author = {David L. Parnas},
Booktitle = {ICSE '78: Proceedings of the 3rd international conference on Software engineering},
Date-Added = {2016-10-28 03:56:16 +0000},
Date-Modified = {2016-10-28 03:56:16 +0000},
Isbn = {none},
Location = {Atlanta, Georgia, United States},
Pages = {264--277},
Publisher = {IEEE Press},
Title = {Designing Software for Ease of Extension and Contraction},
Year = {1978}}
@article{Parnas1972a,
Author = {David L. Parnas},
Date-Added = {2016-10-28 03:55:43 +0000},
Date-Modified = {2016-10-28 03:55:43 +0000},
Journal = {Comm. ACM},
Month = {December},
Number = {2},
Pages = {1053--1058},
Title = {On the Criteria To Be Used in Decomposing Systems into Modules},
Volume = {15},
Year = {1972},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QOS4uLy4uLy4uLy4uLy4uLy4uL1dvcmsvUmVzZWFyY2gvUmVmZXJlbmNlcy9QYXJuYXMxOTcyLnBkZtIXCxgZV05TLmRhdGFPEQGmAAAAAAGmAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAAXAgwOUGFybmFzMTk3Mi5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3+xs9CaVP4AAAAAAAAAAAAGAAQAAAkgAAAAAAAAAAAAAAAAAAAAClJlZmVyZW5jZXMAEAAIAADOl6vDAAAAEQAIAADQmptOAAAAAQAUABcCDAAXAE0AFv3tAAj3ZgACZI4AAgBGTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFdvcms6AFJlc2VhcmNoOgBSZWZlcmVuY2VzOgBQYXJuYXMxOTcyLnBkZgAOAB4ADgBQAGEAcgBuAGEAcwAxADkANwAyAC4AcABkAGYADwAaAAwATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAEgA0VXNlcnMvc21pdGhzL1dvcmsvUmVzZWFyY2gvUmVmZXJlbmNlcy9QYXJuYXMxOTcyLnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOAMoAzwDXAoECgwKIApMCnAKqAq4CtQK+AsMC0ALTAuUC6ALtAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAu8=}}
@inproceedings{ParnasEtAl1984,
Author = {D.L. Parnas and P.C. Clement and D. M. Weiss},
Booktitle = {International Conference on Software Engineering},
......@@ -45,23 +18,3 @@
Year = {1984},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QPy4uLy4uLy4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0V0QWwxOTg0LnBkZtIXCxgZV05TLmRhdGFPEQHcAAAAAAHcAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAkx/Q0SUGFybmFzRXRBbDE5ODQucGRmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACTH9RNNvBNMAAAAAAAAAAAAFAAMAAAkgAAAAAAAAAAAAAAAAAAAAF1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzAAAQAAgAAM6Xq8MAAAARAAgAANNvPRMAAAABABQJMf0NCTHuxwASFacACPdmAAJkjgACAFVNYWNpbnRvc2ggSEQ6VXNlcnM6AHNtaXRoczoAUmVwb3M6AHNlNHNjOgBTY2lDb21wQW5kU29mdEVuZ1BhcGVyczoAUGFybmFzRXRBbDE5ODQucGRmAAAOACYAEgBQAGEAcgBuAGEAcwBFAHQAQQBsADEAOQA4ADQALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAENVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzRXRBbDE5ODQucGRmAAATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANAA1QDdAr0CvwLEAs8C2ALmAuoC8QL6Av8DDAMPAyEDJAMpAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAys=}}
@book{RobertsonAndRobertson2012,
Author = {James Robertson and Suzanne Robertson},
Date-Added = {2016-09-22 13:54:40 +0000},
Date-Modified = {2016-09-22 14:01:42 +0000},
Edition = {16},
Publisher = {Atlantic Systems Guild Limited},
Title = {Volere Requirements Specification Template},
Year = {2012}}
@article{ParnasAndClements1986,
Author = {David L. Parnas and P.C. Clements},
Date-Added = {2016-09-10 13:11:57 +0000},
Date-Modified = {2016-09-10 13:11:57 +0000},
Journal = {IEEE Transactions on Software Engineering},
Number = {2},
Pages = {251--257},
Title = {A Rational Design Process: How and Why to Fake it},
Volume = {12},
Year = {February 1986},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QRi4uLy4uLy4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGbSFwsYGVdOUy5kYXRhTxEB9gAAAAAB9gACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAAzpdzg0grAAAJMf0NGVBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkx/UPTbwTTAAAAAAAAAAAABQADAAAJIAAAAAAAAAAAAAAAAAAAABdTY2lDb21wQW5kU29mdEVuZ1BhcGVycwAAEAAIAADOl6vDAAAAEQAIAADTbz0TAAAAAQAUCTH9DQkx7scAEhWnAAj3ZgACZI4AAgBcTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFJlcG9zOgBzZTRzYzoAU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnM6AFBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYADgA0ABkAUABhAHIAbgBhAHMAQQBuAGQAQwBsAGUAbQBlAG4AdABzADEAOQA4ADYALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAEpVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzQW5kQ2xlbWVudHMxOTg2LnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANcA3ADkAt4C4ALlAvAC+QMHAwsDEgMbAyADLQMwA0IDRQNKAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA0w=}}
BlankProjectTemplate/Doc/Design/MG/MG.pdf
View file @ 0671a4ab
No preview for this file type
BlankProjectTemplate/Doc/Design/MG/MG.tex
View file @ 0671a4ab
......@@ -12,10 +12,11 @@
colorlinks,
citecolor=black,
filecolor=black,
linkcolor=red,
linkcolor=black,
urlcolor=blue
}
\usepackage[round]{natbib}
\usepackage{verbatim}
\newcounter{acnum}
\newcommand{\actheacnum}{AC\theacnum}
......@@ -29,18 +30,16 @@
\newcommand{\mthemnum}{M\themnum}
\newcommand{\mref}[1]{M\ref{#1}}
\title{SE 3XA3: Software Requirements Specification\\Title of Project}
\title{SE 3XA3: Software Requirements Specification\\Snake 2.o}
\author{Team \#, Team Name
\\ Student 1 name and macid
\\ Student 2 name and macid
\\ Student 3 name and macid
\author{Team 30, VUA30
\\ Andy Hameed | Hameea1
\\ Usman Irfan | Irfanm7
\\ Vaibhav Chadha | Chadhav
}
\date{\today}
\input{../../Comments}
\begin{document}
\maketitle
......@@ -55,7 +54,7 @@
\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
\midrule
Date 1 & 1.0 & Notes\\
2018 -11-09 & 1.0 & Andy added section 1, 7 and 5.3\\
Date 2 & 1.1 & Notes\\
\bottomrule
\end{tabularx}
......@@ -67,6 +66,31 @@ Date 2 & 1.1 & Notes\\
\section{Introduction}
\subsection{Overview}
Almost everyone nowadays relies on a computer as a multipurpose tool for research, video streaming, gaming and many other tasks. With the emergence of fast computing, gaming has become a popular pastime activity and a source of entertainment for many. However, not everyone has a device powerful enough to support extensive game applications. A simple, memory-effecient application of the Snake game allows it to be accessible for gamers without the need for extensive hardware or a high-performance computer. Our team, VUA30, will be creating a desktop application for the well-known “Snake” game with new enhancements and features. This competitive and addictive game can allow the user to play at their own pace and challenge their own high score.
\subsection{Scope}
The scope of the project will cover the reimplementation of the game as well as enhancements to the game, in particular, changes that pertain to gameplay themes, different modes/ difficulties and so on. Due to the time constraints of the project, not all enhancements will be implemented but at least one enhancement will be implemented to differentiate Snake 2.o from previous remakes of the game.
\subsection{Relevance of Module Guide}
The Module Guide (MG) document will outline the structure of the reimplementation through modular programming. It highlights the components of the system such that each component can easily be identified by project members, whether they are maintaining or designing the software. Among the list of internal stakeholders that may make use of this document, any new members that are added to the team will also be able to use the MG as a convenient reference to specific modules that they are concerned with or working on~\citep{ParnasEtAl1984}.
\subsection{SRS,MIS and MG}
In the SRS, functional and non-functional requirements were specified along with testing methods. In this document, we will be covering the modules that will implement the functional requirements specified in the SRS. The MIS will outline the module attributes and methods that are needed to meet the functional requirements as well as descriptions of these attributes and methods and their purpose.
The document will have the following structure:
\begin{enumerate}
\item Introduction: Connecting the relevance of the MIS, SRS and the MG along with the scope and a reiteration of the project overview
\item Anticipated changes: This includes changes that will be made to this document including the addition and removal of modules and othe module-related
changes that can come about in the future.
\item Module Heirarchy: Will list the modules that will be implemented, giving an overview of the module structure.
\item Traceability Matrix: Shows the connection between modules and how errors could be traced back to each module
\item Use Heirarchy: a visual of the modules and their working relationship between each other. an arrow from A to B explains that
module A uses module B
\end{enumerate}
\begin{comment}
Decomposing a system into modules is a commonly accepted approach to developing
software. A module is a work assignment for a programmer or programming
team~\citep{ParnasEtAl1984}. We advocate a decomposition
......@@ -115,6 +139,7 @@ modules. Section \ref{SecTM} includes two traceability matrices. One checks
the completeness of the design against the requirements provided in the SRS. The
other shows the relation between anticipated changes and the modules. Section
\ref{SecUse} describes the use relation between modules.
\end{comment}
\section{Anticipated and Unlikely Changes} \label{SecChange}
......@@ -134,26 +159,24 @@ change.
\begin{description}
\item[\refstepcounter{acnum} \actheacnum \label{acHardware}:] The specific
hardware on which the software is running.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The format of the
initial input data.
\item ...
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The Operating System of which the software interfaces with.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The new High Score after any previous record is broken.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The speed of the snake when the user changes the difficulty level.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] Storing the score to the text file after each game is played.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The theme of the playground is changed whenever the user decides changes the theme mode.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:]Default settings for inputs.
\end{description}
\subsection{Unlikely Changes} \label{SecUchange}
The module design should be as general as possible. However, a general system is
more complex. Sometimes this complexity is not necessary. Fixing some design
decisions at the system architecture stage can simplify the software design. If
these decision should later need to be changed, then many parts of the design
will potentially need to be modified. Hence, it is not intended that these
decisions will be changed.
\begin{description}
\item[\refstepcounter{ucnum} \uctheucnum \label{ucIO}:] Input/Output devices
(Input: File and/or Keyboard, Output: File, Memory, and/or Screen).
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] There will always be
a source of input data external to the software.
\item ...
(The system assumes mouse, keyboard and screen are available).
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] The snake is responsive to the directions button under any circumstances.
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] The goal of the system: To provide user with entertainment and a fun game to play.
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] There will always be a source of input data external to the software.
\end{description}
\section{Module Hierarchy} \label{SecMH}
......@@ -165,7 +188,14 @@ actually be implemented.
\begin{description}
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Hardware-Hiding Module
\item ...
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Interface Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Snake Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Food Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Themes Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Software Design Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] init Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] highscore Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Gameplay Module
\end{description}
......@@ -179,19 +209,13 @@ actually be implemented.
{Hardware-Hiding Module} & ~ \\
\midrule
\multirow{7}{0.3\textwidth}{Behaviour-Hiding Module} & ?\\
& ?\\
& ?\\
& ?\\
& ?\\
& ?\\
& ?\\
& ?\\
\multirow{4}{0.3\textwidth}{Behaviour-Hiding Module} & Input Format Module\\
& Snake Module\\
& Food Module\\
& Themes Module\\
\midrule
\multirow{3}{0.3\textwidth}{Software Decision Module} & {?}\\
& ?\\
& ?\\
\multirow{1}{0.3\textwidth}{Software Decision Module} & HighScore Module\\
\bottomrule
\end{tabular}
......@@ -200,10 +224,26 @@ actually be implemented.
\end{table}
\section{Connection Between Requirements and Design} \label{SecConnection}
The design of the system is intended to satisfy the requirements developed in
the SRS. In this stage, the system is decomposed into modules. The connection
between requirements and modules is listed in Table \ref{TblRT}.
The Design of the software product was designed to meet the functional and non-functional
requirements. The user-interference file displays the game interface that allows the user to either start
the game or to select different modes, themes or even check the high score. The design was kept to
keep the interface simple and easy to use. When the user runs the main file, it opens a title page
which has multiple options from which a user can select options. To meet the functional requirement
of outputting high score, the main interface file has a button which when pressed open a new window
displaying the highest score of the game so far. A quit button and a Main Menu button has been
added in the high score window so the user can either go back or end the game. In the Main Menu,
there are different themes combined that the user can select letting us meet another requirement.
The principal part of the design was to open a new window which begins the snake game. It was
created by adding a new button ``Game Time" in the Main Menu window. The design of the snake
game is kept simple where a snake and food appears randomly on the window, upon pressing the
Arrow direction keys the snake moves to the respective location proceeding the game smoothly and
connecting our requirement to its design. The current score of the game displays on the top which
keeps updating as the snake eats the food, and a quit button will be added on the bottom of the
screen so the user can quit the game whenever they feel like.\\
To enhance our design, in the future the group has planned to add radio buttons, drop-down menus or
use a slider to make the game interactive. The radio buttons would be installed where the user can
select the difficulty modes of the game, the drop-down menus would be helpful in selecting the theme
and the slider would work to alter the speed of the snake.
\section{Module Decomposition} \label{SecMD}
......@@ -223,55 +263,94 @@ that the module is not a leaf and will not have to be implemented. Whether or
not this module is implemented depends on the programming language
selected.
\subsection{Hardware Hiding Modules (\mref{mHH})}
\subsection{Hardware Hiding Modules }
\begin{description}
\item[Secrets:]The data structure and algorithm used to implement the virtual
hardware.
\item[Services:]Serves as a virtual hardware used by the rest of the
\item[Secrets:] user controls
\item[Services:] Serves as a virtual hardware used by the rest of the
system. This module provides the interface between the hardware and the
software. So, the system can use it to display outputs or to accept inputs.
\item[Implemented By:] OS
software. So, the system can take inputs from the keyboard and mouse, and then further output it on the screen.
\item[Implemented By:] Pygame library and OS
\end{description}
\subsection{Behaviour-Hiding Module}
\begin{description}
\item[Secrets:]The contents of the required behaviours.
\item[Services:]Includes programs that provide externally visible behaviour of
\item[Services:] Includes programs that provide externally visible behaviour of
the system as specified in the software requirements specification (SRS)
documents. This module serves as a communication layer between the
hardware-hiding module and the software decision module. The programs in this
module will need to change if there are changes in the SRS.
\item[Implemented By:] --
\end{description}
\subsubsection{Interface Module}
\begin{description}
\item[Secrets:] Input Data
\item[Services:] Collects data on customized fields in the game
such as speed, theme, difficulty and other important variables.
\item[Implemented By:] Pygame library
\end{description}
\subsubsection{Input Format Module (\mref{mInput})}
\subsubsection{Snake Module}
\begin{description}
\item[Secrets:]The format and structure of the input data.
\item[Services:]Converts the input data into the data structure used by the
input parameters module.
\item[Implemented By:] [Your Program Name Here]
\item[Secrets:] Snake
\item[Services:] Defines the snake class and its attributes and behaviours. This
includes the movement of the snake depending on its attributes and its interaction with
user events.
\item[Implemented By:] Pygame library
\end{description}
\subsubsection{Etc.}
\subsubsection{Food Module}
\begin{description}
\item[Secrets:] Food
\item[Services:] Defines the food item class for spawning the food item during gameplay.
\item[Implemented By:] Pygame library
\end{description}
\subsubsection{Themes Module}
\begin{description}
\item[Secrets:] Themes
\item[Services:] Allows the user to choose different themes of the snake game.
\item[Implemented By:] Pygame library
\end{description}
\subsubsection{Gameplay Module}
\begin{description}
\item[Secrets:] gameplay
\item[Services:] connects different modules to the Pygame event functionality and
creates movement of snake around window.
\item[Implemented By:] Pygame library
\end{description}
\subsubsection{highscore Module}
\begin{description}
\item[Secrets:] highscore
\item[Services:] provides highscore of player on a separate menu
after initial start menu.
\item[Implemented By:] Pygame library
\end{description}
\subsection{Software Decision Module}
\begin{description}
\item[Secrets:] The design decision based on mathematical theorems, physical
facts, or programming considerations. The secrets of this module are
\emph{not} described in the SRS.
\item[Services:] Includes data structure and algorithms used in the system that
do not provide direct interaction with the user.
\item[Secrets:] Text files
\item[Services:] Creates a text file which stores the game score
% Changes in these modules are more likely to be motivated by a desire to
% improve performance than by externally imposed changes.
\item[Implemented By:] --
\item[Implemented By:] N/A
\end{description}
\subsubsection{Etc.}
%\subsubsection{Etc.}
\section{Traceability Matrix} \label{SecTM}
......@@ -286,17 +365,26 @@ requirements and between the modules and the anticipated changes.
\toprule
\textbf{Req.} & \textbf{Modules}\\
\midrule
R1 & \mref{mHH}, \mref{mInput}, \mref{mParams}, \mref{mControl}\\
R2 & \mref{mInput}, \mref{mParams}\\
R3 & \mref{mVerify}\\
R4 & \mref{mOutput}, \mref{mControl}\\
R5 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}, \mref{mSeqDS}, \mref{mSolver}, \mref{mPlot}\\
R6 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}, \mref{mSeqDS}, \mref{mSolver}, \mref{mPlot}\\
R7 & \mref{mOutput}, \mref{mEnergy}, \mref{mControl}, \mref{mSeqDS}, \mref{mPlot}\\
R8 & \mref{mOutput}, \mref{mEnergy}, \mref{mControl}, \mref{mSeqDS}, \mref{mPlot}\\
R9 & \mref{mVerifyOut}\\
R10 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}\\
R11 & \mref{mOutput}, \mref{mODEs}, \mref{mEnergy}, \mref{mControl}\\
FR1 & M2, M3\\
FR2 & M2, M3\\
FR3 & M2, M3\\
FR4 & M2, M3\\
FR5 & M2, M3\\
FR6 & M2, M3\\
FR7 & M6\\
FR8 & M3\\
FR9 & M2, M5\\
FR10 & M6\\
FR11 & M5\\
FR12 & M3\\
FR13 & M3\\
FR14 & M3\\
FR15 & M4\\
FR16 & M3\\
FR17 & M3\\
FR18 & M4\\
FR19 & M6\\
\bottomrule
\end{tabular}
\caption{Trace Between Requirements and Modules}
......@@ -309,18 +397,13 @@ R11 & \mref{mOutput}, \mref{mODEs}, \mref{mEnergy}, \mref{mControl}\\
\toprule
\textbf{AC} & \textbf{Modules}\\
\midrule
\acref{acHardware} & \mref{mHH}\\
\acref{acInput} & \mref{mInput}\\
\acref{acParams} & \mref{mParams}\\
\acref{acVerify} & \mref{mVerify}\\
\acref{acOutput} & \mref{mOutput}\\
\acref{acVerifyOut} & \mref{mVerifyOut}\\
\acref{acODEs} & \mref{mODEs}\\
\acref{acEnergy} & \mref{mEnergy}\\
\acref{acControl} & \mref{mControl}\\
\acref{acSeqDS} & \mref{mSeqDS}\\
\acref{acSolver} & \mref{mSolver}\\
\acref{acPlot} & \mref{mPlot}\\
AC1 & M1\\
AC2 & M2, M6\\
AC3 & M6\\
AC4 & M5,M6\\
AC5 & M6\\
AC6 & M5\\
AC7 & M2\\
\bottomrule
\end{tabular}
\caption{Trace Between Anticipated Changes and Modules}
......@@ -329,21 +412,12 @@ R11 & \mref{mOutput}, \mref{mODEs}, \mref{mEnergy}, \mref{mControl}\\
\section{Use Hierarchy Between Modules} \label{SecUse}
In this section, the uses hierarchy between modules is
provided. \citet{Parnas1978} said of two programs A and B that A {\em uses} B if
correct execution of B may be necessary for A to complete the task described in
its specification. That is, A {\em uses} B if there exist situations in which
the correct functioning of A depends upon the availability of a correct
implementation of B. Figure \ref{FigUH} illustrates the use relation between
the modules. It can be seen that the graph is a directed acyclic graph
(DAG). Each level of the hierarchy offers a testable and usable subset of the
system, and modules in the higher level of the hierarchy are essentially simpler
because they use modules from the lower levels.
\begin{figure}[H]
\centering
%\includegraphics[width=0.7\textwidth]{UsesHierarchy.png}
%\includegraphics[width=0.7\textwidth]{Use_Hierarchy.png}
\caption{Use hierarchy among modules}
\includegraphics{Use_Heirarchy}
\label{FigUH}
\end{figure}
......
BlankProjectTemplate/Doc/Design/MG/Use_Heirarchy.jpg 0 → 100644
View file @ 0671a4ab
BlankProjectTemplate/Doc/Design/MG/Use_Heirarchy.jpg

9.21 KiB

BlankProjectTemplate/Doc/DevelopmentPlan/DevelopmentPlan.pdf
View file @ 0671a4ab
No preview for this file type
BlankProjectTemplate/Doc/DevelopmentPlan/DevelopmentPlan.tex
View file @ 0671a4ab
\documentclass{article}
\usepackage{pdfpages}
\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{hyperref}
\title{SE 3XA3: Development Plan\\Title of Project}
\author{Team \#, Team Name
\\ Student 1 name and macid
\\ Student 2 name and macid
\\ Student 3 name and macid
\title{SE 3XA3: Development Plan\\Snake 2.o}
\author{Team \# 30, VUA30
\\ Vaibhav Chadha , chadhav
\\ Usman Irfan , irfanm7
\\ Andy Hameed , hameea1
}
\date{}
\input{../Comments}
\begin{document}
......@@ -23,9 +26,12 @@
\toprule
\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
\midrule
Date1 & Name(s) & Description of changes\\
Date2 & Name(s) & Description of changes\\
... & ... & ...\\
Sept 25, 2018 & Vaibhav, Usman, Andy & Worked on part 1 to 4\\
Sept 27, 2018 & Vaibhav, Usman, Andy & Worked on part 4 to 8\\
Sept 27, 2018 & Vaibhav & Added the information from the meeting documents to the LaTeX file\\
Sept 28, 2018 & Andy & Proof of concept, Git workflow, Final editing and formatting\\
Sept 28, 2018 & Usman & Updated proof of concept\\
Oct 12, 2018 & Andy & Made changes according to feedback on development plan and added section on POC demo\\
\bottomrule
\end{tabularx}
\end{table}
......@@ -34,25 +40,97 @@ Date2 & Name(s) & Description of changes\\
\maketitle
Put your introductory blurb here.
\section{Team Meeting Plan}
Meetings will be held \textbf{twice a week} at the following times:
\begin{itemize}
\item Mondays 5:30 - 6:30 pm at KTH Computer Labs
\item Wednesdays 12:30 to 2:00pm at Health science library
\end{itemize}
\subsection{Roles and Agenda}
\textbf{Chair}: Andy Hameed
\begin{itemize}
\item Responsible for creating the agenda and selecting topics that pertain to all team members
\item Agenda items will be listed as questions\\
\end{itemize}
\textbf{Notettaker}: Usman Irfan
\begin{itemize}
\item Responsible for taking meeting minutes
\item Meeting decisions will be summarized in a statement at the end of the meeting
\end{itemize}
\textbf{Timekeeper}: Vaibhav Chadha
\begin{itemize}
\item Keeps track of time in case we are spending too much time on one topic
\end{itemize}
\section{Team Communication Plan}
Main source of communication is \textbf{Facebook Messenger}, it will be used for general inquiries, updates, reminders of team meetings, any links to useful resources and so on. Phone and texting will be used as a backup in case of urgent matters, for example not being able to get in contact with a team member through messenger.
Aside from these, the team will be using Workflowy to assign small tasks that are promptly due or ones that may not necessarily fit on the gantt chart because they are minor - this tool will be used to delegate a small to-do list for each team member .
\section{Team Member Roles}
Vaibhav Chadha:
\begin{itemize}
\item Latex Documentation
\item Analyst - makes sure the requirements of the clients are met through the software
\item gantt chart management\\
\end{itemize}
Usman Irfan:
\begin{itemize}
\item Scribe
\item Technology Research
\item operation manager -ensures project development is running smoothly and software is being developed according to milestones \\
\end{itemize}
Andy Hameed:
\begin{itemize}
\item Final editing
\item latex documentation
\item team leader\\
\end{itemize}
All:
\begin{itemize}
\item GIT project management
\end{itemize}
\section{Git Workflow Plan}
We will be using the Git Feature Branch Workflow to manage the software development. Using branches, each team member is capable of
working on different modules or sections of the software at the same time in localized branches, before pushing their changes to the master branch.
The following procedures will be followed:
\begin{itemize}
\item Vaibhav will be tagging any major milestones for final submission. This makes the submission process consistent. Otherwise, Andy or Usman will agree on one person to tag and submit for final submission.
\item Any major changes can be placed in a branch to avoid merging conflicts and overwriting existing work. They can be merged later on upon team agreement.
\end{itemize}
\section{Proof of Concept Demonstration Plan}
The original project is built using Javascript, HTML and CSS in contrast to our development plan using python and the Pygame library. Since we are using an OOP language, we will be able to create classes for different components of the snake game such as the snake unit block, snake body, and snake bate. The hardest part of the implementation will be the movement of the snake according to the user's keyboard inputs, and second to that would be the process of expanding the snake once a food item is captured. Besides that, the interface may be difficult to implement in python but could be simple with the use of a python framework such as PyQT5.\\
Once our game application has been developed the next part would be to test the project and for that we will be using Pytest, since our backend language is python this will help us test all possible functions and aspects. The functions that will be difficult to test would be to see if the snake eats the food, does the food appear at random locations after eaten by the snake and if the snake tries to leave the borders, will the game end. Portability will have to be taken into consideration since the application is being built for windows. However, it can be compiled and run on any system as long as the necessary files and libraries are download.
\subsection{POC Demo}
The team will be demonstrating the movement of a snake around the screen using unit blocks for the body of the snake. Lengthening the snake body, scoring and eating the bate will not be demonstrated in the demo. This POC should demonstrate that with the movement of the snake, which is the main component of the game, the team will be able to develop classes to represent other components of the game such as the score, food bate, and lengthening of the snake body.
\section{Technology}
Coding Language: Python, Kivy for GUI\\
IDE: IDLE scripting\\
Testing: PyUnit testing\\
Documentation: Doxygen\\
\section{Coding Style}
We will be using the \href{https://github.com/google/styleguide/blob/gh-pages/pyguide.md}{Google Python Style Guide}
for our coding style. It encompasses all the necessary naming conventions and standards required for the project development.
\section{Project Schedule}
Please see the following pages for the project schedule in the form of a gantt chart.
Provide a pointer to your Gantt Chart.
\includepdf[page=-]{../../ProjectSchedule/Team_Gantt}
\section{Project Review}
......
BlankProjectTemplate/Doc/ProblemStatement/ProblemStatement.pdf
View file @ 0671a4ab
No preview for this file type
BlankProjectTemplate/Doc/ProblemStatement/ProblemStatement.tex
View file @ 0671a4ab
......@@ -3,17 +3,17 @@
\usepackage{tabularx}
\usepackage{booktabs}
\title{SE 3XA3: Problem Statement\\Title of Project}
\title{SE 3XA3: Problem Statement\\ \textbf{Snake Game}}
\author{Team \#, Team Name
\\ Student 1 name and macid
\\ Student 2 name and macid
\\ Student 3 name and macid
\author{Team \#30, VUA30
\\ Usman Irfan - irfanm7
\\ Andy Hameed - hameea1
\\ Vaibhav Chadha - chadhav
}
\date{}
\date{2018-09-21}
\input{../Comments}
\usepackage[left=2cm, right=5cm, top=2cm]{geometry}
\begin{document}
......@@ -23,9 +23,10 @@
\toprule
\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
\midrule
Date1 & Name(s) & Description of changes\\
Date2 & Name(s) & Description of changes\\
... & ... & ...\\
2018-09-20 & Vaibhav & Made the LaTeX file and wrote the section with what the Problem is\\
2018-09-20 & Usman & Added the Importance of Problem section while formatting the LaTeX\\
2018-09-21 & Andy Hameed & Formatted LaTeX file and added Context section, giving the final editing to the document\\
2018-10-09 & Andy Hameed & Edited doc to reflect web app to desktop app decision change\\
\bottomrule
\end{tabularx}
\end{table}
......@@ -34,16 +35,17 @@ Date2 & Name(s) & Description of changes\\
\maketitle
Put your problem statement here.
\subsection*{The Problem}
\wss{comment}
Almost everyone nowadays relies on a computer as a multipurpose tool for research, video streaming, gaming and many other tasks. With the emergence of fast computing, gaming has become a popular pastime activity and a source of entertainment for many. However, not everyone has a device powerful enough to support extensive game applications. A simple, memory effecient application of the Snake game allows it to be accessible for gamers without the need for extensive hardware or a high-performance computer. Our team, VUA30, will be creating a desktop application for the well-known Snake game with new enhancements and features. This competitive and addictive game can allow the user to play at their own pace and challenge their own high score.
\ds{comment}
\subsection*{Importance of the Problem}
\mj{comment}
Buying a computing device with high storage and faster performance can be out of budget. Complicated software covers up all the storage and the user is bound to use these applications as opposed to downloading other software. The importance of the redevelopment of The Snake is to save computing devices' personal storage and allow the user to play a game 24/7 with strong performance, even offline. Creating a desktop version of the snake game can fit into the category of downloadable calssical games such as the solitaire suite. The recreation of this game will allow the user to enjoy the classical game anytime and anywhere as long as they have installed the application. Improving aspects such as graphics and custom speed will also make the game more interesting. We would like to add more features to the game to make it more customizable and help people enjoy the classical game in an exciting and new way.
\cm{comment}
\mh{comment}
\subsection*{Context}
The stakeholders are mainly the gaming audience, the older generation of game enthusiasts, youth and teens. Some other stakeholders that Although the game can be played by anyone, it is targeted towards the audience mentioned above who are most invested in the game. The environment is native app development using Python. This provides provides less flexibility than web API's but there still exists many useful libraries which can be used such as Pygame for example.
\end{document}
\end{document}
\ No newline at end of file
BlankProjectTemplate/Doc/SRS/SRS.bib
View file @ 0671a4ab
......@@ -7,6 +7,11 @@
%% Saved with string encoding Unicode (UTF-8)
@article{devArticle,
Author = {Sumit Jain},
Title = {Game Development Life Cycle},
Year = {May 2017}
}
@book{RobertsonAndRobertson2012,
Author = {James Robertson and Suzanne Robertson},
......
BlankProjectTemplate/Doc/SRS/SRS.pdf
View file @ 0671a4ab
No preview for this file type
BlankProjectTemplate/Doc/SRS/SRS.tex
View file @ 0671a4ab
This diff is collapsed.
BlankProjectTemplate/Doc/TestPlan/TestPlan.pdf
View file @ 0671a4ab
No preview for this file type
BlankProjectTemplate/Doc_Revision1/.gitkeep 0 → 100644
View file @ 0671a4ab
BlankProjectTemplate/Doc_Revision1/DevelopmentPlan/DevelopmentPlan.pdf 0 → 100644
View file @ 0671a4ab
File added
BlankProjectTemplate/Doc_Revision1/DevelopmentPlan/DevelopmentPlan.tex 0 → 100644
View file @ 0671a4ab
\documentclass{article}
\usepackage{pdfpages}
\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{hyperref}
\title{SE 3XA3: Development Plan\\Snake 2.o}
\author{Team \# 30, VUA30
\\ Vaibhav Chadha , chadhav
\\ Usman Irfan , irfanm7
\\ Andy Hameed , hameea1
}
\date{}
\begin{document}
\begin{table}[hp]
\caption{Revision History} \label{TblRevisionHistory}
\begin{tabularx}{\textwidth}{llX}
\toprule
\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
\midrule
Sept 25, 2018 & Vaibhav, Usman, Andy & Worked on part 1 to 4\\
Sept 27, 2018 & Vaibhav, Usman, Andy & Worked on part 4 to 8\\
Sept 27, 2018 & Vaibhav & Added the information from the meeting documents to the LaTeX file\\
Sept 28, 2018 & Andy & Proof of concept, Git workflow, Final editing and formatting\\
Sept 28, 2018 & Usman & Updated proof of concept\\
Oct 12, 2018 & Andy & Made changes according to feedback on development plan and added section on POC demo\\
\bottomrule
\end{tabularx}
\end{table}
\newpage
\maketitle
\section{Team Meeting Plan}
Meetings will be held \textbf{twice a week} at the following times:
\begin{itemize}
\item Mondays 5:30 - 6:30 pm at KTH Computer Labs
\item Wednesdays 12:30 to 2:00pm at Health science library
\end{itemize}
\subsection{Roles and Agenda}
\textbf{Chair}: Andy Hameed
\begin{itemize}
\item Responsible for creating the agenda and selecting topics that pertain to all team members
\item Agenda items will be listed as questions\\
\end{itemize}
\textbf{Notettaker}: Usman Irfan
\begin{itemize}
\item Responsible for taking meeting minutes
\item Meeting decisions will be summarized in a statement at the end of the meeting
\end{itemize}
\textbf{Timekeeper}: Vaibhav Chadha
\begin{itemize}
\item Keeps track of time in case we are spending too much time on one topic
\end{itemize}
\section{Team Communication Plan}
Main source of communication is \textbf{Facebook Messenger}, it will be used for general inquiries, updates, reminders of team meetings, any links to useful resources and so on. Phone and texting will be used as a backup in case of urgent matters, for example not being able to get in contact with a team member through messenger.
Aside from these, the team will be using Workflowy to assign small tasks that are promptly due or ones that may not necessarily fit on the gantt chart because they are minor - this tool will be used to delegate a small to-do list for each team member .
\section{Team Member Roles}
Vaibhav Chadha:
\begin{itemize}
\item Latex Documentation
\item Analyst - makes sure the requirements of the clients are met through the software
\item gantt chart management\\
\end{itemize}
Usman Irfan:
\begin{itemize}
\item Scribe
\item Technology Research
\item operation manager -ensures project development is running smoothly and software is being developed according to milestones \\
\end{itemize}
Andy Hameed:
\begin{itemize}
\item Final editing
\item latex documentation
\item team leader\\
\end{itemize}
All:
\begin{itemize}
\item GIT project management
\end{itemize}
\section{Git Workflow Plan}
We will be using the Git Feature Branch Workflow to manage the software development. Using branches, each team member is capable of
working on different modules or sections of the software at the same time in localized branches, before pushing their changes to the master branch.
The following procedures will be followed:
\begin{itemize}
\item Vaibhav will be tagging any major milestones for final submission. This makes the submission process consistent. Otherwise, Andy or Usman will agree on one person to tag and submit for final submission.
\item Any major changes can be placed in a branch to avoid merging conflicts and overwriting existing work. They can be merged later on upon team agreement.
\end{itemize}
\section{Proof of Concept Demonstration Plan}
The original project is built using Javascript, HTML and CSS in contrast to our development plan using python and the Pygame library. Since we are using an OOP language, we will be able to create classes for different components of the snake game such as the snake unit block, snake body, and snake bate. The hardest part of the implementation will be the movement of the snake according to the user's keyboard inputs, and second to that would be the process of expanding the snake once a food item is captured. Besides that, the interface may be difficult to implement in python but could be simple with the use of a python framework such as PyQT5.\\
Once our game application has been developed the next part would be to test the project and for that we will be using Pytest, since our backend language is python this will help us test all possible functions and aspects. The functions that will be difficult to test would be to see if the snake eats the food, does the food appear at random locations after eaten by the snake and if the snake tries to leave the borders, will the game end. Portability will have to be taken into consideration since the application is being built for windows. However, it can be compiled and run on any system as long as the necessary files and libraries are download.
\subsection{POC Demo}
The team will be demonstrating the movement of a snake around the screen using unit blocks for the body of the snake. Lengthening the snake body, scoring and eating the bate will not be demonstrated in the demo. This POC should demonstrate that with the movement of the snake, which is the main component of the game, the team will be able to develop classes to represent other components of the game such as the score, food bate, and lengthening of the snake body.
\section{Technology}
Coding Language: Python, Kivy for GUI\\
IDE: IDLE scripting\\
Testing: PyUnit testing\\
Documentation: Doxygen\\
\section{Coding Style}
We will be using the \href{https://github.com/google/styleguide/blob/gh-pages/pyguide.md}{Google Python Style Guide}
for our coding style. It encompasses all the necessary naming conventions and standards required for the project development.
\section{Project Schedule}
Please see the following pages for the project schedule in the form of a gantt chart.
\includepdf[page=-]{../../ProjectSchedule/Team_Gantt}
\section{Project Review}
\end{document}
\ No newline at end of file
BlankProjectTemplate/Doc_Revision1/ProblemStatement/ProblemStatement.pdf 0 → 100644
View file @ 0671a4ab
File added
BlankProjectTemplate/Doc_Revision1/ProblemStatement/ProblemStatement.tex 0 → 100644
View file @ 0671a4ab
\documentclass{article}
\usepackage{tabularx}
\usepackage{booktabs}
\title{SE 3XA3: Problem Statement\\ \textbf{Snake Game}}
\author{Team \#30, VUA30
\\ Usman Irfan - irfanm7
\\ Andy Hameed - hameea1
\\ Vaibhav Chadha - chadhav
}
\date{2018-09-21}
\usepackage[left=2cm, right=5cm, top=2cm]{geometry}
\begin{document}
\begin{table}[hp]
\caption{Revision History} \label{TblRevisionHistory}
\begin{tabularx}{\textwidth}{llX}
\toprule
\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
\midrule
2018-09-20 & Vaibhav & Made the LaTeX file and wrote the section with what the Problem is\\
2018-09-20 & Usman & Added the Importance of Problem section while formatting the LaTeX\\
2018-09-21 & Andy Hameed & Formatted LaTeX file and added Context section, giving the final editing to the document\\
2018-10-09 & Andy Hameed & Edited doc to reflect web app to desktop app decision change\\
\bottomrule
\end{tabularx}
\end{table}
\newpage
\maketitle
\subsection*{The Problem}
Almost everyone nowadays relies on a computer as a multipurpose tool for research, video streaming, gaming and many other tasks. With the emergence of fast computing, gaming has become a popular pastime activity and a source of entertainment for many. However, not everyone has a device powerful enough to support extensive game applications. A simple, memory effecient application of the Snake game allows it to be accessible for gamers without the need for extensive hardware or a high-performance computer. Our team, VUA30, will be creating a desktop application for the well-known Snake game with new enhancements and features. This competitive and addictive game can allow the user to play at their own pace and challenge their own high score.
\subsection*{Importance of the Problem}
Buying a computing device with high storage and faster performance can be out of budget. Complicated software covers up all the storage and the user is bound to use these applications as opposed to downloading other software. The importance of the redevelopment of The Snake is to save computing devices' personal storage and allow the user to play a game 24/7 with strong performance, even offline. Creating a desktop version of the snake game can fit into the category of downloadable calssical games such as the solitaire suite. The recreation of this game will allow the user to enjoy the classical game anytime and anywhere as long as they have installed the application. Improving aspects such as graphics and custom speed will also make the game more interesting. We would like to add more features to the game to make it more customizable and help people enjoy the classical game in an exciting and new way.
\subsection*{Context}
The stakeholders are mainly the gaming audience, the older generation of game enthusiasts, youth and teens. Some other stakeholders that Although the game can be played by anyone, it is targeted towards the audience mentioned above who are most invested in the game. The environment is native app development using Python. This provides provides less flexibility than web API's but there still exists many useful libraries which can be used such as Pygame for example.
\end{document}
BlankProjectTemplate/Doc/DevelopmentPlan/README.md → BlankProjectTemplate/Doc_Revision1/ProblemStatement/README.md
View file @ 0671a4ab
# Development Plan
# Problem Statement
The folders and files for this folder are as follows:
......
BlankProjectTemplate/Doc_Revision1/SRS/README.md 0 → 100644
View file @ 0671a4ab
# Software Requirements Specification
The folders and files for this folder are as follows:
Describe ...