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
  • liangb30/cas-741-boliang
  • pignierb/cas741
  • jimoha1/cas741
  • huoy8/cas741
  • grandhia/cas741
  • chenq84/cas741
  • yex33/cas741
  • xuey45/cas741
  • garcilau/cas-741-uriel-garcilazo-msa
  • schankuc2/cas741
  • ahmady3/cas741
  • saadh/cas741
  • singhk56/cas741
  • lin523/cas741
  • fangz58/cas741
  • tranp30/cas741
  • ceranich/cas741
  • norouf1/cas741
  • mirzam48/cas741
  • djavahet/cas741
  • hossaa27/cas741
  • yiding_el/cas-741-upate-name
  • sayadia/cas741
  • elmasn2/cas741
  • cheemf8/cas741
  • cheny997/cas741
  • ma209/cas741
  • mousas26/cas741
  • liuy363/cas741
  • wongk124/cas741
  • dua11/cas741
  • zhoug28/cas741
  • courses/cas-741-tst
  • liy443/cas-741-fork-csv
  • sochania/cas741
  • liy443/cas-741-update-csv-old
  • mahdipoa/cas741
  • wangz892/cas741
  • wangn14/cas741
  • defourej/cas741
  • zhaox183/cas741
  • smiths/cas741
42 results
Show changes
Hide whitespace changes
Inline Side-by-side
Showing
with 247 additions and 1372 deletions
BlankProjectTemplate/Doc/SRS/README.md deleted 100644 → 0
View file @ 35121c99
# Software Requirements Specification
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/SRS/SRS.pdf deleted 100644 → 0
View file @ 35121c99
File deleted
BlankProjectTemplate/Doc/SRS/SRS.tex deleted 100644 → 0
View file @ 35121c99
\documentclass[12pt]{article}
\usepackage{amsmath, mathtools}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{graphicx}
\usepackage{colortbl}
\usepackage{xr}
\usepackage{hyperref}
\usepackage{longtable}
\usepackage{xfrac}
\usepackage{tabularx}
\usepackage{float}
\usepackage{siunitx}
\usepackage{booktabs}
\usepackage{caption}
\usepackage{pdflscape}
\usepackage{afterpage}
\usepackage[round]{natbib}
%\usepackage{refcheck}
\hypersetup{
bookmarks=true, % show bookmarks bar?
colorlinks=true, % false: boxed links; true: colored links
linkcolor=red, % color of internal links (change box color with linkbordercolor)
citecolor=green, % color of links to bibliography
filecolor=magenta, % color of file links
urlcolor=cyan % color of external links
}
\input{../Comments}
% For easy change of table widths
\newcommand{\colZwidth}{1.0\textwidth}
\newcommand{\colAwidth}{0.13\textwidth}
\newcommand{\colBwidth}{0.82\textwidth}
\newcommand{\colCwidth}{0.1\textwidth}
\newcommand{\colDwidth}{0.05\textwidth}
\newcommand{\colEwidth}{0.8\textwidth}
\newcommand{\colFwidth}{0.17\textwidth}
\newcommand{\colGwidth}{0.5\textwidth}
\newcommand{\colHwidth}{0.28\textwidth}
% Used so that cross-references have a meaningful prefix
\newcounter{defnum} %Definition Number
\newcommand{\dthedefnum}{GD\thedefnum}
\newcommand{\dref}[1]{GD\ref{#1}}
\newcounter{datadefnum} %Datadefinition Number
\newcommand{\ddthedatadefnum}{DD\thedatadefnum}
\newcommand{\ddref}[1]{DD\ref{#1}}
\newcounter{theorynum} %Theory Number
\newcommand{\tthetheorynum}{T\thetheorynum}
\newcommand{\tref}[1]{T\ref{#1}}
\newcounter{tablenum} %Table Number
\newcommand{\tbthetablenum}{T\thetablenum}
\newcommand{\tbref}[1]{TB\ref{#1}}
\newcounter{assumpnum} %Assumption Number
\newcommand{\atheassumpnum}{P\theassumpnum}
\newcommand{\aref}[1]{A\ref{#1}}
\newcounter{goalnum} %Goal Number
\newcommand{\gthegoalnum}{P\thegoalnum}
\newcommand{\gsref}[1]{GS\ref{#1}}
\newcounter{instnum} %Instance Number
\newcommand{\itheinstnum}{IM\theinstnum}
\newcommand{\iref}[1]{IM\ref{#1}}
\newcounter{reqnum} %Requirement Number
\newcommand{\rthereqnum}{P\thereqnum}
\newcommand{\rref}[1]{R\ref{#1}}
\newcounter{lcnum} %Likely change number
\newcommand{\lthelcnum}{LC\thelcnum}
\newcommand{\lcref}[1]{LC\ref{#1}}
\newcommand{\progname}{ProgName} % PUT YOUR PROGRAM NAME HERE
\usepackage{fullpage}
\begin{document}
\title{Project Title}
\author{Author Name}
\date{\today}
\maketitle
~\newpage
\pagenumbering{roman}
\section{Revision History}
\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
\midrule
Date 1 & 1.0 & Notes\\
Date 2 & 1.1 & Notes\\
\bottomrule
\end{tabularx}
~\newpage
\section{Reference Material}
This section records information for easy reference.
\subsection{Table of Units}
Throughout this document SI (Syst\`{e}me International d'Unit\'{e}s) is employed
as the unit system. In addition to the basic units, several derived units are
used as described below. For each unit, the symbol is given followed by a
description of the unit and the SI name.
~\newline
\renewcommand{\arraystretch}{1.2}
%\begin{table}[ht]
\noindent \begin{tabular}{l l l}
\toprule
\textbf{symbol} & \textbf{unit} & \textbf{SI}\\
\midrule
\si{\metre} & length & metre\\
\si{\kilogram} & mass & kilogram\\
\si{\second} & time & second\\
\si{\celsius} & temperature & centigrade\\
\si{\joule} & energy & Joule\\
\si{\watt} & power & Watt (W = \si{\joule\per\second})\\
\bottomrule
\end{tabular}
% \caption{Provide a caption}
%\end{table}
\wss{Only include the units that your SRS actually uses}
\subsection{Table of Symbols}
The table that follows summarizes the symbols used in this document along with
their units. The choice of symbols was made to be consistent with the heat
transfer literature and with existing documentation for solar water heating
systems. The symbols are listed in alphabetical order.
\renewcommand{\arraystretch}{1.2}
%\noindent \begin{tabularx}{1.0\textwidth}{l l X}
\noindent \begin{longtable*}{l l p{12cm}} \toprule
\textbf{symbol} & \textbf{unit} & \textbf{description}\\
\midrule
$A_C$ & \si[per-mode=symbol] {\square\metre} & coil surface area
\\
$A_\text{in}$ & \si[per-mode=symbol] {\square\metre} & surface area over
which heat is transferred in
\\
\bottomrule
\end{longtable*}
\wss{Use your problems actual symbols. The si package is a good idea to use for
units.}
\subsection{Abbreviations and Acronyms}
\renewcommand{\arraystretch}{1.2}
\begin{tabular}{l l}
\toprule
\textbf{symbol} & \textbf{description}\\
\midrule
A & Assumption\\
DD & Data Definition\\
GD & General Definition\\
GS & Goal Statement\\
IM & Instance Model\\
LC & Likely Change\\
PS & Physical System Description\\
R & Requirement\\
SRS & Software Requirements Specification\\
\progname{} & \wss{put your program name here}\\
T & Theoretical Model\\
\bottomrule
\end{tabular}\\
\wss{Add any other abbreviations or acronyms that you add}
\newpage
\tableofcontents
~\newpage
\pagenumbering{arabic}
\section{Introduction}
\wss{This SRS template is based on \citet{SmithAndLai2005, SmithEtAl2007}. It
will get you started, but you will have to make changes. Any changes to
section headings should be approved by the instructor, since that implies a
deviation from the template. Although the bits shown below do not include
type information, you may need to add this information for your problem.}
\wss{Feel free to change the appearance of the report by modifying the LaTeX
commands.}
\wss{If you are documenting a family of models, you can start from this same
template, but you will have to add a section for variabilities. For program
families you should look at \cite{Smith2006, SmithMcCutchanAndCarette2017}.
You should be able to do one document that captures the commonality analysis
and the requirements.}
\subsection{Purpose of Document}
\subsection{Scope of Requirements}
\subsection{Characteristics of Intended Reader}
\subsection{Organization of Document}
\section{General System Description}
This section identifies the interfaces between the system and its environment,
describes the user characteristics and lists the system constraints.
\subsection{System Context}
\wss{Your system context will likely include an explicit list of user and system
responsibilities}
\begin{itemize}
\item User Responsibilities:
\begin{itemize}
\item
\end{itemize}
\item \progname{} Responsibilities:
\begin{itemize}
\item Detect data type mismatch, such as a string of characters instead of a
floating point number
\item
\end{itemize}
\end{itemize}
\subsection{User Characteristics} \label{SecUserCharacteristics}
The end user of \progname{} should have an understanding of undergraduate Level
1 Calculus and Physics.
\subsection{System Constraints}
\wss{You may not have any system constraints}
\section{Specific System Description}
This section first presents the problem description, which gives a high-level
view of the problem to be solved. This is followed by the solution characteristics
specification, which presents the assumptions, theories, definitions and finally
the instance models. \wss{Add any project specific details that are relevant
for the section overview.}
\subsection{Problem Description} \label{Sec_pd}
\progname{} is \wss{what problem does your program solve?}
\subsubsection{Terminology and Definitions}
This subsection provides a list of terms that are used in the subsequent
sections and their meaning, with the purpose of reducing ambiguity and making it
easier to correctly understand the requirements:
\begin{itemize}
\item
\end{itemize}
\subsubsection{Physical System Description}
The physical system of \progname{}, as shown in Figure~?,
includes the following elements:
\begin{itemize}
\item[PS1:]
\item[PS2:] ...
\end{itemize}
\wss{A figure here may make sense for most SRS documents}
% \begin{figure}[h!]
% \begin{center}
% %\rotatebox{-90}
% {
% \includegraphics[width=0.5\textwidth]{<FigureName>}
% }
% \caption{\label{<Label>} <Caption>}
% \end{center}
% \end{figure}
\subsubsection{Goal Statements}
\noindent Given the \wss{inputs}, the goal statements are:
\begin{itemize}
\item[GS\refstepcounter{goalnum}\thegoalnum \label{G_meaningfulLabel}:] \wss{One
sentence description of the goal. There may be more than one. Each Goal
should have a meaningful label.}
\end{itemize}
\subsection{Solution Characteristics Specification}
The instance models that govern \progname{} are presented in
Subsection~\ref{sec_instance}. The information to understand the meaning of the
instance models and their derivation is also presented, so that the instance
models can be verified.
\subsubsection{Assumptions}
This section simplifies the original problem and helps in developing the
theoretical model by filling in the missing information for the physical
system. The numbers given in the square brackets refer to the theoretical model
[T], general definition [GD], data definition [DD], instance model [IM], or
likely change [LC], in which the respective assumption is used.
\begin{itemize}
\item[A\refstepcounter{assumpnum}\theassumpnum \label{A_meaningfulLabel}:]
\wss{Short description of each assumption. Each assumption
should have a meaningful label. Use cross-references to identify the
appropriate traceability to T, GD, DD etc., using commands like dref, ddref etc.}
\end{itemize}
\subsubsection{Theoretical Models}\label{sec_theoretical}
This section focuses on the general equations and laws that \progname{} is based
on. \wss{Modify the examples below for your problem, and add additional models
as appropriate.}
~\newline
\noindent
\begin{minipage}{\textwidth}
\renewcommand*{\arraystretch}{1.5}
\begin{tabular}{| p{\colAwidth} | p{\colBwidth}|}
\hline
\rowcolor[gray]{0.9}
Number& T\refstepcounter{theorynum}\thetheorynum \label{T_COE}\\
\hline
Label&\bf Conservation of thermal energy\\
\hline
Equation& $-{\bf \nabla \cdot q} + g$ = $\rho C \frac{\partial T}{\partial t}$\\
\hline
Description &
The above equation gives the conservation of energy for transient heat transfer in a material
of specific heat capacity $C$ (\si{\joule\per\kilogram\per\celsius}) and density $\rho$
(\si{\kilogram\per\cubic\metre}), where $\bf q$ is the thermal flux vector (\si{\watt\per\square\metre}),
$g$ is the volumetric heat generation
(\si{\watt\per\cubic\metre}), $T$ is the temperature
(\si{\celsius}), $t$ is time (\si{\second}), and $\nabla$ is
the gradient operator. For this equation to apply, other forms
of energy, such as mechanical energy, are assumed to be negligible in the
system (\aref{A_OnlyThermalEnergy}). In general, the material properties ($\rho$ and $C$) depend on temperature.\\
\hline
Source &
\url{http://www.efunda.com/formulae/heat_transfer/conduction/overview_cond.cfm}\\
% The above web link should be replaced with a proper citation to a publication
\hline
Ref.\ By & \dref{ROCT}\\
\hline
\end{tabular}
\end{minipage}\\
~\newline
\subsubsection{General Definitions}\label{sec_gendef}
This section collects the laws and equations that will be used in deriving the
data definitions, which in turn are used to build the instance models.
\wss{Some projects may not have any content for this section, but the section
heading should be kept.} \wss{Modify the examples below for your problem, and
add additional definitions as appropriate.}
~\newline
\noindent
\begin{minipage}{\textwidth}
\renewcommand*{\arraystretch}{1.5}
\begin{tabular}{| p{\colAwidth} | p{\colBwidth}|}
\hline
\rowcolor[gray]{0.9}
Number& GD\refstepcounter{defnum}\thedefnum \label{NL}\\
\hline
Label &\bf Newton's law of cooling \\
\hline
% Units&$MLt^{-3}T^0$\\
% \hline
SI Units&\si{\watt\per\square\metre}\\
\hline
Equation&$ q(t) = h \Delta T(t)$ \\
\hline
Description &
Newton's law of cooling describes convective cooling from a surface. The law is
stated as: the rate of heat loss from a body is proportional to the difference
in temperatures between the body and its surroundings.
\\
& $q(t)$ is the thermal flux (\si{\watt\per\square\metre}).\\
& $h$ is the heat transfer coefficient, assumed independent of $T$ (\aref{A_hcoeff})
(\si{\watt\per\square\metre\per\celsius}).\\
&$\Delta T(t)$= $T(t) - T_{\text{env}}(t)$ is the time-dependent thermal gradient
between the environment and the object (\si{\celsius}).
\\
\hline
Source &~\cite[p.\ 8]{Incropera2007}\\
\hline
Ref.\ By & \ddref{FluxCoil}, \ddref{FluxPCM}\\
\hline
\end{tabular}
\end{minipage}\\
\subsubsection*{Detailed derivation of simplified rate of change of temperature}
\wss{This may be necessary when the necessary information does not fit in the
description field.}
\subsubsection{Data Definitions}\label{sec_datadef}
This section collects and defines all the data needed to build the instance
models. The dimension of each quantity is also given. \wss{Modify the examples
below for your problem, and add additional definitions as appropriate.}
~\newline
\noindent
\begin{minipage}{\textwidth}
\renewcommand*{\arraystretch}{1.5}
\begin{tabular}{| p{\colAwidth} | p{\colBwidth}|}
\hline
\rowcolor[gray]{0.9}
Number& DD\refstepcounter{datadefnum}\thedatadefnum \label{FluxCoil}\\
\hline
Label& \bf Heat flux out of coil\\
\hline
Symbol &$q_C$\\
\hline
% Units& $Mt^{-3}$\\
% \hline
SI Units & \si{\watt\per\square\metre}\\
\hline
Equation&$q_C(t) = h_C (T_C - T_W(t))$, over area $A_C$\\
\hline
Description &
$T_C$ is the temperature of the coil (\si{\celsius}). $T_W$ is the temperature of the water (\si{\celsius}).
The heat flux out of the coil, $q_C$ (\si{\watt\per\square\metre}), is found by
assuming that Newton's Law
of Cooling applies (\aref{A_Newt_coil}). This law (\dref{NL}) is used on the surface of
the coil, which has area $A_C$ (\si{\square\metre}) and heat
transfer coefficient $h_C$
(\si{\watt\per\square\metre\per\celsius}). This equation
assumes that the temperature of the coil is constant over time (\aref{A_tcoil}) and that it does not vary along the length
of the coil (\aref{A_tlcoil}).
\\
\hline
Sources&~\cite{Lightstone2012} \\
\hline
Ref.\ By & \iref{ewat}\\
\hline
\end{tabular}
\end{minipage}\\
\subsubsection{Instance Models} \label{sec_instance}
This section transforms the problem defined in Section~\ref{Sec_pd} into
one which is expressed in mathematical terms. It uses concrete symbols defined
in Section~\ref{sec_datadef} to replace the abstract symbols in the models
identified in Sections~\ref{sec_theoretical} and~\ref{sec_gendef}.
The goals \wss{reference your goals} are solved by \wss{reference your instance
models}. \wss{other details, with cross-references where appropriate.}
\wss{Modify the examples below for your problem, and add additional models as
appropriate.}
~\newline
%Instance Model 1
\noindent
\begin{minipage}{\textwidth}
\renewcommand*{\arraystretch}{1.5}
\begin{tabular}{| p{\colAwidth} | p{\colBwidth}|}
\hline
\rowcolor[gray]{0.9}
Number& IM\refstepcounter{instnum}\theinstnum \label{ewat}\\
\hline
Label& \bf Energy balance on water to find $T_W$\\
\hline
Input&$m_W$, $C_W$, $h_C$, $A_C$, $h_P$, $A_P$, $t_\text{final}$, $T_C$,
$T_\text{init}$, $T_P(t)$ from \iref{epcm}\\
& The input is constrained so that $T_\text{init} \leq T_C$ (\aref{A_charge})\\
\hline
Output&$T_W(t)$, $0\leq t \leq t_\text{final}$, such that\\
&$\frac{dT_W}{dt} = \frac{1}{\tau_W}[(T_C - T_W(t)) + {\eta}(T_P(t) - T_W(t))]$,\\
&$T_W(0) = T_P(0) = T_\text{init}$ (\aref{A_InitTemp}) and $T_P(t)$ from \iref{epcm} \\
\hline
Description&$T_W$ is the water temperature (\si{\celsius}).\\
&$T_P$ is the PCM temperature (\si{\celsius}).\\
&$T_C$ is the coil temperature (\si{\celsius}).\\
&$\tau_W = \frac{m_W C_W}{h_C A_C}$ is a constant (\si{\second}).\\
&$\eta = \frac{h_P A_P}{h_C A_C}$ is a constant (dimensionless).\\
& The above equation applies as long as the water is in liquid form,
$0<T_W<100^o\text{C}$, where $0^o\text{C}$ and $100^o\text{C}$ are the melting
and boiling points of water, respectively (\aref{A_OpRange}, \aref{A_Pressure}).
\\
\hline
Sources&~\cite{Lightstone2012} \ \\
\hline
Ref.\ By & \iref{epcm}\\
\hline
\end{tabular}
\end{minipage}\\
%~\newline
\subsubsection*{Derivation of ...}
\wss{May be necessary to include this subsection in some cases.}
\subsubsection{Data Constraints} \label{sec_DataConstraints}
Tables~\ref{TblInputVar} and \ref{TblOutputVar} show the data constraints on the
input and output variables, respectively. The column for physical constraints gives
the physical limitations on the range of values that can be taken by the
variable. The column for software constraints restricts the range of inputs to
reasonable values. The constraints are conservative, to give the user of the
model the flexibility to experiment with unusual situations. The column of
typical values is intended to provide a feel for a common scenario. The
uncertainty column provides an estimate of the confidence with which the
physical quantities can be measured. This information would be part of the
input if one were performing an uncertainty quantification exercise.
The specification parameters in Table~\ref{TblInputVar} are listed in
Table~\ref{TblSpecParams}.
\begin{table}[!h]
\caption{Input Variables} \label{TblInputVar}
\renewcommand{\arraystretch}{1.2}
\noindent \begin{longtable*}{l l l l c}
\toprule
\textbf{Var} & \textbf{Physical Constraints} & \textbf{Software Constraints} &
\textbf{Typical Value} & \textbf{Uncertainty}\\
\midrule
$L$ & $L > 0$ & $L_{\text{min}} \leq L \leq L_{\text{max}}$ & 1.5 \si[per-mode=symbol] {\metre} & 10\%
\\
\bottomrule
\end{longtable*}
\end{table}
\noindent
\begin{description}
\item[(*)] \wss{you might need to add some notes or clarifications}
\end{description}
\begin{table}[!h]
\caption{Specification Parameter Values} \label{TblSpecParams}
\renewcommand{\arraystretch}{1.2}
\noindent \begin{longtable*}{l l}
\toprule
\textbf{Var} & \textbf{Value} \\
\midrule
$L_\text{min}$ & 0.1 \si{\metre}\\
\bottomrule
\end{longtable*}
\end{table}
\begin{table}[!h]
\caption{Output Variables} \label{TblOutputVar}
\renewcommand{\arraystretch}{1.2}
\noindent \begin{longtable*}{l l}
\toprule
\textbf{Var} & \textbf{Physical Constraints} \\
\midrule
$T_W$ & $T_\text{init} \leq T_W \leq T_C$ (by~\aref{A_charge})
\\
\bottomrule
\end{longtable*}
\end{table}
\subsubsection{Properties of a Correct Solution} \label{sec_CorrectSolution}
\noindent
A correct solution must exhibit \wss{fill in the details}
\section{Requirements}
This section provides the functional requirements, the business tasks that the
software is expected to complete, and the nonfunctional requirements, the
qualities that the software is expected to exhibit.
\subsection{Functional Requirements}
\noindent \begin{itemize}
\item[R\refstepcounter{reqnum}\thereqnum \label{R_Inputs}:] \wss{Requirements
for the inputs that are supplied by the user. This information has to be
explicit.}
\item[R\refstepcounter{reqnum}\thereqnum \label{R_OutputInputs}:] \wss{It isn't
always required, but often echoing the inputs as part of the output is a
good idea.}
\item[R\refstepcounter{reqnum}\thereqnum \label{R_Calculate}:] \wss{Calculation
related requirements.}
\item[R\refstepcounter{reqnum}\thereqnum \label{R_VerifyOutput}:]
\wss{Verification related requirements.}
\item[R\refstepcounter{reqnum}\thereqnum \label{R_Output}:] \wss{Output related
requirements.}
\end{itemize}
\subsection{Nonfunctional Requirements}
\wss{List your nonfunctional requirements. You may consider using a fit
criterion to make them verifiable.}
\section{Likely Changes}
\noindent \begin{itemize}
\item[LC\refstepcounter{lcnum}\thelcnum\label{LC_meaningfulLabel}:] \wss{Give
the likely changes, with a reference to the related assumption (aref), as appropriate.}
\end{itemize}
\section{Traceability Matrices and Graphs}
The purpose of the traceability matrices is to provide easy references on what
has to be additionally modified if a certain component is changed. Every time a
component is changed, the items in the column of that component that are marked
with an ``X'' may have to be modified as well. Table~\ref{Table:trace} shows the
dependencies of theoretical models, general definitions, data definitions, and
instance models with each other. Table~\ref{Table:R_trace} shows the
dependencies of instance models, requirements, and data constraints on each
other. Table~\ref{Table:A_trace} shows the dependencies of theoretical models,
general definitions, data definitions, instance models, and likely changes on
the assumptions.
\wss{You will have to modify these tables for your problem.}
\afterpage{
\begin{landscape}
\begin{table}[h!]
\centering
\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|}
\hline
& \aref{A_OnlyThermalEnergy}& \aref{A_hcoeff}& \aref{A_mixed}& \aref{A_tpcm}& \aref{A_const_density}& \aref{A_const_C}& \aref{A_Newt_coil}& \aref{A_tcoil}& \aref{A_tlcoil}& \aref{A_Newt_pcm}& \aref{A_charge}& \aref{A_InitTemp}& \aref{A_OpRangePCM}& \aref{A_OpRange}& \aref{A_htank}& \aref{A_int_heat}& \aref{A_vpcm}& \aref{A_PCM_state}& \aref{A_Pressure} \\
\hline
\tref{T_COE} & X& & & & & & & & & & & & & & & & & & \\ \hline
\tref{T_SHE} & & & & & & & & & & & & & & & & & & & \\ \hline
\tref{T_LHE} & & & & & & & & & & & & & & & & & & & \\ \hline
\dref{NL} & & X& & & & & & & & & & & & & & & & & \\ \hline
\dref{ROCT} & & & X& X& X& X& & & & & & & & & & & & & \\ \hline
\ddref{FluxCoil} & & & & & & & X& X& X& & & & & & & & & & \\ \hline
\ddref{FluxPCM} & & & X& X& & & & & & X& & & & & & & & & \\ \hline
\ddref{D_HOF} & & & & & & & & & & & & & & & & & & & \\ \hline
\ddref{D_MF} & & & & & & & & & & & & & & & & & & & \\ \hline
\iref{ewat} & & & & & & & & & & & X& X& & X& X& X& & & X \\ \hline
\iref{epcm} & & & & & & & & & & & & X& X& & & X& X& X& \\ \hline
\iref{I_HWAT} & & & & & & & & & & & & & & X& & & & & X \\ \hline
\iref{I_HPCM} & & & & & & & & & & & & & X& & & & & X & \\ \hline
\lcref{LC_tpcm} & & & & X& & & & & & & & & & & & & & & \\ \hline
\lcref{LC_tcoil} & & & & & & & & X& & & & & & & & & & & \\ \hline
\lcref{LC_tlcoil} & & & & & & & & & X& & & & & & & & & & \\ \hline
\lcref{LC_charge} & & & & & & & & & & & X& & & & & & & & \\ \hline
\lcref{LC_InitTemp} & & & & & & & & & & & & X& & & & & & & \\ \hline
\lcref{LC_htank} & & & & & & & & & & & & & & & X& & & & \\
\hline
\end{tabular}
\caption{Traceability Matrix Showing the Connections Between Assumptions and Other Items}
\label{Table:A_trace}
\end{table}
\end{landscape}
}
\begin{table}[h!]
\centering
\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|}
\hline
& \tref{T_COE}& \tref{T_SHE}& \tref{T_LHE}& \dref{NL}& \dref{ROCT} & \ddref{FluxCoil}& \ddref{FluxPCM} & \ddref{D_HOF}& \ddref{D_MF}& \iref{ewat}& \iref{epcm}& \iref{I_HWAT}& \iref{I_HPCM} \\
\hline
\tref{T_COE} & & & & & & & & & & & & & \\ \hline
\tref{T_SHE} & & & X& & & & & & & & & & \\ \hline
\tref{T_LHE} & & & & & & & & & & & & & \\ \hline
\dref{NL} & & & & & & & & & & & & & \\ \hline
\dref{ROCT} & X& & & & & & & & & & & & \\ \hline
\ddref{FluxCoil} & & & & X& & & & & & & & & \\ \hline
\ddref{FluxPCM} & & & & X& & & & & & & & & \\ \hline
\ddref{D_HOF} & & & & & & & & & & & & & \\ \hline
\ddref{D_MF} & & & & & & & & X& & & & & \\ \hline
\iref{ewat} & & & & & X& X& X& & & & X& & \\ \hline
\iref{epcm} & & & & & X& & X& & X& X& & & X \\ \hline
\iref{I_HWAT} & & X& & & & & & & & & & & \\ \hline
\iref{I_HPCM} & & X& X& & & & X& X& X& & X& & \\
\hline
\end{tabular}
\caption{Traceability Matrix Showing the Connections Between Items of Different Sections}
\label{Table:trace}
\end{table}
\begin{table}[h!]
\centering
\begin{tabular}{|c|c|c|c|c|c|c|c|}
\hline
& \iref{ewat}& \iref{epcm}& \iref{I_HWAT}& \iref{I_HPCM}& \ref{sec_DataConstraints}& \rref{R_RawInputs}& \rref{R_MassInputs} \\
\hline
\iref{ewat} & & X& & & & X& X \\ \hline
\iref{epcm} & X& & & X& & X& X \\ \hline
\iref{I_HWAT} & & & & & & X& X \\ \hline
\iref{I_HPCM} & & X& & & & X& X \\ \hline
\rref{R_RawInputs} & & & & & & & \\ \hline
\rref{R_MassInputs} & & & & & & X& \\ \hline
\rref{R_CheckInputs} & & & & & X& & \\ \hline
\rref{R_OutputInputs} & X& X& & & & X& X \\ \hline
\rref{R_TempWater} & X& & & & & & \\ \hline
\rref{R_TempPCM} & & X& & & & & \\ \hline
\rref{R_EnergyWater} & & & X& & & & \\ \hline
\rref{R_EnergyPCM} & & & & X& & & \\ \hline
\rref{R_VerifyOutput} & & & X& X& & & \\ \hline
\rref{R_timeMeltBegin} & & X& & & & & \\ \hline
\rref{R_timeMeltEnd} & & X& & & & & \\
\hline
\end{tabular}
\caption{Traceability Matrix Showing the Connections Between Requirements and Instance Models}
\label{Table:R_trace}
\end{table}
The purpose of the traceability graphs is also to provide easy references on
what has to be additionally modified if a certain component is changed. The
arrows in the graphs represent dependencies. The component at the tail of an
arrow is depended on by the component at the head of that arrow. Therefore, if a
component is changed, the components that it points to should also be
changed. Figure~\ref{Fig_ATrace} shows the dependencies of theoretical models,
general definitions, data definitions, instance models, likely changes, and
assumptions on each other. Figure~\ref{Fig_RTrace} shows the dependencies of
instance models, requirements, and data constraints on each other.
% \begin{figure}[h!]
% \begin{center}
% %\rotatebox{-90}
% {
% \includegraphics[width=\textwidth]{ATrace.png}
% }
% \caption{\label{Fig_ATrace} Traceability Matrix Showing the Connections Between Items of Different Sections}
% \end{center}
% \end{figure}
% \begin{figure}[h!]
% \begin{center}
% %\rotatebox{-90}
% {
% \includegraphics[width=0.7\textwidth]{RTrace.png}
% }
% \caption{\label{Fig_RTrace} Traceability Matrix Showing the Connections Between Requirements, Instance Models, and Data Constraints}
% \end{center}
% \end{figure}
\newpage
\bibliographystyle {plainnat}
\bibliography {../../ReferenceMaterial/References}
\newpage
\section{Appendix}
\wss{Your report may require an appendix. For instance, this is a good point to
show the values of the symbolic parameters introduced in the report.}
\subsection{Symbolic Parameters}
\wss{The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
Their values are defined in this section for easy maintenance.}
\end{document}
\ No newline at end of file
BlankProjectTemplate/Doc/UserGuide/README.md deleted 100644 → 0
View file @ 35121c99
# User Guide (Optional)
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/VnVPlan/README.md deleted 100644 → 0
View file @ 35121c99
# Test Plan
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/VnVPlan/TestPlan.pdf deleted 100644 → 0
View file @ 35121c99
File deleted
BlankProjectTemplate/Doc/VnVPlan/TestPlan.tex deleted 100644 → 0
View file @ 35121c99
\documentclass[12pt, titlepage]{article}
\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{hyperref}
\hypersetup{
colorlinks,
citecolor=black,
filecolor=black,
linkcolor=red,
urlcolor=blue
}
\usepackage[round]{natbib}
\input{../Comments}
\begin{document}
\title{Project Title}
\author{Author Name}
\date{\today}
\maketitle
\pagenumbering{roman}
\section{Revision History}
\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
\midrule
Date 1 & 1.0 & Notes\\
Date 2 & 1.1 & Notes\\
\bottomrule
\end{tabularx}
~\newpage
\section{Symbols, Abbreviations and Acronyms}
\renewcommand{\arraystretch}{1.2}
\begin{tabular}{l l}
\toprule
\textbf{symbol} & \textbf{description}\\
\midrule
T & Test\\
\bottomrule
\end{tabular}\\
\wss{symbols, abbreviations or acronyms -- you can reference the SRS tables if needed}
\newpage
\tableofcontents
\listoftables
\listoffigures
\newpage
\pagenumbering{arabic}
This document ...
\section{General Information}
\subsection{Purpose}
\subsection{Scope}
\subsection{Overview of Document}
\section{Plan}
\subsection{Software Description}
\subsection{Test Team}
\wss{Probably just you. :-)}
\subsection{Automated Testing Approach}
\subsection{Verification Tools}
\wss{Thoughts on what tools to use, such as the following: unit testing
framework, valgrind, static analyzer, make, continuous integration, test
coverage tool, etc.}
% \subsection{Testing Schedule}
% See Gantt Chart at the following url ...
\subsection{Non-Testing Based Verification}
\wss{List any approaches like code inspection, code walkthrough, symbolic
execution etc. Enter not applicable if that is the case.}
\section{System Test Description}
\subsection{Tests for Functional Requirements}
\subsubsection{Area of Testing1}
\paragraph{Title for Test}
\begin{enumerate}
\item{test-id1\\}
Type: Functional, Dynamic, Manual, Static etc.
Initial State:
Input:
Output:
How test will be performed:
\item{test-id2\\}
Type: Functional, Dynamic, Manual, Static etc.
Initial State:
Input:
Output:
How test will be performed:
\end{enumerate}
\subsubsection{Area of Testing2}
...
\subsection{Tests for Nonfunctional Requirements}
\subsubsection{Area of Testing1}
\paragraph{Title for Test}
\begin{enumerate}
\item{test-id1\\}
Type:
Initial State:
Input/Condition:
Output/Result:
How test will be performed:
\item{test-id2\\}
Type: Functional, Dynamic, Manual, Static etc.
Initial State:
Input:
Output:
How test will be performed:
\end{enumerate}
\subsubsection{Area of Testing2}
...
\subsection{Traceability Between Test Cases and Requirements}
% \section{Tests for Proof of Concept}
% \subsection{Area of Testing1}
% \paragraph{Title for Test}
% \begin{enumerate}
% \item{test-id1\\}
% Type: Functional, Dynamic, Manual, Static etc.
% Initial State:
% Input:
% Output:
% How test will be performed:
% \item{test-id2\\}
% Type: Functional, Dynamic, Manual, Static etc.
% Initial State:
% Input:
% Output:
% How test will be performed:
% \end{enumerate}
% \subsection{Area of Testing2}
% ...
\section{Unit Testing Plan}
\wss{Unit testing plans for internal functions and, if appropriate, output
files}
\bibliographystyle{plainnat}
\bibliography{SRS}
\newpage
\section{Appendix}
This is where you can place additional information.
\subsection{Symbolic Parameters}
The definition of the test cases will call for SYMBOLIC\_CONSTANTS.
Their values are defined in this section for easy maintenance.
\subsection{Usability Survey Questions?}
This is a section that would be appropriate for some teams.
\end{document}
\ No newline at end of file
BlankProjectTemplate/Doc/VnVReport/README.md deleted 100644 → 0
View file @ 35121c99
# Test Report
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/VnVReport/TestReport.pdf deleted 100644 → 0
View file @ 35121c99
File deleted
BlankProjectTemplate/Doc/VnVReport/TestReport.tex deleted 100644 → 0
View file @ 35121c99
\documentclass[12pt, titlepage]{article}
\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{hyperref}
\hypersetup{
colorlinks,
citecolor=black,
filecolor=black,
linkcolor=red,
urlcolor=blue
}
\usepackage[round]{natbib}
\input{../Comments}
\begin{document}
\title{Test Report: Project Title}
\author{Author Name}
\date{\today}
\maketitle
\pagenumbering{roman}
\section{Revision History}
\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
\midrule
Date 1 & 1.0 & Notes\\
Date 2 & 1.1 & Notes\\
\bottomrule
\end{tabularx}
~\newpage
\section{Symbols, Abbreviations and Acronyms}
\renewcommand{\arraystretch}{1.2}
\begin{tabular}{l l}
\toprule
\textbf{symbol} & \textbf{description}\\
\midrule
T & Test\\
\bottomrule
\end{tabular}\\
\wss{symbols, abbreviations or acronyms -- you can reference the SRS tables if needed}
\newpage
\tableofcontents
\listoftables %if appropriate
\listoffigures %if appropriate
\newpage
\pagenumbering{arabic}
This document ...
\section{Functional Requirements Evaluation}
\section{Nonfunctional Requirements Evaluation}
\subsection{Usability}
\subsection{Performance}
\subsection{etc.}
\section{Comparison to Existing Implementation}
This section will not be appropriate for every project.
\section{Unit Testing}
\section{Changes Due to Testing}
\section{Automated Testing}
\section{Trace to Requirements}
\section{Trace to Modules}
\section{Code Coverage Metrics}
\bibliographystyle{plainnat}
\bibliography{SRS}
\end{document}
\ No newline at end of file
BlankProjectTemplate/LICENSE.txt deleted 100644 → 0
View file @ 35121c99
LICENSE Information
\ No newline at end of file
BlankProjectTemplate/README.md deleted 100644 → 0
View file @ 35121c99
# Project Name
Developer Name:
This project is a reimplementation of ...
The folders and files for this project are as follows:
Doc - Documentation for the project
Code - Implementation
…
\ No newline at end of file
BlankProjectTemplate/ReferenceMaterial/README.md deleted 100644 → 0
View file @ 35121c99
# Project Name
This folder holds information and resources of interest for the project. This
is intended to be a convenient location for project members to access
support material for the project.
References are named using the Nat Bib convention. That is, the citation name,
and the corresponding file name should be in the format AuthorYear. If there is
two author's the name should be Author1Author2Year. For more than two authors,
the name should be Author1EtAlYear. In the preceding text, Author, Author1 and
Author2 are the last names of the authors.
BlankProjectTemplate/ReferenceMaterial/References.bib deleted 100644 → 0
View file @ 35121c99
%% This BibTeX bibliography file was created using BibDesk.
%% http://bibdesk.sourceforge.net/
%% Created for Spencer Smith at 2017-11-10 06:27:41 -0500
%% Saved with string encoding Unicode (UTF-8)
@book{GhezziEtAl2003,
Address = {Upper Saddle River, NJ, USA},
Author = {Carlo Ghezzi and Mehdi Jazayeri and Dino Mandrioli},
Date-Added = {2017-11-10 11:27:31 +0000},
Date-Modified = {2017-11-10 11:27:31 +0000},
Edition = {2nd},
Keywords = {software engineering},
Publisher = {Prentice Hall},
Title = {Fundamentals of Software Engineering},
Year = {2003}}
@book{HoffmanAndStrooper1995,
Address = {New York, NY, USA},
Author = {Daniel M. Hoffman and Paul A. Strooper},
Date-Added = {2017-11-10 11:27:24 +0000},
Date-Modified = {2017-11-10 11:27:24 +0000},
Local-Url = {file://localhost/Users/smiths/LongTermArchives/Work/Research/References/SoftwareEngineering/software-design-automated-testing.pdf},
Publisher = {International Thomson Computer Press},
Title = {Software Design, Automated Testing, and Maintenance: A Practical Approach},
Url = {http:// citeseer.ist.psu.edu/428727.html},
Year = {1995},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QPC4uLy4uLy4uL3NlM3hhMy9SZWZlcmVuY2VNYXRlcmlhbC9Ib2ZmbWFuQW5kU3Ryb29wZXIxOTk1LnBkZtIXCxgZV05TLmRhdGFPEQHqAAAAAAHqAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAnHusUaSG9mZm1hbkFuZFN0cm9vcGVyMTk5NS5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgYWv9Q41tAAAAAAAAAAAAADAAMAAAkgAAAAAAAAAAAAAAAAAAAAEVJlZmVyZW5jZU1hdGVyaWFsAAAQAAgAAM6Xq8MAAAARAAgAANQ5DxAAAAABABQJx7rFCcYGMwASFacACPdmAAJkjgACAFhNYWNpbnRvc2ggSEQ6VXNlcnM6AHNtaXRoczoAUmVwb3M6AHNlM3hhMzoAUmVmZXJlbmNlTWF0ZXJpYWw6AEhvZmZtYW5BbmRTdHJvb3BlcjE5OTUucGRmAA4ANgAaAEgAbwBmAGYAbQBhAG4AQQBuAGQAUwB0AHIAbwBvAHAAZQByADEAOQA5ADUALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAEZVc2Vycy9zbWl0aHMvUmVwb3Mvc2UzeGEzL1JlZmVyZW5jZU1hdGVyaWFsL0hvZmZtYW5BbmRTdHJvb3BlcjE5OTUucGRmABMAAS8AABUAAgAN//8AAIAG0hscHR5aJGNsYXNzbmFtZVgkY2xhc3Nlc11OU011dGFibGVEYXRhox0fIFZOU0RhdGFYTlNPYmplY3TSGxwiI1xOU0RpY3Rpb25hcnmiIiBfEA9OU0tleWVkQXJjaGl2ZXLRJidUcm9vdIABAAgAEQAaACMALQAyADcAQABGAE0AVQBgAGcAagBsAG4AcQBzAHUAdwCEAI4AzQDSANoCyALKAs8C2gLjAvEC9QL8AwUDCgMXAxoDLAMvAzQAAAAAAAACAQAAAAAAAAAoAAAAAAAAAAAAAAAAAAADNg==},
Bdsk-Url-1 = {http://%20citeseer.ist.psu.edu/428727.html}}
@techreport{SmithMcCutchanAndCarette2017,
Author = {W. Spencer Smith and John McCutchan and Jacques Carette},
Date-Added = {2017-09-14 19:16:56 +0000},
Date-Modified = {2017-09-14 19:16:56 +0000},
Institution = {McMaster University, Department of Computing and Software},
Number = {CAS-17-01-SS},
Title = {Commonality Analysis for a Family of Material Models},
Type = {Technical Report},
Year = {2017},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QTi4uLy4uLy4uL09MRF9TVk4vbW1zY09MRF9TVk4vRmFtaWx5T2ZNYXRlcmlhbE1vZGVscy9GYW1pbHlPZk1hdGVyaWFsTW9kZWxzLnBkZtIXCxgZV05TLmRhdGFPEQIYAAAAAAIYAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAKR0H8aRmFtaWx5T2ZNYXRlcmlhbE1vZGVscy5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApHQ7NAhLREAAAAAAAAAAAADAAQAAAkgAAAAAAAAAAAAAAAAAAAAFkZhbWlseU9mTWF0ZXJpYWxNb2RlbHMAEAAIAADOl6vDAAAAEQAIAADQIWVRAAAAAQAYApHQfwKRxEwJMf6nABIVpwAI92YAAmSOAAIAa01hY2ludG9zaCBIRDpVc2VyczoAc21pdGhzOgBSZXBvczoAT0xEX1NWTjoAbW1zY09MRF9TVk46AEZhbWlseU9mTWF0ZXJpYWxNb2RlbHM6AEZhbWlseU9mTWF0ZXJpYWxNb2RlbHMucGRmAAAOADYAGgBGAGEAbQBpAGwAeQBPAGYATQBhAHQAZQByAGkAYQBsAE0AbwBkAGUAbABzAC4AcABkAGYADwAaAAwATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAEgBYVXNlcnMvc21pdGhzL1JlcG9zL09MRF9TVk4vbW1zY09MRF9TVk4vRmFtaWx5T2ZNYXRlcmlhbE1vZGVscy9GYW1pbHlPZk1hdGVyaWFsTW9kZWxzLnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOAN8A5ADsAwgDCgMPAxoDIwMxAzUDPANFA0oDVwNaA2wDbwN0AAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA3Y=}}
@inproceedings{SmithEtAl2008,
Address = {Leipzig, Germany},
Author = {W. Spencer Smith and John McCutchan and Jacques Carette},
Booktitle = {Proceedings of the First International Workshop on Software Engineering for Computational Science and Engineering (SECSE 2008)},
Date-Added = {2017-09-14 19:15:18 +0000},
Date-Modified = {2017-09-14 19:15:18 +0000},
Month = {May},
Note = {8 pp},
Organization = {In conjunction with the 30th International Conference on Software Engineering (ICSE)},
Title = {Commonality Analysis of Families of Physical Models for use in Scientific Computing},
Url = {http://www.cse.msstate.edu/~SECSE08/schedule.htm},
Year = {2008},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QPi4uLy4uLy4uL09MRF9TVk4vbW1zY09MRF9TVk4vU0VDU0UwOC9TbWl0aEV0QWxfQXNTdWJtaXR0ZWQucGRm0hcLGBlXTlMuZGF0YU8RAegAAAAAAegAAgAADE1hY2ludG9zaCBIRAAAAAAAAAAAAAAAAAAAAM6Xc4NIKwAAApHRBxlTbWl0aEV0QWxfQXNTdWJtaXR0ZWQucGRmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACkdFu0CEtFAAAAAAAAAAAAAMABAAACSAAAAAAAAAAAAAAAAAAAAAHU0VDU0UwOAAAEAAIAADOl6vDAAAAEQAIAADQIWVUAAAAAQAYApHRBwKRxEwJMf6nABIVpwAI92YAAmSOAAIAW01hY2ludG9zaCBIRDpVc2VyczoAc21pdGhzOgBSZXBvczoAT0xEX1NWTjoAbW1zY09MRF9TVk46AFNFQ1NFMDg6AFNtaXRoRXRBbF9Bc1N1Ym1pdHRlZC5wZGYAAA4ANAAZAFMAbQBpAHQAaABFAHQAQQBsAF8AQQBzAFMAdQBiAG0AaQB0AHQAZQBkAC4AcABkAGYADwAaAAwATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAEgBIVXNlcnMvc21pdGhzL1JlcG9zL09MRF9TVk4vbW1zY09MRF9TVk4vU0VDU0UwOC9TbWl0aEV0QWxfQXNTdWJtaXR0ZWQucGRmABMAAS8AABUAAgAN//8AAIAG0hscHR5aJGNsYXNzbmFtZVgkY2xhc3Nlc11OU011dGFibGVEYXRhox0fIFZOU0RhdGFYTlNPYmplY3TSGxwiI1xOU0RpY3Rpb25hcnmiIiBfEA9OU0tleWVkQXJjaGl2ZXLRJidUcm9vdIABAAgAEQAaACMALQAyADcAQABGAE0AVQBgAGcAagBsAG4AcQBzAHUAdwCEAI4AzwDUANwCyALKAs8C2gLjAvEC9QL8AwUDCgMXAxoDLAMvAzQAAAAAAAACAQAAAAAAAAAoAAAAAAAAAAAAAAAAAAADNg==},
Bdsk-Url-1 = {http://www.cse.msstate.edu/~SECSE08/schedule.htm}}
@inproceedings{Smith2006,
Address = {Minneapolis / St.\ Paul, Minnesota},
Author = {W. Spencer Smith},
Booktitle = {Proceedings of the 14th IEEE International Requirements Engineering Conference, RE 2006},
Date-Added = {2017-09-14 19:15:09 +0000},
Date-Modified = {2017-09-14 19:15:09 +0000},
Local-Url = {/Users/smiths/Work/Research/Papers/RE_2006/Smith2006_VersionAsPublished.pdf},
Pages = {209--218},
Title = {Systematic Development of Requirements Documentation for General Purpose Scientific Computing Software},
Url = {http://www.ifi.unizh.ch/req/events/RE06/},
Year = {2006},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QSS4uLy4uLy4uLy4uL1dvcmsvUmVzZWFyY2gvUGFwZXJzL1JFXzIwMDYvU21pdGgyMDA2X1ZlcnNpb25Bc1B1Ymxpc2hlZC5wZGbSFwsYGVdOUy5kYXRhTxEB+AAAAAAB+AACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAAzpdzg0grAAAAFwtsH1NtaXRoMjAwNl9WZXJzaW9uQXNQIzE3ODg5Mi5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXiJLPIuEzUERGIENBUk8ABAAFAAAJIAAAAAAAAAAAAAAAAAAAAAdSRV8yMDA2AAAQAAgAAM6Xq8MAAAARAAgAAM8jJ4MAAAABABgAFwtsABcCCwAXAE0AFv3tAAj3ZgACZI4AAgBcTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFdvcms6AFJlc2VhcmNoOgBQYXBlcnM6AFJFXzIwMDY6AFNtaXRoMjAwNl9WZXJzaW9uQXNQIzE3ODg5Mi5wZGYADgBCACAAUwBtAGkAdABoADIAMAAwADYAXwBWAGUAcgBzAGkAbwBuAEEAcwBQAHUAYgBsAGkAcwBoAGUAZAAuAHAAZABmAA8AGgAMAE0AYQBjAGkAbgB0AG8AcwBoACAASABEABIASlVzZXJzL3NtaXRocy9Xb3JrL1Jlc2VhcmNoL1BhcGVycy9SRV8yMDA2L1NtaXRoMjAwNl9WZXJzaW9uQXNQdWJsaXNoZWQucGRmABMAAS8AABUAAgAN//8AAIAG0hscHR5aJGNsYXNzbmFtZVgkY2xhc3Nlc11OU011dGFibGVEYXRhox0fIFZOU0RhdGFYTlNPYmplY3TSGxwiI1xOU0RpY3Rpb25hcnmiIiBfEA9OU0tleWVkQXJjaGl2ZXLRJidUcm9vdIABAAgAEQAaACMALQAyADcAQABGAE0AVQBgAGcAagBsAG4AcQBzAHUAdwCEAI4A2gDfAOcC4wLlAuoC9QL+AwwDEAMXAyADJQMyAzUDRwNKA08AAAAAAAACAQAAAAAAAAAoAAAAAAAAAAAAAAAAAAADUQ==},
Bdsk-Url-1 = {http://www.ifi.unizh.ch/req/events/RE06/}}
@article{SmithEtAl2007,
Author = {W. Spencer Smith and Lei Lai and Ridha Khedri},
Date-Added = {2017-09-14 15:47:22 +0000},
Date-Modified = {2017-09-14 15:47:22 +0000},
Journal = {Reliable Computing, Special Issue on Reliable Engineering Computation},
Local-Url = {/Users/smiths/Work/Research/Papers/ReliableComputing/SmithLaiAndKhedri2007fulltext.pdf},
Month = {February},
Number = {1},
Pages = {83--107},
Title = {Requirements Analysis for Engineering Computation: A Systematic Approach for Improving Software Reliability},
Volume = {13},
Year = {2007},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QSC4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1NtaXRoTGFpQW5kS2hlZHJpMjAwN2Z1bGx0ZXh0LnBkZtIXCxgZV05TLmRhdGFPEQIUAAAAAAIUAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAkx/Q0fU21pdGhMYWlBbmRLaGVkcmkyMCM5MzFGRDYwLnBkZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACTH9YNNvBNMAAAAAAAAAAAADAAMAAAkgAAAAAAAAAAAAAAAAAAAAF1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzAAAQAAgAAM6Xq8MAAAARAAgAANNvPRMAAAABABQJMf0NCTHuxwASFacACPdmAAJkjgACAGJNYWNpbnRvc2ggSEQ6VXNlcnM6AHNtaXRoczoAUmVwb3M6AHNlNHNjOgBTY2lDb21wQW5kU29mdEVuZ1BhcGVyczoAU21pdGhMYWlBbmRLaGVkcmkyMCM5MzFGRDYwLnBkZgAOAEQAIQBTAG0AaQB0AGgATABhAGkAQQBuAGQASwBoAGUAZAByAGkAMgAwADAANwBmAHUAbABsAHQAZQB4AHQALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAFJVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvU21pdGhMYWlBbmRLaGVkcmkyMDA3ZnVsbHRleHQucGRmABMAAS8AABUAAgAN//8AAIAG0hscHR5aJGNsYXNzbmFtZVgkY2xhc3Nlc11OU011dGFibGVEYXRhox0fIFZOU0RhdGFYTlNPYmplY3TSGxwiI1xOU0RpY3Rpb25hcnmiIiBfEA9OU0tleWVkQXJjaGl2ZXLRJidUcm9vdIABAAgAEQAaACMALQAyADcAQABGAE0AVQBgAGcAagBsAG4AcQBzAHUAdwCEAI4A2QDeAOYC/gMAAwUDEAMZAycDKwMyAzsDQANNA1ADYgNlA2oAAAAAAAACAQAAAAAAAAAoAAAAAAAAAAAAAAAAAAADbA==},
Bdsk-File-2 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QVC4uLy4uLy4uLy4uL1dvcmsvUmVzZWFyY2gvUGFwZXJzL1JlbGlhYmxlQ29tcHV0aW5nL1NtaXRoTGFpQW5kS2hlZHJpMjAwN2Z1bGx0ZXh0LnBkZtIXCxgZV05TLmRhdGFPEQIaAAAAAAIaAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAAXC24fU21pdGhMYWlBbmRLaGVkcmkyMDAjMTc4ODYzLnBkZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABeIY88i4TNQREYgQ0FSTwAEAAUAAAkgAAAAAAAAAAAAAAAAAAAAEVJlbGlhYmxlQ29tcHV0aW5nAAAQAAgAAM6Xq8MAAAARAAgAAM8jJ4MAAAABABgAFwtuABcCCwAXAE0AFv3tAAj3ZgACZI4AAgBmTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFdvcms6AFJlc2VhcmNoOgBQYXBlcnM6AFJlbGlhYmxlQ29tcHV0aW5nOgBTbWl0aExhaUFuZEtoZWRyaTIwMCMxNzg4NjMucGRmAA4ARAAhAFMAbQBpAHQAaABMAGEAaQBBAG4AZABLAGgAZQBkAHIAaQAyADAAMAA3AGYAdQBsAGwAdABlAHgAdAAuAHAAZABmAA8AGgAMAE0AYQBjAGkAbgB0AG8AcwBoACAASABEABIAVVVzZXJzL3NtaXRocy9Xb3JrL1Jlc2VhcmNoL1BhcGVycy9SZWxpYWJsZUNvbXB1dGluZy9TbWl0aExhaUFuZEtoZWRyaTIwMDdmdWxsdGV4dC5wZGYAABMAAS8AABUAAgAN//8AAIAG0hscHR5aJGNsYXNzbmFtZVgkY2xhc3Nlc11OU011dGFibGVEYXRhox0fIFZOU0RhdGFYTlNPYmplY3TSGxwiI1xOU0RpY3Rpb25hcnmiIiBfEA9OU0tleWVkQXJjaGl2ZXLRJidUcm9vdIABAAgAEQAaACMALQAyADcAQABGAE0AVQBgAGcAagBsAG4AcQBzAHUAdwCEAI4A5QDqAPIDEAMSAxcDIgMrAzkDPQNEA00DUgNfA2IDdAN3A3wAAAAAAAACAQAAAAAAAAAoAAAAAAAAAAAAAAAAAAADfg==}}
@inproceedings{SmithAndLai2005,
Address = {Paris, France},
Author = {W. Spencer Smith and Lei Lai},
Booktitle = {Proceedings of the First International Workshop on Situational Requirements Engineering Processes -- Methods, Techniques and Tools to Support Situation-Specific Requirements Engineering Processes, SREP'05},
Date-Added = {2017-09-14 15:47:18 +0000},
Date-Modified = {2017-09-14 15:47:18 +0000},
Editor = {J. Ralyt\'{e} and P. \.{A}gerfalk and N. Kraiem},
Local-Url = {file://localhost/Users/smiths/Work/Research/Papers/SREP05/SREP05_ReformatAndRevise/SmithAndLai_2005.pdf},
Organization = {In conjunction with 13th IEEE International Requirements Engineering Conference},
Pages = {107--121},
Title = {A New Requirements Template for Scientific Computing},
Year = {2005},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QVS4uLy4uLy4uLy4uL1dvcmsvUmVzZWFyY2gvUGFwZXJzL1NSRVAwNS9TUkVQMDVfUmVmb3JtYXRBbmRSZXZpc2UvU21pdGhBbmRMYWlfMjAwNS5wZGbSFwsYGVdOUy5kYXRhTxECDgAAAAACDgACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAAzpdzg0grAAAAF0DvFFNtaXRoQW5kTGFpXzIwMDUucGRmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXntPPIuJUAAAAAAAAAAAABAAGAAAJIAAAAAAAAAAAAAAAAAAAABhTUkVQMDVfUmVmb3JtYXRBbmRSZXZpc2UAEAAIAADOl6vDAAAAEQAIAADPIyikAAAAAQAcABdA7wAXC3oAFwILABcATQAW/e0ACPdmAAJkjgACAGpNYWNpbnRvc2ggSEQ6VXNlcnM6AHNtaXRoczoAV29yazoAUmVzZWFyY2g6AFBhcGVyczoAU1JFUDA1OgBTUkVQMDVfUmVmb3JtYXRBbmRSZXZpc2U6AFNtaXRoQW5kTGFpXzIwMDUucGRmAA4AKgAUAFMAbQBpAHQAaABBAG4AZABMAGEAaQBfADIAMAAwADUALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAFZVc2Vycy9zbWl0aHMvV29yay9SZXNlYXJjaC9QYXBlcnMvU1JFUDA1L1NSRVAwNV9SZWZvcm1hdEFuZFJldmlzZS9TbWl0aEFuZExhaV8yMDA1LnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOAOYA6wDzAwUDBwMMAxcDIAMuAzIDOQNCA0cDVANXA2kDbANxAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA3M=}}
@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 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QQC4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGbSFwsYGVdOUy5kYXRhTxEB9gAAAAAB9gACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAAzpdzg0grAAAJMf0NGVBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkx/UPTbwTTAAAAAAAAAAAAAwADAAAJIAAAAAAAAAAAAAAAAAAAABdTY2lDb21wQW5kU29mdEVuZ1BhcGVycwAAEAAIAADOl6vDAAAAEQAIAADTbz0TAAAAAQAUCTH9DQkx7scAEhWnAAj3ZgACZI4AAgBcTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFJlcG9zOgBzZTRzYzoAU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnM6AFBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYADgA0ABkAUABhAHIAbgBhAHMAQQBuAGQAQwBsAGUAbQBlAG4AdABzADEAOQA4ADYALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAEpVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzQW5kQ2xlbWVudHMxOTg2LnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANEA1gDeAtgC2gLfAuoC8wMBAwUDDAMVAxoDJwMqAzwDPwNEAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA0Y=}}
BlankProjectTemplate/src/INSTALL.txt deleted 100644 → 0
View file @ 35121c99
Instructions for installation and running of software.
\ No newline at end of file
BlankProjectTemplate/src/README.md deleted 100644 → 0
View file @ 35121c99
# Project Name Source Code
The folders and files for this project are as follows:
...
Copyright.txt
View file @ ba88147b
The contents of this folder were created by Spencer Smith.
(c) 2017 Spencer Smith ALL RIGHTS RESERVED
\ No newline at end of file
(c) 2018 Spencer Smith ALL RIGHTS RESERVED
\ No newline at end of file
CourseOutline/CAS741_Outline.pdf
View file @ ba88147b
No preview for this file type
CourseOutline/CAS741_Outline.tex
View file @ ba88147b
......@@ -32,11 +32,11 @@
\renewcommand{\labelenumi}{\arabic{enumi}.}
\newcounter{temp}
\begin {document}
\begin{document}
\maketitle
This course outline contains important information that will effect your
This course outline contains important information that will affect your
grade. You should retain and refer to this outline throughout the term.
\section {Instructor}
......@@ -45,61 +45,61 @@ Dr.~Spencer Smith\\
Office: ITB/167\\
E-mail: \texttt{smiths@mcmaster.ca}\\
Web: \url{http://www.cas.mcmaster.ca/~smiths}\\
Office Hours Term 1: Drop in, or by appointment\\
Office Hours: Drop in, or by appointment\\
\section{Calendar Description}
This course presents the basic principles of software development for reliable
scientific and engineering software. Using example applications, a systematic
process is given for the development and documentation of requirements, system
design, module design, implementation, testing and inspection.
and sustainable scientific and engineering software. Using example
applications, we discuss a systematic process for the development and
documentation of requirements, system design, module design, implementation,
testing, and inspection.
\section{Introduction}
Scientific computation consists of using computer tools to simulate mathematical
models of real world systems so that we can better understand and predict the
system's behaviour. A small sample of some important applications of scientific
computation include the following: designing new automotive parts, analysing the
flow of blood in the body, and determining the concentration of a pollutant
released into the groundwater. As these examples illustrate, scientific
computation can be used for tackling problems that impact such areas as
manufacturing, financial planning, environmental policy, and the health, welfare
and safety of communities. Given the important applications of scientific
computation, it is surprising that little emphasis is currently placed on the
quality of the software that performs the computations. Although many
Scientific computation (Research Software) consists of using computer tools to
simulate mathematical models of real world systems so that we can better
understand and predict the system's behaviour. A small sample of some important
applications of scientific computation include the following: designing new
automotive parts, analysing the flow of blood in the body, and determining the
concentration of a pollutant released into the groundwater. As these examples
illustrate, scientific computation can be used for tackling problems that impact
such areas as manufacturing, financial planning, environmental policy, and the
health, welfare and safety of communities. Given the important applications of
scientific computation, it is surprising that developers place little emphasis
on the quality of the software that performs the computations. Although many
successful and sophisticated algorithms have been developed for scientific
computing, the software often suffers from problems with such qualities as
reliability, usability, verifiability, maintainability, reusability and
portability. This is why scientific software is routinely sold with a
disclaimer instead of a warranty. To make matters worse, the quality of
scientific software is becoming increasingly more of an issue because the
complexity and size of the problems that can be simulated on modern computers is
constantly growing. The question for the future is how to meet the growing need
for providing quick solutions to large and complex problems, and at the same
time ensure that the solutions are correct? This graduate course will
investigate this question by applying to scientific computing problems such
software engineering methodologies as commonality analysis, requirements
analysis and documentation, modular decomposition, module interface
specification, testing, code and document generation and assurance cases.
The course will look at tools, techniques and principles for iterative and
reliability, usability, verifiability, maintainability, reusability, and
portability. This is why developers sell scientific software with a disclaimer
instead of a warranty. To make matters worse, the quality of scientific
software is becoming increasingly more of an issue because the complexity and
size of the problems that can be simulated on modern computers is constantly
growing. The question for the future is how to meet the growing need for
providing quick solutions to large and complex problems, and at the same time
ensure that the solutions are correct? This graduate course will investigate
this question by applying to scientific computing problems such software
engineering methodologies as commonality analysis, requirements analysis and
documentation, modular decomposition, module interface specification, testing,
code and document generation and assurance cases.
The course will look at tools, techniques, and principles for iterative and
incremental development of scientific and engineering software. Despite the
iterative development cycle, the documentation will follow 5 rational steps: i)
identify the problem, ii) document the requirements, iii) design the system, iv)
implement the software, and v) perform tests. This structure is well suited to
scientific computing because it parallels the idealized scientific method, as
follows: i) a physical problem of engineering or scientific importance is
identified; ii) a system of governing equations and the associated boundary
conditions are derived; iii) a numerical algorithms are developed; iv) the
numerical algorithms are implemented on a computer; and, v) the model and the
computed results are verified and validated, with the potential to return to one
of the previous steps if necessary. These five steps are inherently
multidisciplinary as they involve skills from physical modelling, mathematics,
numerical analysis and computer science. For this reason it is important that
requirements (including assumptions) and design decisions are clearly
documented.
\subsection*{Course Web Site}
follows: i) we identify a physical problem of engineering or scientific
importance; ii) we derive a system of governing equations and the associated
boundary conditions; iii) we develop numerical algorithms; iv) we implement the
numerical algorithms on a computer; and, v) we verify and validate the model and
the computed results, with the potential to return to one of the previous steps
if necessary. These five steps are inherently multidisciplinary as they involve
skills from physical modelling, mathematics, numerical analysis and computer
science. For this reason it is important that we clearly document requirements
(including assumptions) and design decisions.
\subsection*{Avenue, GitLab, GitHub and Teams}
This course will be administered via Avenue to Learn. Go to
......@@ -112,88 +112,172 @@ This course will be administered via Avenue to Learn. Go to
\noindent to access the course's Avenue to Learn page. Please send only normal
McMaster e-mail; do not send mail via Avenue.
Students should be aware that, when they access the electronic
components of this course, private information such as first and last
names, user names for the McMaster e-mail accounts, and program
affiliation may become apparent to all other students in the same
course. The available information is dependent on the technology
used. Continuation in this course will be deemed consent to this
disclosure. If you have any questions or concerns about such
disclosure please discuss this with the Instructor.
Students should be aware that, when they access the electronic components of
this course, private information such as first and last names, usernames for the
McMaster e-mail accounts, and program affiliation may become apparent to all
other students in the same course. The available information is dependent on
the technology used. Continuation in this course will be deemed consent to this
disclosure. If you have any questions or concerns about such disclosure please
discuss this with the Instructor.
\emph{It is the student's responsibility to be aware of the
information on the course's Avenue to Learn page and to check
regularly for announcements.}
The primary purpose of Avenue will be for maintaining grades. Most
of the course content will be maintained in a public git repository.
You can access this repository at:\\
The primary purpose of Avenue will be for maintaining grades. Most of the
course content will be maintained in a public git (CAS GitLab) repository. You
can access this repository at:
~\newline
\href{https://gitlab.cas.mcmaster.ca/smiths/cas741/}{https://gitlab.cas.mcmaster.ca/smiths/cas741/}\\
\noindent Rather than use the Avenue discussion board, please post your
questions (issues) to the GitLab issue tracker.
% \noindent Rather than use the Avenue discussion board, please post your
% questions (issues) to the GitLab issue tracker.
In addition to Avenue and the gitlab course note repository, every student will
create a public gitHub repository (with instructor added as a full access
collaborator) for their work. The GitHub server is located at
\url{https://github.com/}. Students will be expected to use GitHub to provide
comments on the work of other students in the class.
In addition to Avenue and the Gitlab course note repository, every student will
create a public GitHub repository (with the instructor added as a full access
collaborator) for their work. The GitHub server is at
\url{https://github.com/}. Each student's repo will start from the given
\href{https://github.com/smiths/capTemplate} {template repo}. Students will be
expected to use GitHub to provide comments on the work of other students in the
class.
We will use Teams for for discussion. Our communication policy is that questions
that are relevant to other students in the class should be posted on Teams.
That way everyone can benefit from the discussion. Questions that are relevant
to only one individual, should be sent to the instructor via e-mail. Please
send only normal McMaster e-mail; do not send mail via Avenue or direct messages
using Teams.
\subsection*{Classes}
Classes will be held in person in the graduate classroom (ITB/222).
\section {Course Project}
At the beginning of the term each student will select a scientific computing
problem. Over the course of the term software will be developed to address the
selected problem. The software development process will follow the iterative
waterfall model, with the following milestones:
waterfall model. Typically, students will use one of two methodologies:
\begin{enumerate}
\item ``Traditional/Manual Approach''
\begin {enumerate}
\item Software Requirements Specification (SRS)
\item Module Guide (MG)
\item Module Interface Specification (MIS)
\item Implementation (any appropriate programming language)
\item Testing
\item Verification and Validation (VnV) Plan
\item Verification and Validation (VnV) Report
\end{enumerate}
\item ``Drasil (artifact+code generation)/Automated Approach''
\begin {enumerate}
\item Software Requirements Specification (SRS) draft, as for manual
\item SRS generation in Drasil
\item Drasil design choices and explanation
\item Code generation (Drasil supported programming languages)
\item Verification and Validation (VnV) Plan (manually produced)
\item Verification and Validation (VnV) Report (manually produced)
\end{enumerate}
\end {enumerate}
If a student opts for the Drasil approach, they can later switch back to the
Traditional approach, without any grade related penalty.
The Drasil approach uses the \href{https://github.com/JacquesCarette/Drasil}
{Drasil framework} to generate the SRS and the code. Since Drasil is
incomplete, the V\&V documents will still be generated manually. Further
details on Drasil will be covered during the class lectures.
With approval from the instructor, the deliverables can potentially be modified,
if a project is more suited to different deliverables. For instance, a project
if a project is more suited to a different structure. For instance, a project
could replace one of the above deliverables with an assurance case deliverable,
or with domain specific code to automatically build the deliverables.
or with a greater emphasis on domain specific code to automatically build the
deliverables, or with extending Drasil's capabilities. Projects that add
something substantial to the base requirements are eligible for a bonus grade of
up to 50\%. For instance, adding support for a new external library to Drasil
would be worth additional marks. The specific bonus should be discussed with
the instructor in advance.
\section {Course Structure}
The format of the course will consist of student and instructor presentations.
Each student will be expected to do an informal presentation on their SRS, MG,
MIS, Implementation and Testing. It is expected the class discussion will
assist in improving the quality of the written deliverables. Each student will
be expected to hand in the following written documents: SRS, MG, MIS, and Final
Documentation.
Each student will be expected to do an informal presentation on some subset of
their SRS, MG, MIS, Drasil, Implementation, VnV Plan and VnV Report. The class
discussion during each presentation will assist in improving the quality of the
written deliverable. Given the term-long goal of improving each project,
students should be prepared for criticism during their presentations. This
criticism is part of formative learning; it is part of the learning process. It
will not effect the presentation grades. Please let the instructor know if you
have any concerns with the feedback you receive.
Each student following the traditional approach will be expected to virtually
hand in the following written documents: SRS, MG, MIS, VnV Plan, VnV Report,
code and Final Documentation. The deliverables for the Drasil approach are the
same, except we replace the MG and MIS with the Drasil code to generate the
documentation and code.
\section {Grading}
\begin {enumerate}
\item Presentations and class discussion 10\%
\item (Traditional and Drasil) Presentations and class discussion 5\%
\item Quality of GitHub issues provided to classmates 5\%
\item (Traditional and Drasil) ``Domain Expert'' reviewer role 5\%
\item Problem Statement 0\%
\item (Traditional and Drasil) Problem Statement, Risk, Proof of Concept (POC) Plan 0\%
\item System Requirements Specification (SRS) 20\%
\item (Traditional and Drasil) System Requirements Specification (SRS) Document 10\%
\item Verification and Validation Plan 10\%
\item (Traditional and Drasil) System Verification and Validation (VnV-Syst) Plan 10\%
\item Module Guide (MG) 10\%
\item (Traditional) Module Guide and Module Interface Specification (MG and MIS) 10\%
\item Module Interface Specification (MIS) 10\%
\item (Drasil) Drasil code and Code Explanation Document 10\%
\item Final Documentation (including revised versions of previous documents,
plus the source code and a testing report) 35\%
\item (Traditional and Drasil) Final Documentation 60\%
\begin{enumerate}
\item Problem Statement (Revised)
\item SRS (Revised)
\item System VnV Plan (Revised)
\item (Traditional) MG (Revised)
\item (Traditional) MIS (Revised)
\item (Drasil) Drasil code and explanation (Revised)
\item Unit VnV Plan
\item Code
\item System VnV Report
\item Unit VnV Report
\item Reflection Report
\item Extra task (for non-research projects, see below)
\end{enumerate}
\end {enumerate}
All projects are expected to use Continuous Integration (CI), unless there is a
compelling reason (agreed on with the instructor) why CI is not an option.
\subsection{Peer Review}
Each student will be assigned as a ``Domain Expert'' (DE) for one of their
classmates. The DE will review (via GitHub issues) their assigned project. %
%In addition, they will write the code for one of the modules of their assigned
% project and issue a pull request through GitHub. For the secondary reviewer
% role, the instructor will assign various review tasks throughout the term. The
% secondary reviewers feedback will focus more on the structure and format of the
% documentation, rather than on issues related to domain knowledge.
\subsection{Challenge Level and Extra Tasks}
Due to differences in interests and background, students in this course will
select topics with varying levels of complexity in the required domain knowledge
and possibly in the implementation. If a project requires graduate-level domain
knowledge, it is classified as a ``research'' project. For projects that are
not ``research'' projects, an extra task required. Examples of extra tasks
include usability testing, rigorous code walkthroughs, user manual, formal
proof, etc. If a research project does extra work, the extra work is graded as
a bonus. The extra task is evaluated as part of the final documentation.
\section {Policy Statements}
This section of the course outline explains the course policy with respect to
......@@ -267,4 +351,63 @@ during the term and to note any changes. Your McMaster e-mail is the
one with the address ending in \texttt{@mcmaster.ca}. This is a
separate e-mail address from your Avenue address.
\subsection*{Conduct Expectations}
As a McMaster graduate student, you have the right to experience, and the
responsibility to demonstrate, respectful and dignified interactions within all
of our living, learning and working communities. These expectations are
described in the Code of Student Rights \& Responsibilities (the ``Code''). All
students share the responsibility of maintaining a positive environment for the
academic and personal growth of all McMaster community members, whether in
person or online.
It is essential that students be mindful of their interactions online, as the
Code remains in effect in virtual learning environments. The Code applies to any
interactions that adversely affect, disrupt, or interfere with reasonable
participation in University activities. Student disruptions or behaviours that
interfere with university functions on online platforms (e.g. use of Avenue 2
Learn, WebEx or Zoom for delivery), will be taken very seriously and will be
investigated. Outcomes may include restriction or removal of the involved
students’ access to these platforms.
\subsection*{Academic Accommodation of Students with Disabilities}
Students with disabilities who require academic accommodation must contact
Student Accessibility Services (SAS) at 905-525-9140 ext. 28652 or
sas@mcmaster.ca to make arrangements with a Program Coordinator. For further
information, consult McMaster University’s Academic Accommodation of Students
with Disabilities policy.
\subsection*{Academic Accommodation for Religious, Indigenous or Spiritual
Observations (RISO)}
Students requiring academic accommodation based on religious, indigenous or
spiritual observances should follow the procedures set out in the RISO
policy. Students should submit their request to their Faculty Office normally
within 10 working days of the beginning of term in which they anticipate a need
for accommodation or to the Registrar's Office prior to their
examinations. Students should also contact their instructors as soon as possible
to make alternative arrangements for classes, assignments, and tests.
\subsection*{Copyright and Recording}
Students are advised that lectures, demonstrations, performances, and any other
course material provided by an instructor include copyright protected works. The
Copyright Act and copyright law protect every original literary, dramatic,
musical and artistic work, including lectures by University instructors
The recording of lectures, tutorials, or other methods of instruction may occur
during a course. Recording may be done by either the instructor for the purpose
of authorized distribution, or by a student for the purpose of personal
study. Students should be aware that their voice and/or image may be recorded by
others during the class. Please speak with the instructor if this is a concern
for you.
\subsection*{Extreme Circumstances}
The University reserves the right to change the dates and deadlines for any or
all courses in extreme circumstances (e.g., severe weather, labour disruptions,
etc.). Changes will be communicated through regular McMaster communication
channels, such as McMaster Daily News, A2L and/or McMaster email.
\end{document}
\ No newline at end of file
Examples/CaseStudies.txt 0 → 100644
View file @ ba88147b
1. Software Engineering for Science
https://gitlab.cas.mcmaster.ca/SEforSC/se4sc
https://gitlab.cas.mcmaster.ca/SEforSC/se4sc/tree/git-svn/SciCompAndSoftEngPapers
2. Case Study Examples of Scientific Computing Projects
SWHS: https://github.com/smiths/swhs
GlassBR: https://github.com/smiths/caseStudies/tree/master/CaseStudies/glass
noPCM: https://github.com/smiths/caseStudies/tree/master/CaseStudies/noPCM
SSP: https://github.com/smiths/caseStudies/tree/master/CaseStudies/ssp
GamePhysics: https://github.com/smiths/caseStudies/tree/master/CaseStudies/gamephys
3. Document and Code Generation
https://github.com/JacquesCarette/Drasil
\ No newline at end of file