\documentclass[pdf,bookmarks,colorlinks=true]{IEEEtran}
\usepackage{times}
\usepackage{amsmath}
\usepackage{hyperref}
\usepackage{url}
\usepackage{psfrag}    %Shouldn't use this if you plan on using pdflatex!
\usepackage{graphicx}
\usepackage{wrapfig}   %for wrapping text around figures and tables

%Included for Gather Purpose in WinEdt only:
%input "my.bib"

\title{\bf Generic Technical Paper Skeleton}

\author{Scot Anderson\\
Southern Adventist University\\
scot@southern.edu
}

\begin{document}

\maketitle

\begin{abstract}

The abstract should describe the basic message of the paper, including: the
problem, why your solution should be of interest, some notion that your
solution is effective, and a teaser about how it has been evaluated. Cover all
of this using between 75 and 150 words. The abstract is thus the hardest part
to write. Sometimes I try to write it first, but the final version is usually
composed of items drawn from the introduction, and then condensed, as the last
step of writing the paper.

\end{abstract}

%   \tableofcontents
%   \newpage

% \doublespace

\section{Introduction}
\label{sec:Introduction}

\textbf{The problem we have solved:}

%\begin{itemize}
%\item
Concentrate on making {\em this} assertion and {\em only} this assertion in a
succinct set of 1 to 3 paragraphs

%\item
A common mistake is to explain too much of the problem context first. Instead,
state the problem essentially as a claim, and leave explanations supporting
your claim to the next part, ``Why it is not already solved.''

%\end{itemize}


\textbf{Why the problem is not already solved or other solutions
are ineffective in one or more important ways}

%\begin{itemize}
%\item
Your new idea need not solve every problem but it should solve at least one
that is not already solved

%\item
This is the place to provide a succinct description of the problem context
giving enough information to support the claim that a problem exists, made in
the preceding problem declaration.

%\end{itemize}


\textbf{Why our solution is worth considering and why is it effective
in some way that others are not}

%\begin{itemize}
%\item
A succinct statement of {\em why} the reader should care enough to read the
rest of the paper.

%\item
This should include a statement about the characteristics of your solution to
the problem which 1) make it a solution, and 2) make it superior to other
solutions to the same problem.

%\end{itemize}


\textbf{How the rest of the paper is structured}
%\begin{itemize}
%\item
The short statement below is often all you need, but you should change it when
your paper has a different structure, or when more information is {\em
required} to describe what a given section contains. If it isn't {\em required}
then you don't want to say it here.

%\end{itemize}

The rest of this paper first discusses related work in
\ref{sec:RelatedWork}, and then describes our implementation in
\ref{sec:Implementation}. \ref{sec:Evaluation} describes how we evaluated
our system and presents the results. \ref{sec:Conclusion} presents our
conclusions and describes future work.

\section{Related Work}
\label{sec:RelatedWork}

\textbf{Other efforts that exist to solve this problem and why are they
less effective than our method}

%\begin{itemize}
%\item
Resist the urge to point out only flaws in other work. Do your best to point
out both the strengths and weaknesses to provide as well rounded a view of how
your idea relates to other work as possible

%\item
In a social and political sense, it is {\em very smart} as well as ethical to
say good things, which are true, about other people's work. A major motivation
for this is that editors and program committee members have to get a set of
reviews for your paper. The easiest way for them to decide who should review it
is to look at the set of references to {\em related work} (e.g.,
\cite{Anderson2007,Anderson2009}) to find people who are likely to be competent to
review your paper.  The people whose work you talk about are thus likely to be
reading what you say about {\em their} work while deciding what to say about
{\em your} work.

%\item
Clear enough? Speak the truth, say what you have to say, but be generous to the
efforts of others.

%\end{itemize}


\textbf{Other efforts that exist to solve related problems that are
relevant, how are they relevant, and why are they less effective than our
solution for this problem}

%\begin{itemize}
%\item
Many times no one has solved your exact problem before, but others have solved
closely related problems or problems with aspects that are strongly analogous
to aspects of your problem

%\end{itemize}

\section{Implementation}
\label{sec:Implementation}

\textbf{What we (will do $|$ did): {\em Our Solution}}
%\begin{itemize}
%\item
Another way to look at this section is as a paper, within a paper,
describing your implementation. That viewpoint makes this the introduction to
the subordinate paper, which should describe the overall structure of your
implementation and how it is designed to address the problem effectively.

%\item
Then, describe the structure of the rest of this section, and what each
subsection describes.


\textbf{How our solution (will $|$ does) work}
%\begin{itemize}
%\item
This is the body of the subordinate paper describing your solution. It
may be divided into several subsections as required by the nature of your
implementation.

%\item
The level of detail about how the solution works is determined by what
is appropriate to the type of paper (conference, journal, technical report)

%\item
This section can be fairly short for conference papers, fairly long for
journal papers, or {\em quite} long in technical reports. It all depends on the
purpose of the paper and the target audience

%\item
Proposals are necessarily a good deal more vague in this section since
you have to convince someone you know enough to have a good chance of building
a solution, but that you have not {\em already} done so.

%\end{itemize}


\section{Evaluation}
\label{sec:Evaluation}

\textbf{How we tested our solution}
\begin{itemize}
\item   Performance metrics
\item   Performance parameters
\item   Experimental design
\end{itemize}


\textbf{How our solution performed, how its performance compared to
that of other solutions mentioned in related work, and how these results show
that our solution is effective}:

\begin{itemize}
\item   Presentation and Interpretation
\item   Why, how, and to what degree our solution is better
\item   Why the reader should be impressed with our solution
\item   Comments

\end{itemize}


\textbf{Context and limitations of our solution as required for
summation:} State what the results {\em do} and {\em do not} say.



\section{Conclusions and Future Work}
\label{sec:Conclusion}

\textbf{The problem we have solved}: The most succinct statement of the problem in the paper. Ideally one
sentence. More realistically two or three. Remember that you simply state it
without argument. If you have written a good paper you are simply reminding the
reader of what they now believe and of how much they agree with you.



\textbf{Our solution to the problem}: again, a succinct statement of the presented solution
Sometimes it works well to leave it at that and not even describe your
solution here. If you do, then again state your solution in one or two
sentences taking the rhetorical stance that this is all obvious. If you have a
good solution and have written an effective paper, then the reader already
agrees with you.

\textbf{Why our solution is worthwhile in some significant way}:
Again, a succinct restatement in just a few sentences of why your solution is
worthwhile assuming the reader already agrees with you

\textbf{Why the reader should be impressed and/or pleased to have read the paper}:
A few sentences about why your solution is valuable, and thus why the
reader should be glad to have read the paper and why they should be glad you
did this work.



\textbf{What we will (or could) do next}

\begin{itemize}
\item   Improve our solution
\item   Apply our solution to harder or more realistic versions of this problem
\item   Apply our solution or a related solution to a related problem

\end{itemize}


\bibliographystyle{IEEETrans}
\bibliography{./my}


\end{document}