paper_20_sdo.tex

\documentclass[SDSUThesis.tex]{subfiles} 
\begin{document}


\section{A SOFTWARE DEVELOPMENT ORGANIZATION}
A \textit{Software Development Organization (SDO)} is any organization or subset of an organization that is responsible
for the creation, deployment, and maintenance of software.  Many times an SDO
is a company that produces software.  Other times, an SDO is contained
within the Information Technology department of a larger organization. Some of the job roles
with an SDO are: software engineer, system administrator, software quality analyst,
programmer, database administrator, and documentation specialist.


\subsection{WHAT IS SOFTWARE?}
Numerous definitions can be found for the term \textit{software}.
Software is more than just computer programs. According to Ian Sommerville \cite{Sommerville2001}, 
``Software is not just the programs but also all associated documentation and configuration data which is needed to make these programs operate correctly.''
This is the definition used for the remainder of this dissertation.


\subsection{THE SOFTWARE DEVELOPMENT LIFE CYCLE}
    The discipline of software engineering has created a workflow for developing
    software.  
    This workflow is called the \textit{Software Development Life Cycle (SDLC)}
    \nomenclature{SDLC}{Software Development Life Cycle}.
    SDLC can be defined as \cite{Ruparelia2010}:
    \begin{quote}
     [...] a conceptual framework or process that considers the structure of the stages
     involved in the development of an application from its initial feasibility study
     through to its deployment in the field and maintenance.
    \end{quote}
    While the SDLC states what needs to be done, there are numerous models 
    that formalize exactly how to perform the SDLC.  The models contain
    steps that are commonly referred to as a phases. A few of the popular
    models are described below.
    
    
    \subsubsection{WATERFALL}
        The waterfall model is the oldest and most influential of the SDLC models. 
        It was first presented at a Navy Mathematical Computing Advisory Panel in 1956
        by Herb Benington \cite{Benington1987}. Figure \ref{fig:benington} shows
        the model Benington outlined for producing large software systems.  
        In 1970, Benington's model was modified by Royce \cite{Royce1987}.  Royce
        produced an updated version of the diagram seen in Figure \ref{fig:royce}
        which provides some loops to go back to a previous phase in the workflow.
    
        \begin{figure}[ht]
            \centering
            \includegraphics[scale=.7]{images/benington_waterfall.PNG}
            \caption[BENINGTON'S ORIGINAL DIAGRAM FOR PRODUCING LARGE SOFTWARE SYSTEMS]
                    {Benington's original diagram for producing large software 
                        systems, adapted from \cite{Benington1987}}
            \label{fig:benington}
        \end{figure}%
        \begin{figure}[ht]
            \centering
            \includegraphics[scale=.7]{images/royce_waterfall.PNG}
            \caption[ROYCE'S VERSION OF THE WATERFALL MODEL]
                {Royce's version of the waterfall model for producing software 
                        systems, adapted from \cite{Royce1987}}
            \label{fig:royce}
        \end{figure}
        
        The modern version of the waterfall model specifies that each phase needs 
        to be entirely completed before moving
        onto the next phase.  Some small amount of overlap is permitted and looping 
        occurs but both actions are discouraged and should be limited.  
        A modern diagram of the waterfall model can be seen in Figure \ref{fig:waterfall}.
        \begin{figure}[ht]
            \centering
            \includegraphics[scale=.9]{images/waterfall.png}
            \caption[MODERN WATERFALL]
                {Modern Waterfall Diagram, adapted from \cite{Hibbs2009} }
            \label{fig:waterfall}
        \end{figure}
        
        Waterfall has some excellent features such as: simple to understand,
        easy to plan, and well-defined phases. However, waterfall lacks
        the flexibility required of many software systems built today
        \cite{Maheshwari2012}.  Due to the fact the phases are so sequential,
        it makes changes during the life cycle difficult and expensive if 
        not impossible. Therefore, other models of SDLC have been created
        to address the lack of flexibility of the waterfall model. Notice,
        the other models are  adaptations of waterfall.
    
    
    \subsubsection{SPIRAL}
        
        The spiral model for software development was presented by Boehm in 1986
        \cite{Boehm1986, Boehm1988}. 
        The goal of the spiral model of software development is very risk-driven.
        A software project will start with many small and quick iterations. 
        Each iteration will cover the following 4 basic steps. 
        \begin{enumerate}
            \item Determine Objectives
            \item Identify Risks
            \item Develop and Test
            \item Plan Next Iteration
        \end{enumerate}
        This model allows software to be built over a series of iterations
        without risking too much time or effort in any single iteration.
        Spiral requires a very adaptive management approach
        as well as flexibility of the key stakeholders \cite{Ruparelia2010}.
        It can also be difficult to identify risks that will occur in future
        iterations.
        Figure \ref{fig:spiral} provides a bit more detail on the iterations
        and the overall process. 
        \begin{figure}[ht]
            \centering
            \includegraphics[scale=.8]{images/spiral_model.png}
            \caption[SPIRAL SDLC MODEL]{Spiral SDLC Model \cite{Boehm2000} }
            \label{fig:spiral}
        \end{figure}
        
        
    \subsubsection{AGILE}
        Agile software development has arisen due to the inability
        of the waterfall and other models to adjust to changes during the 
        development cycle.  
        Agile software development is a group of SDLC models that operate
        under the influence of the following four key principles \cite{Beck2001}.
        \begin{enumerate}
            \item Individuals and interactions over processes and tools
            \item Working software over comprehensive documentation
            \item Customer collaboration over contract negotiation
            \item Responding to change over following a plan
        \end{enumerate}
        Agile does not specify an implementation, but
        some specific models of agile SDLC are:
        eXtreme Programming, Scrum, Lean, Kanban and others 
        \cite{Moniruzzaman2013, Hibbs2009}.  Agile models 
        are very popular in many of today's software development
        organizations because the models work well for dynamic
        quickly changing applications such as web-based applications.
        Startups have largely adopted the Lean methodology for its
        ability to identify a minimum viable product\footnote{
        A \textit{minimum viable product} is a reduced version of software
        that contains only the bare minimum functionality required to meet
        the requirements.}
        and reduce the time to market \cite{Giardino2014}. 
        
        
    \subsubsection{SDLC COMMONALITIES}
        Even with the large number of SDLC models currently being used by different SDOs,
        many commonalities exist among the models.  The 
        commonalities can be tied back to the steps of waterfall.  All of the models
        exhibit, to some degree, the following phases. The only major difference is 
        the scope, size, and duration of each phase.  For example, the spiral
        model spends less time in each phase.  The agile models produce less
        documentation and focus more on the implementation phase. Here are
        the five common phases in nearly all SDLC models:
        \begin{description}
            \item[1. Requirements] \hfill \\ The first phase is involved 
                with defining what the software must do.  Each piece of 
                functionality is considered a requirement.  
            \item[2. Design] \hfill \\ Before writing any code, the 
                necessary infrastructure and involved software systems
                must be identified. This phase can serve as a guideline for the 
                remaining phases. If done properly, this phase can greatly 
                help the later phases.
            \item[3. Implementation] \hfill \\ Often the only phase of the SDLC 
                that is measured, this is the phase where the actual computer
                code is written.
            \item[4. Testing] \hfill \\ This phase validates the expected 
                functionality.  Also, testing attempts to discover unexpected
                side affects of the software.
            \item[5. Deployment and Maintenance] \hfill \\ All software must 
                be correctly deployed and maintained.  This phase is the 
                most expensive and lengthy phase of the software
                development life cycle.
        \end{description}
        
        These five steps cannot cover everything that needs to be accomplished
        during a project.  They just provide of rough guideline of what needs
        to be completed in order to ensure a more successful software release.
        Appendix \ref{app:detailedSDLC} contains a more detailed list of the
        tasks necessary to complete the software life cycle.
        
\subsection{WHAT IS SOFTWARE ENGINEERING?}
\label{sec:swe}
    \textit{Software Engineering} as a term dates back to the 
    1968 North Atlantic Treaty Organization (NATO) conference \cite{Tsui2013, Naur1969}. Over the 
    years many definitions have been provided.  Institute of Electrical 
    and Electronics Engineers (IEEE) provides a definition that encompasses 
    many of the other definitions.
    \nomenclature{IEEE}{Institute of Electrical and Electronics Engineers}
    IEEE ISO610.12 defines software engineering as, 
    ``The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software''
    \cite{Ieee1990}.
    
    Software engineering has struggled to determine the correct projects 
    to complete \cite{DeMarco2009}.
    Software projects are commonly behind schedule and over budget \cite{Lehtinen2014, 
    Charette2005,Jorgensen2013,Ichu2012} with nearly 20\% of projects
    in the United States still failing \cite{Emam2008}. 
    As of 2015, Software engineering is 
    still awaiting the professional status of more established fields such
    as medicine, law, and general engineering \cite{Jones2013b}. 
    Organizations need a better
    technique to understand the past performance so they can better 
    predict the future performance.  Proper measurement will be essential
    to solidifying software engineering as certified profession.  

\end{document}